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

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

引用原文：

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

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

b.上层对下层不可见。即下层不知道上层的存在，只提供接口。这里业务逻辑层的业务对象被数据存取层操作，会导致两个层之间纠缠不清，以至于会出现改动业务逻辑会影响数据存取方式的荒谬现象。另外，强类型DataSet也有同样的问题(本应是属于数据存取层的，却被传递到业务逻辑层，甚至是展现层) 本应是属于数据存取层的，却被传递到业务逻辑层，甚至是展现层.

举一个简单的例子：本系统中业务逻辑层会调用数据存取层的方法，得到一些数据。比如调用一个PartnerAccess类的GetPartner的方法。PartnerAccess是数据存取层的一个具体类，负责Patrner表的所有增删改查操作。而业务逻辑层到处充斥着这样的语法：PartnerAccess partnerac = new PartnerAccess();partnerac.getPartner();

这就是一个典型的依赖于具体实现的方案。这样的后果是，业务逻辑层知道每一个数据表的数据结构，甚至是无需知道的细节，并且对数据层的每一个方法都了如指掌，到处都在使用。当我们开始修改PartnerAccess的其中一个方法的时候(比如增加一个参数)都要修改业务逻辑层的相关代码，但谁知道那些代码都在哪呢?只好重新编译吧，让编译器告诉我们。而面向接口编程可以使我们避免这种问题。我们不再依赖于千千万万个PartnerAccess或者什么别的Access类，而是依赖一个IDataAccess的接口。这样，所有的数据存取都被标准化，我们的调用代码便的更简单，不会依赖任何数据库的结构，甚至不需要知道表的名字，有多少个字段等等。当我们增加一个OrderAccess类时，只需在数据存取层增加一个文件，一个类就好了，而不需要更改业务逻辑层的任何代码。

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

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

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

1IDataAccess:
2　　Code
3　　public interface IDataAccess
4　　{
5　　IList getPartner();
6　　}
7　　PartnerAccess:
8　　Code
9　　/**////
10　　/// 负责Patrner表的所有增删改查操作
11　　///
12　　public class PartnerAccess : IDataAccess
13　　{
14　　/**////
15　　/// 取得所有合作者的姓名
16　　///
17　　/// 合作者记录集
18　　public IList getPartner()
19
20　　{
21　　//方便说明问题,就省略数据库取记录的操作了.
22　　IList _list = new List();
23　　for (int i = 1; i < 100; i++)
24　　{
25　　//加入99个合作者的姓名
26　　_list.Add(i.ToString());
27　　}
28　　return _list ;
29　　}
30　　}
31

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

1　Code
2　　/**//**//**////
3　　/// 负责Patrner表的所有增删改查操作
4　　///
5　　public class Partner_BLL
6　　...{
7　　/**//**//**////
8　　/// 取得所有合作者的姓名
9　　///
10　　/// 合作者记录集
11　　public IList getPartner()
12　　...{
13　　//调用数据层中的相关类完成数据的读取操作
14　　IList _list = new List();
15　　IDataAccess _Parter = new PartnerAccess();
16　　_list = _Parter.getPartner();
17　　return _list ;
18　　}
19　　}
20

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

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

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

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

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

引用原文

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

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

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

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

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

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