最近在学习一个DDD的框架
在DDD中,Respository(资源库)封装获取对象引用的逻辑,即(CRUD)操作,属于基础设施层,Service服务层应是很薄的一层,不应包含业务逻辑,那么业务逻辑是应该放入领域层Entity中,使模型成为充血模型,在处理模型间调用关系时,是直接调用其他模型的Service,还是使要调用的模型成为调用模型的属性,即模型套模型?目前我的做法是模型套模型,感觉很乱,如果直接调用其他模型的Service,所有的Service都是IOC配置注入的,这样的话又感觉不合理,感觉还不如在表现层controller中获取Service处理业务逻辑...请教大神解惑

解决方案 »

  1.   

    过于教条了,这东西千万别太教条了,
    谁规定滴?你让写个规定的人自己试试看能不能行的通!!!这个根本无所谓,能玩成任务就好。其实你两个问题根本就是一个问题,就是“视图映射”,无论是不是充血模型,在对外提供综合服务的时候,总免不了在对象和对象间做转换映射,现在的语言机制根本达不到自动映射的程度,所以你对外服务总是需要写一堆代码去手动映射过去,所以Service服务层在现有的语言机制下肯定不会是啥薄薄的一层,你肯定有一堆对象映射转换,重新封装的过程。在我看来现在的技术手段下,你在充血也达不到逻辑完备,并且能自动变换的效果,所以什么“Service服务层应是很薄的一层,不应包含业务逻辑”根本就是一句玩笑话
      

  2.   

    当然如果要达到自动映射的目的,在理论上微软也给了一条路IQueryable 和linq provide基本就可以达到自动映射的目的,因为可以延迟决定,可以动态解析但是(最讨厌的但是还是的出来)你不太可能为你自己的项目去单独构建一个linq provide,这个时间成本不划算,而且就单独项目构建的provide目标太具体了,也很难做到项目级别复用,所以意义不大!而通用的provide,微软自己有EF,linq2sql你又觉着不成还非要在外面套个什么模型和service