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