请教一个设计上的问题?

我是来接分的 2013-03-28 05:03:40

最近在学习一个DDD的框架
在DDD中,Respository(资源库)封装获取对象引用的逻辑,即(CRUD)操作,属于基础设施层,

Service服务层应是很薄的一层,不应包含业务逻辑,

那么业务逻辑是应该放入领域层Entity中,使模型成为充血模型,在处理模型间调用关系时,是直接调用其他模型的Service,还是使要调用的模型成为调用模型的属性,即模型套模型?

目前我的做法是模型套模型,感觉很乱,如果直接调用其他模型的Service,所有的Service都是IOC配置注入的,这样的话又感觉不合理,感觉还不如在表现层controller中获取Service处理业务逻辑...

请教大神解惑
...全文
118 5 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
5 条回复
切换为时间正序
请发表友善的回复…
发表回复
wanghui0380 2013-03-28
  • 打赏
  • 举报
回复
当然如果要达到自动映射的目的,在理论上微软也给了一条路IQueryable 和linq provide基本就可以达到自动映射的目的,因为可以延迟决定,可以动态解析 但是(最讨厌的但是还是的出来)你不太可能为你自己的项目去单独构建一个linq provide,这个时间成本不划算,而且就单独项目构建的provide目标太具体了,也很难做到项目级别复用,所以意义不大!而通用的provide,微软自己有EF,linq2sql你又觉着不成还非要在外面套个什么模型和service
wanghui0380 2013-03-28
  • 打赏
  • 举报
回复
过于教条了,这东西千万别太教条了,
引用
Service服务层应是很薄的一层,不应包含业务逻辑
谁规定滴?你让写个规定的人自己试试看能不能行的通!!!
引用
那么业务逻辑是应该放入领域层Entity中,使模型成为充血模型,在处理模型间调用关系时,是直接调用其他模型的Service,还是使要调用的模型成为调用模型的属性,即模型套模型
这个根本无所谓,能玩成任务就好。 其实你两个问题根本就是一个问题,就是“视图映射”,无论是不是充血模型,在对外提供综合服务的时候,总免不了在对象和对象间做转换映射,现在的语言机制根本达不到自动映射的程度,所以你对外服务总是需要写一堆代码去手动映射过去,所以Service服务层在现有的语言机制下肯定不会是啥薄薄的一层,你肯定有一堆对象映射转换,重新封装的过程。在我看来现在的技术手段下,你在充血也达不到逻辑完备,并且能自动变换的效果,所以什么“Service服务层应是很薄的一层,不应包含业务逻辑”根本就是一句玩笑话
sunman 2013-03-28
  • 打赏
  • 举报
回复
夜色镇歌 2013-03-28
  • 打赏
  • 举报
回复
gxingmin 2013-03-28
  • 打赏
  • 举报
回复
直接模型调模型

62,243

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术交流专区
javascript云原生 企业社区
社区管理员
  • ASP.NET
  • .Net开发者社区
  • R小R
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。

希望和大家一起共同营造一个活跃、友好的社区氛围。

试试用AI创作助手写篇文章吧