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

  这应该是一个算是古老的话题了,我想在这里面重新的提一下,希望能跟园子里朋友交流交流。看园子里很多都是交流具体的技术,交流思想的倒是相对比较少,希望大家能够一起热闹热闹,给我扔砖头。
  前几篇帖子只是介绍了一下我的框架。特别是对ORM是采用自己的、NHIBENATE、LINQ TO SQL等,有采用LINQ TO SQL的N个理由,也有不采用其的N个理由,其中重要的一条就是因为业务逻辑的组织。
  说到业务逻辑代码的组织,也就涉及到领域模型的与代码映射的组织问题。按照Java的说法,我的第一个应用是充血型领域模型,现在的应用是贫血型领域模型,并且把很多接口全部去掉。
  对于简单的基本逻辑通过基于泛形实现,并把对业务实体数据的CRUD操作放在单独Service 里,每一个Data都对应着一个Service。Data里只有基本的get/set操作和与之关联的关联、自身验证等处。
  


        
关联父对象Field
        
        
public City()
        
{
        }

        
        
public City(CityEntity meta) : 
                
base(meta)
        
{
        }

        
        
关联父对象Property

       
public City()
        
{
        }

        
        
public City(CityEntity meta) : 
                
base(meta)
        
{
        }

        
        
映射属性
        
       
}

每一个业务对象都有一个相关的Service与之对应

[Unie2e.Common.Model.E2EBOAttribute("City")]
    
public partial class CityService : CityService<City>
    
{
    }

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

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