关于多层开发中的问题--实体层设计

Question

我在设计时会有很多想法，好头疼啊；借贴参考一下大家的设计或开发经验：一、我的代码中大概会有三种实体，请问大家也是这样吗？
1、与数据库表一一对应实体
2、提供给界面显示的实体，（这种可能就是N个表中的不同字段组合在一起）。
3、查询条件有时候也作为一个类。（为了统一接口）
二、大家的实体是否有增、删、改自己的能力。
我之前的系统里实体的增、删、改大部分都是放在业务层里的。我现在觉得放在业务层里不好，一个简单的添加自己操作得NEW一个实体，还得NEW自己的业务对象，再把实体传给业务对象。我想请问有人这样作吗？请大家多发言啊关于第二项。来者有分。

Answer 1

还有个问题，如果用的ORM模型之后，，大家还自己写实体层吗？如果考虑到扩展或者数据库可能更换，我觉得应该还是要写实体层。

Answer 2

我觉得ORM得到的object应该和显示的object分开。ORM得到的object只是从关系数据库的几个表中合成出来的，是很简单的数据模型。而在应用逻辑中使用的object可能需要具有更加复杂的结构，会有更多的附加信息。所以两者不能等同。
从另一个角度想，如果在程序里面到处都用ORM得到的object，那么如果ORM需要更换的话，改动可就太大了。
当然，这取决于你的系统有多大有多复杂了，如果只是很简单的东西，把两者合在一起也还好。

Answer 3

界面字段太多的话,不用实体,直接用DataTable也未尝不可.如果界面一种实体,业务一种实体的话,还要花功夫建立对应关系也不爽.实体层和业务层分开也是有一定道理的.因为分层的原则就是要可替换.如果实体把维护自己的东东放在一块儿,耦合性太强.
再说,在有远程数据传输或异种系统交换数据的场合,不含任何业务逻辑的"纯实体"应该是最适合的.

Answer 4

我有点不明白你说的“二”，对object的增加删除修改难道不是业务层的事情么？

Answer 5

把业务逻辑中需要用到的实体提取出来，然后再实体层写好这些实体的CRUD