请问一个设计上的有关问题
请教一个设计上的问题？
最近在学习一个DDD的框架
在DDD中，Respository(资源库)封装获取对象引用的逻辑，即（CRUD）操作，属于基础设施层，
Service服务层应是很薄的一层，不应包含业务逻辑，
那么业务逻辑是应该放入领域层Entity中，使模型成为充血模型，在处理模型间调用关系时，是直接调用其他模型的Service，还是使要调用的模型成为调用模型的属性，即模型套模型？
目前我的做法是模型套模型，感觉很乱，如果直接调用其他模型的Service，所有的Service都是IOC配置注入的，这样的话又感觉不合理，感觉还不如在表现层controller中获取Service处理业务逻辑...
请教大神解惑
------解决方案--------------------
直接模型调模型
------解决方案--------------------
过于教条了，这东西千万别太教条了，
谁规定滴？你让写个规定的人自己试试看能不能行的通！！！
这个根本无所谓，能玩成任务就好。
其实你两个问题根本就是一个问题，就是“视图映射”，无论是不是充血模型，在对外提供综合服务的时候，总免不了在对象和对象间做转换映射，现在的语言机制根本达不到自动映射的程度，所以你对外服务总是需要写一堆代码去手动映射过去，所以Service服务层在现有的语言机制下肯定不会是啥薄薄的一层，你肯定有一堆对象映射转换，重新封装的过程。在我看来现在的技术手段下，你在充血也达不到逻辑完备，并且能自动变换的效果，所以什么“Service服务层应是很薄的一层，不应包含业务逻辑”根本就是一句玩笑话
------解决方案--------------------
当然如果要达到自动映射的目的，在理论上微软也给了一条路IQueryable 和linq provide基本就可以达到自动映射的目的，因为可以延迟决定，可以动态解析
但是（最讨厌的但是还是的出来）你不太可能为你自己的项目去单独构建一个linq provide，这个时间成本不划算，而且就单独项目构建的provide目标太具体了，也很难做到项目级别复用，所以意义不大！而通用的provide，微软自己有EF，linq2sql你又觉着不成还非要在外面套个什么模型和service
最近在学习一个DDD的框架
在DDD中，Respository(资源库)封装获取对象引用的逻辑，即（CRUD）操作，属于基础设施层，
Service服务层应是很薄的一层，不应包含业务逻辑，
那么业务逻辑是应该放入领域层Entity中，使模型成为充血模型，在处理模型间调用关系时，是直接调用其他模型的Service，还是使要调用的模型成为调用模型的属性，即模型套模型？
目前我的做法是模型套模型，感觉很乱，如果直接调用其他模型的Service，所有的Service都是IOC配置注入的，这样的话又感觉不合理，感觉还不如在表现层controller中获取Service处理业务逻辑...
请教大神解惑
------解决方案--------------------
直接模型调模型
------解决方案--------------------
过于教条了，这东西千万别太教条了，
谁规定滴？你让写个规定的人自己试试看能不能行的通！！！
这个根本无所谓，能玩成任务就好。
其实你两个问题根本就是一个问题，就是“视图映射”，无论是不是充血模型，在对外提供综合服务的时候，总免不了在对象和对象间做转换映射，现在的语言机制根本达不到自动映射的程度，所以你对外服务总是需要写一堆代码去手动映射过去，所以Service服务层在现有的语言机制下肯定不会是啥薄薄的一层，你肯定有一堆对象映射转换，重新封装的过程。在我看来现在的技术手段下，你在充血也达不到逻辑完备，并且能自动变换的效果，所以什么“Service服务层应是很薄的一层，不应包含业务逻辑”根本就是一句玩笑话
------解决方案--------------------
当然如果要达到自动映射的目的，在理论上微软也给了一条路IQueryable 和linq provide基本就可以达到自动映射的目的，因为可以延迟决定，可以动态解析
但是（最讨厌的但是还是的出来）你不太可能为你自己的项目去单独构建一个linq provide，这个时间成本不划算，而且就单独项目构建的provide目标太具体了，也很难做到项目级别复用，所以意义不大！而通用的provide，微软自己有EF，linq2sql你又觉着不成还非要在外面套个什么模型和service