|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-25
七彩狼 写道 这并没有解决我的疑惑，我的问题是，象这类依赖数据库查询的 Logic ，是放在 Manager 内合适，还是放在 Domain Model 内合适。
我觉得应该放入，Domain Model 内更适合，因为这种业务校验，也的确属于 Domain Logic 的范畴。 ??你指的依赖于数据库查询的逻辑是什么意思？ 不是指调用DAO接口吗？ 既然DomainModel<------>DAO接口，是双向依赖。那也就是说 DomainModel的对象是可以调用DAO接口的，不是吗？ 不太清楚你疑惑在哪里？ 
|
| 返回顶楼 | |
|
发表时间：2005-03-25
七彩狼 写道 这并没有解决我的疑惑，我的问题是，象这类依赖数据库查询的 Logic ，是放在 Manager 内合适，还是放在 Domain Model 内合适。
我觉得应该放入，Domain Model 内更适合，因为这种业务校验，也的确属于 Domain Logic 的范畴。 呵呵，知道问题在哪里了。 你说的Manager是Service层的对象吧？ 我说的Manager可是业务层的对象，是DomainModel的对象勒。 Manager是我上面说的模型中的1.1.控制对象。 |
| 返回顶楼 | |
|
发表时间：2005-03-25
引用 我提出的原则是：看业务方法是否显式的依赖持久化。
Item的placeBid这个业务逻辑方法没有显式的对持久化ItemDao接口产生依赖，所以要放在Item中。请注意，如果脱离了Hibernate这个持久化框架，Item这个domain object是可以进行单元测试的，他不依赖于Hibernate的持久化机制。它是一个独立的，可移植的，完整的，自包含的域对象。 在Robbin的第二种模型中，提出了如上的观点。 我也是在第二种模型的基础上，来提出疑问和进行讨论的。 按上面的观点 Domain Model <------- DAO Interface 应该是这样的一种依赖关系，而不是双向的。 |
| 返回顶楼 | |
|
发表时间：2005-03-25
七彩狼 写道 引用 我提出的原则是：看业务方法是否显式的依赖持久化。
Item的placeBid这个业务逻辑方法没有显式的对持久化ItemDao接口产生依赖，所以要放在Item中。请注意，如果脱离了Hibernate这个持久化框架，Item这个domain object是可以进行单元测试的，他不依赖于Hibernate的持久化机制。它是一个独立的，可移植的，完整的，自包含的域对象。 在Robbin的第二种模型中，提出了如上的观点。 我也是在第二种模型的基础上，来提出疑问和进行讨论的。 按上面的观点 Domain Model <------- DAO Interface 应该是这样的一种依赖关系，而不是双向的。 ？？为什么DomainObject不能依赖DAOInferface？叫Domain Object精确点。 |
| 返回顶楼 | |
|
发表时间：2005-03-25
引用 Service层对象是单独的一层，它不属于业务层，它包裹着业务层。
在我的模型中业务层的对象包括 1.业务对象： 1.1.业务控制对象； 1.2.业务实体对象； （上面两类对象如果站在足够的高度其实是一类对象） 2.业务层调用其它服务需要的接口和封装接口的相关对象。持久化接口（例如UnitOfWork接口，DAO的接口，封装接口的Repository对象）只是其中之一。 我来按 Partech 的方式，统一一下名词，好进一步讨论。 Service - 不属于业务层，它包裹着业务层； Manager - 业务控制对象； 可能会依赖持久化接口。 Domain Object - 业务实体对象；不与任何持久化或查询相关的。 To Partech ，我上面的理解对么？ |
| 返回顶楼 | |
|
发表时间：2005-03-25
引用 引用 1.“DomainModel的持久化与封装”； 2.“大数据量操作”； 我在前面提到过，我对模型2还存在一些疑惑，这便是其中的一个。 我将这类问题，称为“大数据量操作”问题，这个名字不是很恰当，希望能有人给出更好的表达方式。 这类问题的特点是，单个 Domain Object 内的 Domain Logic ，实际上是依赖 整个 Domain Object 集合的。 就上面Item的例子来讲，Item是否符合自身的校验规则，是需要依赖所有的 Item 的。即当判断这个 Item 是否合法时，我们需要查找所有的 Item 来进行相关的校验。 这类问题，应该是 Domain Logic 的一部分。放在 Service 之内，似乎并不适合。 但我们现在有需要尽量是 Domain Logic 最少甚至不依赖与 DAO ，我们该怎么办？ |
| 返回顶楼 | |
|
发表时间：2005-03-25
七彩狼 写道 我来按 Partech 的方式，统一一下名词，好进一步讨论。
Service - 不属于业务层，它包裹着业务层； Manager - 业务控制对象； 可能会依赖持久化接口。 Domain Object - 业务实体对象；不与任何持久化或查询相关的。 To Partech ，我上面的理解对么？ 业务实体对象属于DomainObject的一种可以同DAO接口相关。 业务控制对象也是DomainObject的一种可以同DAO接口相关。 但是我这里持久化概念可能和你理解的不一样。 持久化分为两种变更数据的，查询数据的。 变更数据的通过UnitOfWork接口实现，查询数据的通过不同的XXXXFinderDAO接口实现。 没有必要限制DomainObject对DAO接口的依赖关系，因为DomainObject在 概念上本来就有持久化的状态。去看看DDD里面关于Life Cycle Of Domain Object 的论述，里面讲到了DomainObject的状态变化，你的疑惑就该没有了。 |
| 返回顶楼 | |
|
发表时间：2005-03-25
partech 写道 七彩狼 写道 我来按 Partech 的方式，统一一下名词，好进一步讨论。
Service - 不属于业务层，它包裹着业务层； Manager - 业务控制对象； 可能会依赖持久化接口。 Domain Object - 业务实体对象；不与任何持久化或查询相关的。 To Partech ，我上面的理解对么？ 业务实体对象属于DomainObject的一种可以同DAO接口相关。 业务控制对象也是DomainObject的一种可以同DAO接口相关。 但是我这里持久化概念可能和你理解的不一样。 持久化分为两种变更数据的，查询数据的。 变更数据的通过UnitOfWork接口实现，查询数据的通过不同的XXXXFinderDAO接口实现。 没有必要限制DomainObject对DAO接口的依赖关系，因为DomainObject在 概念上本来就有持久化的状态。去看看DDD里面关于Life Cycle Of Domain Object 的论述，里面讲到了DomainObject的状态变化，你的疑惑就该没有了。 ORM工具是实现了UnitOfWork接口的，或者说是实现了类似的接口，呵呵。 |
| 返回顶楼 | |
|
发表时间：2005-03-25
七彩狼 写道 七彩狼 写道 对于上面我所提到的第三类DomainLogic，也就是需要依赖到复杂查询的Logic。
我们究竟是应该将其当做 业务逻辑 放在 Manager 之内呢？ 还是应该将其当做 Domain Logic 放在 Domain Model 之内呢？ 我个人认为，就上面的例子来说 Item.Name 不能有重复，应该是 Domain Logic 的一部分。也就是说，这种 logic 应该是放入 Domain Model 之内，才更为合理。 但如果将查询操作，置入 Domain Model 之内，似乎又与我们的初衷不符合，Domain Model 不应该依赖于 DAO 。 小板凳中，等待着Robbin和Partech对如上问题的解惑。。。  。。。item的name能不能重复这个业务逻辑并不是一个只和item对象本身有关的domain logic，你想想看，你怎么判断name重复不重复呢？ 你当然只能拿这个domain object和其他同类型的domain object相对比，这样才能判断？所以这个业务逻辑很明显的需要多个domain object参与协作，因此他不是domain logic，而是business logic，应该放在业务逻辑层，而不是domain object里面。这里有一个很确定的原则：logic是否只和这个object的状态有关，如果只和这个object有关，就是domain logic；如果logic是和一批domain object的状态有关，就不是domain logic，而不是business logic。 |
| 返回顶楼 | |
|
发表时间：2005-03-25
应该说partech的观点是最符合Martin Fowler在POEAA中描述的模型的，但是我并不完全同意Martin Fowler的模型，我认为这种模型过于理想化，在实际项目中，会显得很罗嗦冗余，例如使用UnitOfWork来改变对象状态，使用QueryObject处理查询，又有Servier，Manager，Mapper等等等等。
在实际项目中我们需要简化，需要把一概完善理想的模型和实际具体的情况综合起来考虑和权衡，得到一个总体而言最实用有效的模型，经过我自己的实践摸索，我认为我提出的第二种模型的第一种变体是最实用的。 其实我提倡的这种模型也是主要参考了Rod Johnson的意见，特别是without EJB第10章。我总觉得纯粹的理论模型在实际项目中一定会根据具体情况进行修改了，我现在的实践下来，在你采用Spring/Hibernate架构的情况下，Rod Johnson的意见是最实用的。 |
| 返回顶楼 | |
