＋设为首页 ＋添加到收藏夹
1.实体A，对应数据库中的一条记录，根据对象B的一些属性，可以生成A，我想问的是，如果我在做其它业务方法的时候，可能需要大量引用A的某些属性才执行某些操作，甚至要改变A的某些属性，或是需要一些属性的某种组合后的结果。
我想问的是，A是否有必要封装成一个对象，提供一些个性的功能？在.net里，有DataValue(在java里类似javabean)表示数据库中的一条记录，也算是对其进行了封装，但是使用DataValue(javabean)的方式，其不能直接返给上级对象B实际需要的A的某些属性的的组合的功能，也不能自己生成自己，而需要上级对象B自己分别去组合！可能这里把A封成对象似乎有些麻烦，甚至简单到有些不必要，但是我觉得对跟A有关的操作可以都被封装在A的对象中，方便编码和调试，何乐而不为呢？
2.还有业务实体和数据库实体如何理解和区分？
来者有分,我来领分,帮你顶!
1。不是很清楚，你需要举例说明，感觉你的设计也许有问题
2。参考我的blog:
http://blog.joycode.com/saucer/archive/2005/07/05/58520.aspx
DTO所承载的数据必然都是业务逻辑所需要的。如果这些数据的结构变了，业务逻辑能不变吗？这种关联不能认为就是耦合
在思归给的那个blog链接里，第三种方法说了Flower/PEAA的Domain Model，这就是数据和行为合二为一的做法。这也是个不错的方法。不过这里的实体不完全和某个具体业务对应，而是和领域概念对应。这和PetShop/Duwamish的做法大相庭径。
to progra：
实体是由英文Entity翻译过来的，只是说到Business Entity则一般所指的就是数据载体DTO。
>>> 而我说要再把实体封成对象的意思是我需要得到的不是简单返回的数据库某条记录，而是记录里某些字段组合后的更有意义的结果，而这个结果希望可以是某个对数据库中的记录封装后的对象返回给我的
嗯，我明白你的意思了。这个我也不好说，因为毕竟把所有的东西都封装起来，可能没有必要。但是那种表达了某种领域概念的数据，又经常被使用，则最好封装起来。
这种耦合因为分层是按平行划分造成，如果纵向的划分呢，是不是可以把耦合降低呢？
