当前位置>>
今天看了实战项目分析一文，对文中有些观点颇为不解。虽然很多园友都说不错.看了原文,作者提出的项目问题,自己的比较下自己平时做的项目,居然很 多都一样,心哇凉哇凉水的,难道以前自认为不错的项目都是些垃圾吗?与高手做的项目就差这么远吗?仔细想下,总觉的说的让人不服,不服的原因并不是作者写 的不好,而是本人不理解而已.
疑问一：分层架构中的面向接口
引用原文：
----------------------------------------
a.下层对上层隐藏细节，只暴露接口。再此，本应属于业务逻辑层的业务对象被暴露到了展现层。
b.上层对下层不可见。即下层不知道上层的存在，只提供接口。这里业务逻辑层的业务对象被数据存取层操作，会导致两个层之间纠缠不清，以至于会出现改动 业务逻辑会影响数据存取方式的荒谬现象。另外，强类型DataSet也有同样的问题(本应是属于数据存取层的，却被传递到业务逻辑层，甚至是展现层) 本应是属于数据存取层的，却被传递到业务逻辑层，甚至是展现层.
举一个简单的例子：本系统中业务逻辑层会调用数据存取层的方法，得到一 些数据。比如调用一个PartnerAccess类的GetPartner的方法。PartnerAccess是数据存取层的一个具体类，负责 Patrner表的所有增删改查操作。而业务逻辑层到处充斥着这样的语法：PartnerAccess partnerac = new PartnerAccess();partnerac.getPartner();
这就是一个典型的依赖于具体实现的方案。这样的后果 是，业务逻辑层知道每一个数据表的数据结构，甚至是无需知道的细节，并且对数据层的每一个方法都了如指掌，到处都在使用。当我们开始修改 PartnerAccess的其中一个方法的时候(比如增加一个参数)都要修改业务逻辑层的相关代码，但谁知道那些代码都在哪呢?只好重新编译吧，让编译 器告诉我们。而面向接口编程可以使我们避免这种问题。我们不再依赖于千千万万个PartnerAccess或者什么别的Access类，而是依赖一个 IDataAccess的接口。这样，所有的数据存取都被标准化，我们的调用代码便的更简单，不会依赖任何数据库的结构，甚至不需要知道表的名字，有多少 个字段等等。当我们增加一个OrderAccess类时，只需在数据存取层增加一个文件，一个类就好了，而不需要更改业务逻辑层的任何代码。
----------------------------------------
按照作者所说的情况，我写了一个类似实现的DEMO。这个DEMO就按作者的意思面向接口,不知道是否完全符合.
数据存取层有一个类PartnerAccess,和一个接口IDataAccess
IDataAccess:2
Code3
public interface IDataAccess4
{5
IList getPartner();6
}7
PartnerAccess:8
Code9
/**//// 10
/// 负责Patrner表的所有增删改查操作11
/// 12
public class PartnerAccess : IDataAccess13
{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
Code2
/**//// 
3
/// 负责Patrner表的所有增删改查操作4
/// 5
public class Partner_BLL6
{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皮毛的程序员来说在这胡说八道可能有点不妥，但大师也是从精通人过来的，适当 的参与一下也不为过. :) ,面向接口的强大是不用说的，但并不是万能的，适当的面向接口才能发挥最大的作用。系统设计也是要有度的。本文并不是说面向接口不好，只是针对原文有点想 法而已。本文只代表个人意见，并没有针对原文作者文章的意思，纯属技术沟通，如有不妥望谅解。
本文来自:http://tech.it168.com/a2008/0814/200/000000200668.shtml
