有关领域对象

昨天和朋友讨论了一下领域对象相关的话题。目前，我们的系统是这样分层的：action-->service-->dao.  action和service、service和dao之间传递的是entity。他提出可以把service的一些操作，如对领域对象的增删改直接放到领域对象里。如此，原来的service.save(entity)变成了entity.save();这样更符合面向对象编程的说。在一些领域对象建模的书上有提到这样的设计，我的朋友觉得这样做在使用上也很方便。就此话题，讨论一下吧，大家。

这个问题其实很早以前就讨论过了，也就是是否应该在POJO中加入业务逻辑，使之成为BO的问题，你搜索一下历史帖子好了。我个人的观点是不应该加入的，gigix在他的blog也对这个问题产生过置疑。

方便在何处？
这样一来，每个entity都要去实现自己的save，load，find等

如果不加业务的话，这些entity不是和ms的DataSet一样的了？比如一个Account对象只表示数据，而全部操作要另一个对象代劳，那这二种形式其是是一样的：
对象版：

Account account = <<get an account>>;
account.setName("sun");;
AccountManager.update(account);;

非对象版：

Entity account = <<get an account>>;
account.setString("Name", "sun");;
AccountManager.update(account);;

只不过对象版从表面上看起来要好看一点，而实际上没多大好处，反而非对象版对于灵活性上要好一点（比如字段定制，动态显示等）。

回答是Negative !

在我目前所做过的项目里，把业务逻辑（当然你说的是持久逻辑，不过原理应该差不离）写进领域对象里以后出现以下问题：

1.逻辑僵化，无法更改。领域对象是整个程序的基石，改的话，伤筋动骨，改动会贯穿各个层面。在其间写入任何可能会变的逻辑都是自杀。

2.兼容性差。我用过WSAD的向导生成web service接口，结果它无法处理含有业务逻辑的领域对象，更无法在客户端生成有效的proxy。直到去除了所有除getter/setter方法以外的内容后才正常。

3.目前解决方案：领域对象全部使用极为简单的VO。其他需求通过wrapper模式外覆解决。

to monk：
我说上面的话不是指我在这些对象中加了业务，我从来就没加过，加了业务会把系统搞复杂了且难设计好（或是我还不懂如何作这样的设计）。我是指如果一个对象只当作存对象的值来用，还不如就做一个通用的类来管理一个对象的值（有如ms的DataSet），而ms就把这种做法很好的发挥了，比如窗体数据绑定就很好用啊，且数据源不一定是它的DataSet，你也可以自已做一个，什么方便就怎样啊）。这样的话如果要实现高度可定制的系统，可以有一个MetaData类描述这些对象有什么字段，字段的标题，类型，显示格式，实体之间的关系。。。，要加一个字段只要在MetaData和数据库里改一下就行了，代码不用改，因为显示会查询MetaData得到要显示的信息。

原来你说的是这个啊。

那用JDBC不就行了，不必自己做。ResultSet类完全符合你的标准，大不了再外加一个wrapper简化一下逻辑。

不过我觉得这不是什么主流做法。

呵呵，那你说主流的这种做法比之有何好处啊？把数据和操作分开好象有点又退回到过程设计了，失去了面向对象的一些好处（不过这个也有点难怪，毕劲设计一个信息处理系统和设计一个字处理程序差别太大了）。

恩...也不能说谁是主流吧。你当然可以省却对象/关系映射——要是你压根不需要把数据以对象的形式展现出来呢？比如需要在页面上显示一张跟数据库表一模一样的表？那就不必先O/R mapping再把对象拆开来。

各取所需。

问题是这样的对象根本算不上是一个合格的对象，只有数据的对象你说是一个正常的对象吗？顶多是一个贫血的对象。