[开发日志] 架构设计初步介绍

阅读更多

昨天应该完成业务分析的工作，但很无奈的是到写这篇日志的时候我们小组仍然没有完成这项工作。昨晚的额外开销的负面影响果然不小。
今天上午讲课部分的内容：先是让各组确认VSS帐户的建立和管理，让各组把业务流程分析的结果传到VSS上同步起来；再是点评昨天各组所做的分析。我们组被点评的是客户管理的部分。很可惜，看来并不合格。今天晚上我的任务就是把小组其他成员所做的分析与我负责的部分整合到一起，并修正其中的错误。啊，说起来我们组的VSS帐号结果也是我来创建和维护的；得让我们的支持经理少玩点流星花园多干点正经事才好，但又不知道该如何入手好。

下午的课程讲了一下本次项目会采用的架构。看来会参考非常经典的例子来展开： The .NET Pet Shop。主要的参考实现是Pet Shop 4.0，但参考架构是Pet Shop 3.0。LY老师说要在3.0采用的架构的基础上进行裁剪，让我感到有点困惑……说到底，Pet Shop 3.0的架构是典型的三层架构——表现层（presentation tier）、业务逻辑层（business logic layer）、数据访问层（data access layer）；这已经相当精简了，我想不到有什么理由还需要去精简，要说需要调整那或许还算合理。
表现层负责显示数据与获取用户输入，以ASP.NET Web表单实现，一般部署在IIS上；业务逻辑层负责处理领域相关的业务逻辑，以C#或VB.NET等实现，运行在CLR上；数据访问层处理数据持久化相关的操作，同样以C#或VB.NET等实现并运行在CLR上。在数据持久层以下就是数据库的连接器与数据库本身，不需要在系统内讨论。


这跟我相对熟悉的Java EE体系自然十分相似。很多东西只是换了个叫法，思想是一样的所以上手不算麻烦；像是中间的DAO，在MS体系中被分在了DAL里，后面由JavaBean表示的业务实体在MS体系中则是在Model模块中。
这么说来，应该简单看看这个架构下各个部分中有些什么对象，做些什么事，与Java EE中的术语又如何联系起来。
DBUtility是真正与数据库打交道的部分。里面有像是SQLHelper、OracleHelper等的工具类，其中实现了ExecuteNonQuery、ExecuteReader等方法，以具体的Connection/Command/Parameter来实现对数据库的访问。Pet Shop里的这些工具类对query操作会返回DataReader（而没有用DataSet），这在我们的设计中可以考虑改变一下。
Model中的对象主要是类似POJO（plain old/ordinary Java object）一般的skinny class，提供一个空构造器和一个全参数构造器，然后提供各个业务实体需要的字段和相应的属性。通常会与具体的表相对应。用于持久化的时候，Model中的对象被当作PO（persistent object）。
DAL中的自然是DAO（data access object）了。DAO用于封装对数据库的访问，但并不是直接与数据库打交道，而是通过调用DBUtility里的工具类来访问。对应每个Model里的类都有一个DAO，里面有各种操作所需要的SQL语句，并有诸如GetItemsByProduct等的方法去使用具体的SQL语句完成对数据库的操作。啊，不能忘记DAL层有IDAL模块来指定各DAO的接口，然后各个实际DAL实现会有对应的类去实现那些接口。具体加载哪个DAL实现可以在配置文件里配置，到运行时利用反射来加载。
BLL中的对象主要应该是BO（business object）——封装了业务逻辑的对象。Pet Shop里BLL中对应每个Model里的业务实体类都有一个类来处理业务……或许是因为业务逻辑很简单？
Web部分就是表现层，基本上就是页面和相关配置/资源，不应该混入业务逻辑。这里用于显示的数据的来源就是所谓VO（value/view object）

Pet Shop 4里还有些别的东西，像是几个Dependency和Strategy，这次不知道会不会用上。不过Membership的部分很可能会用。之前得Colorful大的提醒，接触到基于Membership实现的RBAC，确实很不错，看看能不能用进来。

===============================================

几个想记录的链接：
Microsoft .NET Pet Shop 3.x: Design Patterns and Architecture of the .NET Pet Shop
Microsoft .NET Pet Shop 4 架构与技术分析
对比.NET PetShop和Duwamish来探讨Ado.NET的数据库编程模式