Enterprise Application Achitecture Design Based on LiteMDA 0.5
简介：LiteMDA是Teddy正在设计的一个用于企业级应用开发的基于MDA、ORM、C# 2.0、.Net Framework 2.0、Microsoft Enterprise Library及部分AOP思想的Framework。从最初的设想到目前，听取了很多朋友（尤其是双鱼座和、idior）的批评、建议和探讨，剔除了最初设计中的许多理想化、不雅和目前的技术还不易实现的设计，基本上形成了一个完整的、比较优雅的构架。真的特别感谢这些朋友！在本文中，Teddy将向您简单介绍一个“Enterprise Application Achitecture Design Based on LiteMDA 0.5”，可以说是一个基于LiteMDA进行企业级应用开发的基本模式，当然，除了最完整的应用模式之外，我也会介绍在业务逻辑较简单情况下，怎样以简化模式使用LiteMDA来简化您的开发过程和极大的较少开发工作量。
1、Enterprise Application Achitecture Design Based on LiteMDA 0.5 Full Diagram
以上的模型中，带箭头的虚线表示package、component和其它节点间的依赖关系，线条间的关系有点复杂，我先从上到下，从UI开始做写简单介绍。
1) User Interface
对于UI来讲，它只需关心和调用四个方面的组件，分别是LiteMDA.Common(定义了LiteMDA中的通用接口和基类)、Custom Entities(用户的实体类，每个实体类必须继承自LiteMDA.Common.Entity，一般实体类及其对应的数据库表映射都可由LiteMDA提供的辅助工具，由UML Static Model自动生成)、LiteMDA.Domain(为Entity和Entity集合提供通用持久化支持)、Custom Service/Facade(用户的封装调用Business和Domain的Service/Facade类，下文会有更详细介绍)。
2) LiteMDA.Business
LiteMDA.Business主要提供了一个BusinessObjectFactory类，用于构造各种用户需要的Business Rules或者Business Domain Model等对象，Business Rules或Business Domain Model必须通过接口暴露给LiteMDA.Business，BusinessObjectFactory则基于EnterpriseLibrary.Configuration获取和构造被暴露的接口和类，并且提供运行时保持接口不变的情况下动态的改变Business Rules或Business Domain Model接口和实现类的映射的能力，即允许一定程度上的实时部署和更新。
3) LiteMDA.Domain
LiteMDA.Domain是整个Framework的ORM核心，为Entity和Entity的集合提供了类DomainObject<ObjectType>、DomainObjectCollection<ObjectType>，这两个范型类，其中范型参数ObjectType必须是继承于LiteMDA.Common.Entity的实体类，简单地以DomainObjeec<EntityType>的方式构造的类就能作为一个ActiveDomainObject为Entity提供持久化支持。
4) LiteMDA.Persistence
LiteMDA.Persistence中，PersistenceHelper类提供静态不包含任何SQL语义的Persistence接口给LiteMDA.Domain层调用，并通过Provider模式，使得具体的数据库操作对于LiteMDA.Domain完全透明且非常容易扩展。
5) EnterpriseLibrary.Configuration
EnterpriseLibrary.Configuration作为整个框架使用的配置模块，起着非常重要的作用，任意一个需要Configuration的层，如：LiteMDA.Business、LiteMDA.Domain、LiteMDA.Persistence等，都可以通过它或者非常便利的Configuration支持。并且，如果，您的应用中需要用到EnterpriseLibrary中的其它组件，也可以非常方便的通过EnterpriseLibrary.Configuration整合进来。
2、More About LiteMDA
以上只是从一个应用构架的角度简单介绍了一下LiteMDA的风貌，下面，则在说一点在以上的模型中看不到的东西。
1) MDA
LiteMDA中的MDA思想，主要体现在实体类和数据库表映射的根据UML Static Model(XMI格式输入)自动生成，用户可以在默认Configuration的基础上，添加自定义设置细颗粒控制实体类和数据库表的映射细节。
2) ORM Configuration Format
一般常见的描述ORM细节的配置文件，要么以像Hibernate这样每个类对应一个xml文件来定义，要么通过.Net 下的Custom Attribute，直接写在实体类中。
然而，LiteMDA中，Teddy将采用另一种方式，这种方式有点类似asp.net中的machine.config和web.config思想，即采用公共默认设置附以特殊设置的方式来定义。简单的说，对于LiteMDA中的一个实体类来讲，默认由工具从Model生成的实体类源码将不包含任何有关映射的配置信息、也不会同时生成一个描述映射的xml文件。此时，对该类的映射细节包括主键、字段属性映射，数据库字段类型等等，将直接采用默认配置。如果，您要更改其映射细节，则可以为其添加额外的配置信息从而覆盖默认映射配置。
这样做有几个非常大的好处：首先，不论对于用户还是代码生成工具，工作量都大大减少，且方便直接使用Framework生成的实体类；其次，还有一点更重要，就是，配置文将本身将是对生成工具非常友好的，考虑模型变更的情形，实体类和数据库结构都将重新自动生成，此时，对于上面提到的两种传统的方式来讲，所有自定义的映射细节将被覆盖，当然你可以事先作些备份，重新生成后再手动改回去，但是无疑是个十分讨厌和容易出错的过程，而LiteMDA的方案不会有这样的问题，因为，生成工具不需为每个类生成冗余的映射信息，用户自定义的细节修改绝对不会被覆盖，即使，模型的修改导致实体类结构的变化，对于用户自定义配置文件的修改，也已经被降至极低了，这一点对于需求变更飞快、迭代周期越来越短的开发现状，我想是非常有意义的。顺便再说一句，在LiteMDA的2.0以后的后续版本中，Teddy可能会再提供一个更加完美的ORM配置的方案，可以做到模型变更时自定义映射细节的零更改，大家可以猜猜我会怎么做。
3) ICondition
ICondition是什么呢？其实是LiteMDA中的用于持久化操作的OO语义的查询对象。作为如DomainObject<ObjectType>的Load、Update、Delete操作的参数。
LiteMDA中的ICondition同样将是非常有特色的，首先，在运行时，程序可以调用ICondition的接口动态构造任意的查询和排序条件，并且，对于用于Load而言可以为查询条件附加分页参数，及指定只返回符合条件的某一页数据；其次，ICondition的实现类中，同样将提供另一类实现，可以从自定义配置文件中、理论上甚至从外部环境，如webservice的，获取配置信息来构造查询条件。还有就是，对于常用的如LoadAll, LoadFirst等等常用的查询条件，LiteMDA将给你做一些预定义枚举。可以直接像这样调用，如：DomainObjectCollection<User>.Load(ConmonConditions<User>.LoadAllOrderByPk)将以实体类的主键属性正向排序并载入所有的User对象。
4) Simple Application Achitecture Based on LiteMDA
其实，从上面的完整构架图大家也能看到了，LiteMDA提供的框架本身是一个非常灵活和可插拔的结构，因此，无论是扩展还是简化都是很方便的。对于一类非常简单的应用来讲，不需要专门的Business Rules或Business Domain Model，甚至不需要Service/Facade层，此时，只需要直接利用LiteMDA.Domain为Entity提供ActiveDomainObject支持，用户要做的只是画一画UML，然后，用辅助工具生成Entity和数据库结构，此时，所有的Entity就已经具备持久化能力，接下来就只需要写UI就好了。就是对编程不很擅长的美工，只需弄懂UML，就可以非常方便的创建这样的程序。
3、Development Schedule and Status
基于第一个可运行版本LiteMDA v0.5的设计，目前大约完成了三分之一强的代码，但是基本上的构架已不会改动。已完成的有效代码使用“为了明天”的iCount统计行数：1009。这主要还是托了C# 2.0 的Generic支持以及使用了EnterpriseLibrary的福，代码量比预期的大大降低了。
