|
锁定老帖子 主题：是否应该让实体类具备丰富的业务逻辑？
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-23
frankensteinlin 写道 robbin 写道 frankensteinlin 写道 引用 而后面我举的那个deleteTopics来说，这个逻辑的实现是必须依赖持久化操作的(forumDao)，我们必须把forumDao.update方法调用挪到外面去(放在Manager,Server或者其他的什么里面) 也就是说 我认为应该把update方法放在里面， 为什么？看看order.getTotalAccount();方法没有持久化的帮助如何计算？
Class Order{
getTotalAccount();{
List tempItems=getItems();;//需要持久化方法的调用
.................
while ..............
total+=item.price();;
..........
return total;
}
}
] 这里并不需要持久化方法调用，因为tempItems本身就是Order的一个属性(有一个隐含的lazy loading) (有一个隐含的lazy loading)其实就是一次隐含的持久化的读取阿，如果没有hibernate 直接jdbc的话就更加明显了。SQL打印出来就是执行了一句sql. 其实就是隐藏了OrderDetailDAO.getItems();的操作阿。 所以说要做到对象间的导航肯定要用到持久化的操作，否则肯定要跳出来，使得业务操作不连贯 采用什么持久层框架产品，这是一个直接会影响到软件系统架构的问题。如果你采用JDBC来完成持久化，那么整个应用层和持久层的设计必然和你采用Hibernate完成持久化的系统设计有很大的不同。 我想我们讨论的一个隐含前提就是持久层框架ORM的采用（Hibernate，JDO）。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
Archie 写道 robbin 写道 引用 这个已经解释过了，domain object －－>DAO是单向依赖的。
在你的模型当中 public interface ForumDao {
public void updateForum(Forum forum);;
}
请看清楚了，DAO依赖不依赖domain object？至于 ForumDaoxxxImpl那就更不说了。 应该这样的： public interface Dao {
public void update(Object obj);;
}
public class DaoImpl implements Dao {
public void update(Object obj);
{
this.session.saveorupdate(obj);;
}
}
这不算依赖domain object吧。 不说什么了，这是狡辩了。实际项目的DAO接口可没有这么简单。别的不说，DAO接口的一个loadObjectByPrimaryKey你就没有办法抽象。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
robbin 写道 我想Martin的Domain Object的一个优点，或者说我主张的模型的一个缺点，partech最后已经指出来了。
作为Web应用程序员，他需要区分那些操作需要持久化(需要调用ForumService)，那些调用不需要持久化(直接调用Forum)，这可能是一个比较困难的问题，此外，万一Forum的一个业务逻辑方法由于需求变更，变得开始依赖持久化了，那么势必需要把该方法从Forum中挪到ForumService中去，这样的结果造成了Web层的应用程序不可避免的修改。 而如果是Marin的Domain Objecct模型，则直接修改Forum里面的实现代码，而不需要修改Web层代码。 :D 很高兴看到讨论终于有了结论. |
| 返回顶楼 | |
|
发表时间：2005-03-23
robbin 写道 Archie 写道 robbin 写道 引用 这个已经解释过了，domain object －－>DAO是单向依赖的。
在你的模型当中 public interface ForumDao {
public void updateForum(Forum forum);;
}
请看清楚了，DAO依赖不依赖domain object？至于 ForumDaoxxxImpl那就更不说了。 应该这样的： public interface Dao {
public void update(Object obj);;
}
public class DaoImpl implements Dao {
public void update(Object obj);
{
this.session.saveorupdate(obj);;
}
}
这不算依赖domain object吧。 不说什么了，这是狡辩了。实际项目的DAO接口可没有这么简单。别的不说，DAO接口的一个loadObjectByPrimaryKey你就没有办法抽象。 loadObjectByPrimaryKey(Class clazz,int id) 写个JDO实现
public Object loadObjectByPrimaryKey(Class clazz,int id);
{
Object oid=this.pm.newObjectIdInstance(clazz,new Integer(id););;
return pm.getObjectById(objId, true);;
}
|
| 返回顶楼 | |
|
发表时间：2005-03-23
Archie 写道 这个已经解释过了，domain object －－>DAO是单向依赖的。 呵呵，Archie我看这个你就别较真了，从数据库里面查询DomainObject的接口 你的返回值中一定会有DomainObject的。 
|
| 返回顶楼 | |
|
发表时间：2005-03-23
引用 采用什么持久层框架产品，这是一个直接会影响到软件系统架构的问题。如果你采用JDBC来完成持久化，那么整个应用层和持久层的设计必然和你采用Hibernate完成持久化的系统设计有很大的不同。 我想我们讨论的一个隐含前提就是持久层框架ORM的采用（Hibernate，JDO）。 也就是说在透明读取导航这些持久化的操作应该放入那个类（domain object 叫什么名字，实在搞不清除了。）这一点是一致了。 下面是否该讨论什么样的 持久化操作应该放在那个类的外面。由于持久化操作的都是那个类类面的属性，为什么要完全把它暴露出来呢？放在里面有透明的好处，放在外面是在看不出好处。减少依赖？不见得 （好的orm框架都有类似session的对象图的维护者 它save方法只要传入哦bject吧，似乎不需要具体的实体类） |
| 返回顶楼 | |
|
发表时间：2005-03-23
partech 写道 Archie 写道 这个已经解释过了，domain object －－>DAO是单向依赖的。 呵呵，Archie我看这个你就别较真了，从数据库里面查询DomainObject的接口 你的返回值中一定会有DomainObject的。  我试试
public interface Dao
{
Collection queryObjects(Class clazz,String filter);;
}
public Collection queryObjects(Class clazz,String filter);
{
Query query=this.pm.newQuery(clazz);;
query.setFilter(filter);;
return (Collection);query.execute();;
}
to partech: 你还没给我解释那个图呢。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
frankensteinlin 写道 引用 采用什么持久层框架产品，这是一个直接会影响到软件系统架构的问题。如果你采用JDBC来完成持久化，那么整个应用层和持久层的设计必然和你采用Hibernate完成持久化的系统设计有很大的不同。 我想我们讨论的一个隐含前提就是持久层框架ORM的采用（Hibernate，JDO）。 也就是说在透明读取导航这些持久化的操作应该放入那个类（domain object 叫什么名字，实在搞不清除了。）这一点是一致了。 下面是否该讨论什么样的 持久化操作应该放在那个类的外面。由于持久化操作的都是那个类类面的属性，为什么要完全把它暴露出来呢？放在里面有透明的好处，放在外面是在看不出好处。减少依赖？不见得 （好的orm框架都有类似session的对象图的维护者 它save方法只要传入哦bject吧，似乎不需要具体的实体类） 好了，frankensteinlin，这里你把它持久化的概念理解为对数据的变更（Insert/Delete/Update）就好了。查询则不再其中。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
不过对于把所有的逻辑(包括持久化服务)都塞到domain object里面我也有疑问。因为我们知道有一些逻辑他一定需要多个domain object互相协作完成的，那么这个时候这个逻辑究竟应该放在哪个domain object里面好呢？还是需要再弄一个TransactiionScript出来？ 而如何再弄一些TransactionScript出来的话，岂不是又会出现我前面说的问题吗？ Web程序员究竟该如何选择，调用TransactionScript类，还是调用domain object类？
这样考虑下来的结果，好像只有getter/setter的纯数据类反而最好？因为纯数据类就只映射数据库字段，数据库字段是不会轻易变动的，所以这样的实体映射类也最稳定。 |
| 返回顶楼 | |
|
发表时间：2005-03-23
Archie 写道 to partech: 你还没给我解释那个图呢。
好吧。不要把圆柱体的东西都理解为数据库好吗？ MartinFowler的意思是DomainObject也需要持久化啊。 |
| 返回顶楼 | |
