求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
 
对于项目分层架构的疑惑
 

2010-06-03 作者:姜敏 来源:IT168

 

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

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

引用原文:

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

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皮毛的程序员来说在这胡说八道可能有点不妥,但大师也是从精通人过来的,适当的参与一下也不为过. :) ,面向接口的强大是不用说的,但并不是万能的,适当的面向接口才能发挥最大的作用。系统设计也是要有度的。本文并不是说面向接口不好,只是针对原文有点想法而已。本文只代表个人意见,并没有针对原文作者文章的意思,纯属技术沟通,如有不妥望谅解。



专家视角看IT与架构
软件架构设计
面向服务体系架构和业务组件
人人网移动开发架构
架构腐化之谜
谈平台即服务PaaS


面向应用的架构设计实践
单元测试+重构+设计模式
软件架构师—高级实践
软件架构设计方法、案例与实践
嵌入式软件架构设计—高级实践
SOA体系结构实践


锐安科技 软件架构设计方法
成都 嵌入式软件架构设计
上海汽车 嵌入式软件架构设计
北京 软件架构设计
上海 软件架构设计案例与实践
北京 架构设计方法案例与实践
深圳 架构设计方法案例与实践
嵌入式软件架构设计—高级实践
更多...