本文针对《MS .NET企业级应用架构设计》业务层前半部分做了相关笔记并记录了自己的一点想法。对于后半部分的具体模式将在第二次笔记中体现。
关于Layer与Tier
Layer一般用来组织代码。例如当提到表现层(Presebtation Layer),我们指的是应用程序前端的功能,而并不是某种客户端平台或技术。
Tier指代码运行的位置。Tier常指物理上的层次或一个物理层。或者可以这样说,Tier就是架构师让逻辑层运行的地方。
以前一直以为业务层只能应用在具体的某一物理层上,事实上,物理层的Tier与组织代码的Layer是有区分的,跨物理层的Layer只要适当在Layer混合层(Tier独立层)的代码中加以分离,仍然是可以达到良好的代码维护效果的。但个人感觉这并非推荐的模式。
关于是否推荐多物理层架构
物理层中一个层就表示一个需要穿过的边界,这个边界可能是进程的便捷也可能是计算机的边界。穿越边界的代价较高,一个估算比例是穿越便捷要比进程内部调用慢100倍左右。若需要通过网络访问,还要更慢一些。多物理层会导致整体性能的降低。
而有时又不得不需要多物理层。一个理由是需要支持外部产品,而外部产品需要自己的进程来运行;另一个理由是出于安全方面的考虑,运行于一个独立进程中的模块将会更容易被保护和访问。再者,多物理层架构具有可伸缩的特性,系统的组件可拆分至其他层并重复部署。
总之物理层的分层需要在系统性能与安全性、可伸缩性、容错性之间平衡。
在项目中遇到此类问题时,可将系统性能等综合考虑。在经历项目的同时发现,在同流程下,既有跨物理层通讯也有同物理层通讯的代码处理相当麻烦,两种形态的代码带来的可维护性极差,是否能够运用设计模式解决这一问题?
关于过程模式与对象模式
在业务层中,对其实现模式进行分解,可以分为过程模式与对象模式。
业务逻辑层被看作一系列相关的操作,系统需要执行的步骤被分割为更小的步骤,每一个步骤都用一个操作表示,这样的操作叫事务。在这个上下文中,事务是一个不可分割的逻辑操作,这个模式叫做事务脚本(Transaction Script) 。
另一种过程模式称之为表模块(Table Module)。表模块的设计角度仍是一系列事务,不过事务是按照数据分组的。操作被定义在表示表数据的对象上。我们使用表数据作为实体,组织方法。
对于对象模式,我们用一系列相互交互的对象来组织逻辑。最简单的对象模型看上去像是数据库表的数据模型,这里组成模型的对象就是数据库中的记录,并增加了一些额外的方法。这个模式叫做活动记录(Active Record)。抽象程度越高,与数据模型的距离也越大,这种高度抽象的模式叫做领域模型(Domain Model)。
![](https://images0.cnblogs.com/blog/237770/201402/092148596939460.png)
从上图中可得出结论,对于复杂度较低的逻辑,采用过程模式能够产生较好的实现,但随着逻辑复杂度的提升,程序的代价将变得很高。原因在于过程模式的编码虽然简单高效,但需要不断的重构以减小“意大利面代码”带来的危害,而对于大多数程序员来说,一旦代码逻辑结果实现,一定会对其置之不理,因此由领域驱动的面向对象的业务层代码便体现出相当大的优势。对于复杂逻辑的代码可维护性与拓展性均比过程模式强健。
在具体的项目中,普通的过程性逻辑是适用过程模式的,也是我最熟悉的,尤其是事务脚本;但对象模式却经历的较少,今后可在组炉等复杂逻辑中考虑是否可以改成对象模式,加上设计模式的合理应用,应该会对程序的可维护性与可扩展性有较大幅度的提升。