随笔-15  评论-5  文章-0  trackbacks-0
使用多层架构进行系统开发是现今系统设计的流行趋势。通过分解业务细节,将不同的功能代码分散开来,更利于系统的设计和开发,同时为可能的变更提供了更小的单元。

以下就是一个典型的多层体系结构图。

uploads/200607/24_142206_mt.png


首先我们以“订单(Order)”为例,进行一个简单的业务分解。

1. 订单自然包括订单的内容(OrderInfo),其中有诸如订单编号、商品名称、数量,以及金额等信息。
2. 有了订单信息,我们还需要一个存储订单的场所,那么自然需要有个操作读写的对象(OrderAccess)。
3. 为了外界能进行相关的订单操作,我们还需要有个业务逻辑对象(Order),它提供创建新订单,向订单插入/删除商品,保存订单等操作。

通过上面的分析,我们基本上可以将一个业务逻辑完整地分割为:

业务实体 ---> OrderInfo
数据访问 ---> OrderAccess
业务逻辑 ---> Order

基于系统架构考虑,我们将这些对象分别放置在不同的逻辑单元中,这些逻辑单元就组成了“多层”。

业务实体层(Model) ---> 业务实体 ---> OrderInfo
数据访问层(DAL) ---> 数据访问 ---> OrderAccess
业务逻辑层(BLL) ---> 业务逻辑 ---> Order

同样以上面订单为例,我们进一步讲述各层对象的实现细节。

1. 客户基本上只依赖于 Order 和 OrderInfo,通过他们就可以操作业务的全部,它并不关心业务存储等细节。

2. 大多数时候我们会将 OrderAccess 设计成 Internal Protected 方式,OrderAccess 可以是一个抽象类或者接口。我更习惯于将其实现为抽象类,因为某些方法是调用其他方法来实现的,抽象类的设计可以减少实现类的代码数量。另外将该抽象类设计成工厂方法模式,通过 IoC 或者 "配置反射" 来获得具体的实现类,可以减少层之间的耦合,也便于数据系统的替换。

3. Order 多数时候可以实现为 Singleton 或者静态类,它只是提供了一系列的方法来操作某些逻辑,通过接受 OrderInfo 参数来获取信息。其本身无需保存任何状态。如果需要实现购物车,只需将 OrderInfo 存储到 Session 之中即可。

通过上面的例子,我们还可以发现多层的另外一个好处就是更利于团队协作开发。架构设计人员无需考虑具体的数据库实现代码,而将设计重点放在业务层面;数据库开发人员自然也可将重心放在数据库访问优化上。团队成员之间不再是一人负责一个业务模块,不再有了 n 个数据访问类,不再有 n 种不同的对象模式等等。从传统的 "瓦罐作坊" 演变为 "工业流水线",更利于根据技术能力和业务熟悉度的差别来划分不同的角色。
posted on 2008-04-17 17:13 学习才能进步 阅读(198) 评论(0)  编辑 收藏 引用 所属分类: 收集

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理