关于项目架构的一些浅谈

         最近,一直在学习和摸索关于项目架构的东东。或许说架构说得有点太大。但是还是暂且用着吧。
也看看过几个高手关于三层架构和MVC模型的文章,觉得很多东西的理解和自己的不是很一样。但是自己确实没有他们研究的深入,所以也不妄加评论。
        在这里想说的是,自己幼稚的观点欢迎各位砸砖;自己绝对的言语只是针对自己的想法。
        我不是什么大虾,所以肯定没有架子,不会跟别人撑死争执,只会死缠着问。
      
          一、数据库设计的角度来说。个人的观点是数据库的设计应该是完全的面向需求和性能。而不应该考虑或是只是适当考虑代码设计的问题。 
                       表结构对程序的设计是有相当大的影响的。但是我们的表是根据需求来做的,同时考虑将来访问的性能问题。视图某种程度上是表 的延伸,但是他依赖表的设计。存储过程是业务逻辑一定程度上原始的表达。
          总结:数据库设计中对系统架构设计颇有影响的就是:表,视图,存储过程
                     其他的,比如约束,索引主要是维持表的完整性和提高数据读取的性能,对系统的结构影响甚微。
        恕我无知,我在做数据库设计是一般就是用到这么几个元素,其中索引用之很少。
       我是坚定的存储过程派(如果分派的话),在这里不去讨论两派的论战了。但是对存储过程的使用也是相当的有疑惑:
               1.存储过程抽空了业务逻辑的功能,让业务逻辑名存实亡;
               2.存储过程加大了数据与UI的耦合度(呵呵,不知道自己对耦合的理解对否?)
               3.项目中存储过程泛滥(很简单的SQL写成了存储过程,很多功能相似的存储过程)
               4.对于3采用动态存储过程,就出现耦合严重
         二、数据库访问层
              1. 看过好几个项目,看到别人的做法总是不厌其烦的用add方法向存储过程添加参数的时候,就在怀疑自己的做法是不很好。
我想为什么不做出一个通用的方法呢?
                             代码如下:
                  

  1using System;
  2using System.Data;
  3using System.Data.SqlClient;
  4
  5namespace DB.Componse
  6{
  7        /// <summary>
  8        ///基于SqlCilent的数据操作基类(全存储过程实现)
  9        /// </summary>

 10     public class SqlProcedure :IDisposable
 11    {
 12         构造和声明
 76
 77         数据库Command对象及参数对象的创建
151        
152         数据库操作方法
268     }

269}

270

                2.看到经典的petshop4.0中,数据库访问层返回的都是DataReader对象,这样确实很好。但是如果我的一个方法中除了要求返回若干数据集,还要返回传出参数,那怎么办呢?
                      (我的做法是在数据库访问层中先将DataReader中的数据转移),这样感觉有点不伦不类了。
              3.对于这层,现在大虾的做法是用ORM直接生成,所以我想在这层中应该是相当的成熟了。所以很想知道那些比较优良的解决方案。
 
        
                   
   

原文地址:https://www.cnblogs.com/xiaobing/p/886737.html