随笔-19  评论-186  文章-2  trackbacks-8

      昨天介绍了ORM部分,由于Linq的用词不当,可能引起了部分人的误解,在些道歉。这里所说的Linq 仅仅只是Linq To Sql,切记切记。只是针对ORM处理部分。
      在开始介绍业务层之前,再重提一下旧事吧。我的ORM是在2005年初开始设计的,在8月份,正式在项目里面开始使用,那时候Vs2005还在Beta1,一段时间之后才发布Beta2,当时还是冒了很大的风险的。因为项目启动的比较早,当时,哪里有现在这么多的资源?一切都是原创的,没有什么资料文档可以借鉴的。所有的完善、升级,都是经过项目之后,把经验教训加进来的。
其实ORM就是把关系与对象实现映射,提供简单的增删改查罢了,中间根据需要做一些优化罢了,最终还是为了方便业务逻辑的组织。在我的ORM里面,是把存储过程映射成类的,对于可变查询、多数据库支持,也是在后期才加进去的。特别是多数据库支持,刚开始根本就没有解决的思路,不能把连接写死,又不能改变编程模型,又要统一配置,对于程序员是透明的。举个夸张一点的例子,对于主从结构(通常主从结构不会存在不同的数据库),主表可能在一个数据库内,从表可能保存在另外一个数库内,编程的时候,程序员不知道,也不关心,单库与多库的代码是完全一样的,仅仅是配置文件的不同。对于客户端,当然更是透明的,连服务层都不知道数据的具体保存位置,实现了编程模型的统一。
说了那么多,下面把业务层的框架作一大致的介绍。
      业务层,我这里叫BO,也是业务对象了。通常一个对象包含数据与方法,我业务层里数据与方法是分开的,第一个版本是合在一起的。分为Data与Service两个相关的类,对于Data里,包含一个Protected的Meta,就是Entity,Data把需要公开的属性公开出来就是Data的对外成员属性了,另外,工具还根据键关联的关联因也同时生成了,对于关联类,这里没有用通常的属性处理方式,要加进来的话,难度倒没有什么。

Code


Data是通过泛形实现的,主要是为了方便继承的处理了。他与Service配合。主要的变化是在Service。
上面为手工添加的主从结构处理代码。
下面为工具生成的部分

[Unie2e.Common.Model.E2EBOAttribute("Province")]
    
public class ProvinceService<T> : POSService<T,ProvinceEntity> where T:E2EData<ProvinceEntity> ,new ()
    
{
        
protected override T DataConvert(ProvinceEntity input)
        
{
            T t 
= new T();
            t.Meta 
= input;
            
return t;
        }

        
        
自动生成的Actionr操作
        
        
自动生成的查询方法