|
锁定老帖子 主题：架构更新
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-18
to kewan:
请你先看看这两本书： 1、《敏捷软件开发：原则、模式与实践》第11章 依赖倒置，Robert C. Martin 2、《Domain Driven Design》第6章 聚合，Eric Evans 然后我想你的大部分问题就不成问题了:) kewan 写道 你说的理由不足以证明服务层是画蛇添足。任何一个Domain Model不会只是考虑一个应用，它考虑的是在这个在这个domain下的logic。在具体的一个应用里，这些Logic是需要组织起来完成某项工作的，Service就是这个组织者。Facade模式我想我不用再提了吧。另外一个在Service和Facade之上可以组织事务。封装考虑的仅仅是指责吗？没有数据，如何会有职责？
“把逻辑组织起来”，其实事务层和操作层已经担负起了组织的作用，你说他们是服务层也可以。这只是名词上的差异，我想实质上并没有什么冲突。 |
| 返回顶楼 | |
|
发表时间：2005-03-18
关于DIP，jinfeng_Wang解释的很好。
jinfeng_Wang 写道 不过楼主在执行思想的过程中，这思想还不够彻底。
不是我执行不彻底，而是那个思想根本就有问题（就是一定要下层依赖上层的说法），凭什么要让业务层反过来依赖显示层？显示层调用业务层是很自然的事情，就让它依赖，没有必要生搬硬套，一招鲜吃遍天，DIP随便拿来乱用。这就是我说的“想让谁依赖谁，就让谁依赖谁”，依据什么来执行这个呢，就是设计的思想：以业务层为核心，既然它是核心，大家就都依赖它。 |
| 返回顶楼 | |
|
发表时间：2005-03-18
问个业务上的问题:
项目规模大吗? 业务逻辑复杂吗? |
| 返回顶楼 | |
|
发表时间：2005-03-18
中等
|
| 返回顶楼 | |
