简介: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的福,代码量比预期的大大降低了。