对于项目架构的疑惑

     今天看了实战项目分析一文，对文中有些观点颇为不解。虽然很多园友都说不错.看了原文,作者提出的项目问题,自己的比较下自己平时做的项目,居然很多都一样,心哇凉哇凉水的,难道以前自认为不错的项目都是些垃圾吗?与高手做的项目就差这么远吗?仔细想下,总觉的说的让人不服,不服的原因并不是作者写的不好,而是本人不理解而已.

    

     疑问一：分层架构中的面向接口

     引用原文：
     ----------------------------------------
    a.下层对上层隐藏细节，只暴露接口。再此，本应属于业务逻辑层的业务对象被暴露到了展现层。

    b.上层对下层不可见。即下层不知道上层的存在，只提供接口。这里业务逻辑层的业务对象被数据存取层操作，会导致两个层之间纠缠不清，以至于会出现改动业务逻辑会影响数据存取方式的荒谬现象。另外，强类型DataSet也有同样的问题（本应是属于数据存取层的，却被传递到业务逻辑层，甚至是展现层） 本应是属于数据存取层的，却被传递到业务逻辑层，甚至是展现层.
    举一个简单的例子：本系统中业务逻辑层会调用数据存取层的方法，得到一些数据。比如调用一个PartnerAccess类的GetPartner的方法。PartnerAccess是数据存取层的一个具体类，负责Patrner表的所有增删改查操作。而业务逻辑层到处充斥着这样的语法：PartnerAccess partnerac = new PartnerAccess（）；partnerac.getPartner（）；
这就是一个典型的依赖于具体实现的方案。这样的后果是，业务逻辑层知道每一个数据表的数据结构，甚至是无需知道的细节，并且对数据层的每一个方法都了如指掌，到处都在使用。当我们开始修改PartnerAccess的其中一个方法的时候（比如增加一个参数）都要修改业务逻辑层的相关代码，但谁知道那些代码都在哪呢？只好重新编译吧，让编译器告诉我们。而面向接口编程可以使我们避免这种问题。我们不再依赖于千千万万个PartnerAccess或者什么别的Access类，而是依赖一个IDataAccess的接口。这样，所有的数据存取都被标准化，我们的调用代码便的更简单，不会依赖任何数据库的结构，甚至不需要知道表的名字，有多少个字段等等。当我们增加一个OrderAccess类时，只需在数据存取层增加一个文件，一个类就好了，而不需要更改业务逻辑层的任何代码。

    ----------------------------------------

   按照作者所说的情况，我写了一个类似实现的DEMO。这个DEMO就按作者的意思面向接口,不知道是否完全符合.

   数据存取层有一个类PartnerAccess,和一个接口IDataAccess

   IDataAccess:

public  interface IDataAccess
    {
        IList<string> getPartner();
    }

    

    PartnerAccess:

/**//// <summary>
    /// 负责Patrner表的所有增删改查操作
    /// </summary>
    public class PartnerAccess : IDataAccess
    {
       /**//// <summary>
       /// 取得所有合作者的姓名
       /// </summary>
       /// <returns>合作者记录集</returns>
       public IList<string> getPartner()
       {
           //方便说明问题,就省略数据库取记录的操作了.
           IList<string> _list = new List<string>();
           for (int i = 1; i < 100; i++)
           {
               //加入99个合作者的姓名
               _list.Add(i.ToString());
           
           }
           return _list ;
 
       
       }
    }

   业务逻辑层会调用数据存取层的方法，得到一些数据，这里我构造了一个类：Partner_BLL

/**//// <summary>
    /// 负责Patrner表的所有增删改查操作
    /// </summary>
   public  class Partner_BLL
    {
        /**//// <summary>
        /// 取得所有合作者的姓名
        /// </summary>
        /// <returns>合作者记录集</returns>
        public IList<string> getPartner()
        {
            //调用数据层中的相关类完成数据的读取操作
            IList<string> _list = new List<string>();
            IDataAccess  _Parter = new PartnerAccess();
            _list = _Parter.getPartner();
            return _list ;

        }
    }

 

   这样的代码真的可以做到一个层的变化不会引起另一层的变化吗?

   面向接口，接口并不是光定义就行的，它也要有具体的类去实现它，既然有了实现的类，那就会必然会存在一定的耦合。例如都在一个接口IDataAccess,当你选择用PartnerAccess类的时候，上面业务逻辑的IDataAccess就会变IDataAccess _Parter = new PartnerAccess();当使用OrderAccess类时就会变成：IDataAccess _Parter = new OrderAccess();

无论你怎么面向接口，业务逻辑层也是要修改代码的，除非你采用工厂模式来实现。话又说回来了，就是采用工厂模式它也是要修改工厂类的。并不能说修改一个层就一切OK。

   当我们开始修改PartnerAccess的其中一个方法的时候,是否会引起业务逻辑层的修改,不在于是否面向接口,而在于你如何修改,如果你的方法中修改了参数,那即使面向接口的话,也是要修改接口,以及具体的实现类,如果是不影响方法重载的情况下,当然可以.

    疑问二：强类型的DataSet为什么不能在层与层之间传递呢？

    引用原文

    --------------------------------------
    本应是属于数据存取层的，却被传递到业务逻辑层，甚至是展现层

    --------------------------------------

    记录集如果不传递的话，那最终UI层是如何取得数据存取层的记录集的呢？本人不才，实在不解。

    我总觉的把对象在层与层之间传递与系统架构关联起来特别牵强.

    总结：一说到系统架构，一般都是大师级别的人来做的事，做为只涉及.net皮毛的程序员来说在这胡说八道可能有点不妥，但大师也是从精通人过来的，适当的参与一下也不为过.  :)  ,面向接口的强大是不用说的，但并不是万能的，适当的面向接口才能发挥最大的作用。系统设计也是要有度的。本文并不是说面向接口不好，只是针对原文有点想法而已。本文只代表个人意见，并没有针对原文作者文章的意思，纯属技术沟通，如有不妥望谅解。