三层结构数据层如何设计

我想按三层结构设计系统，可是苦于数据层不知如何设计。
看了很多资料，微软的要求无状态，层间用记录集来传递，而J2EE好像要求有状态，层间用实体类传递。
谁有设计经验者，请多指教！！

　　大家都有同样的困惑，不过我认为用对象的方式可能要好些，因为：
　　1、数据库从关系型到对象型发展是趋势
　　2、微软在.net framework中提供了DataSet，可以同时装入多个异构的对象的数据，简单点说就是一个DataSet可以装多个ResultSet（java）的。但并不代表微软就在抵触对象式传递，事实上，好多工程设计时都是用对象传递的思想，即使用的是.net framework
　　3、用对象传可能使代码的可维护性更好
　　4、现在在ORMapping领域，有些公司已经有了很成熟的做法，比如中国的金蝶（他们的人自己说的，不知是否属实）。我认为数据集这个概念应该被淡化才对。
　　5、我在设计时，从没有考虑过用数据集传递，也可能是我的做法太单一，或者就有错误，各位不妨指正。

以上与你讨论，希望得到你的指正，大家共同进步。
谢谢你的回答！
　　1.我也认为使用对象可维护性更好，但使用记录集效率会高一些。因为按每个表对应一个对象，当使用多表操作时，效率难免差，但用记录集一个Sql语句可以返回多表的相关内容。
　　2.我看Net Framework的企业级例子Duwamish中使用的方法是用Dataset包含了数据，但没有用真正使用一个对象对应每个表，每个属性对应字段；并且所有的CRUD操作全是用存储过程，我觉得并不这么样。

共讨论，和你共进步

　　我没有研究过.Net framework中的例子，可能微软这么做有他的考虑，但我体会不到其中的好处。
　　另个，我有些想法跟你的不太一样，大家交流一下。
　　首先，表和对象并没有严格的一对一关系，并非一个表对应一个对象，虽然大多数时候是这样的，但会根据具体的逻辑，可能会有一些特殊的设计，比如事务...
　　其次，用记录集比用对象的效率高不了多少。虽然用对象的方式好象与数据库的交互次数据多了，效率会降低。其实不然，更多的是理解和实现上感觉用对象方式会比数据集差，但实际的低层的数据操作量是相同的，只是表现方式不同。对象方式如果处理好了connection的问题，效率不会比数据集方式慢很多。
　　最后，如果系统涉及的峰值访问不是很大的话，效率的权重就比可维护性低多了。毕竟，硬件的发展比软件快，加根内存的成本比修改软件低。
　　不知你是如何考虑的.

我把自己的想法写出来和大家讨论。
1。我觉得要讨论的问题，不屎瞎槟晌枚韵蠡故鞘菁诙嗖憬峁怪写菔荨Ｒ蛭锹技涫狄彩嵌韵螅琋ET中的DataSet,J2EE中ResultSet和RowSet,都封装成对象了。
２。J2EE中，记录集对象和实体对象的区别为：记录集对象是通用的，可以操作不同表结构中取出来的数据，而实体对象基本上只对应特定的表结构，可以做些通用方面的设计，但是通用性方面的改进是很有限的。
３。我在设计时主要使用记录集对象。感觉这样做不用管具体结构的表结构，系统相对简单，而且在表结构做调整时，系统相关部分基本不用改动，而表结构的细微调整，在开发过程中很难避免。

有些想法，想与楼上的讨论一下：
1）用DataSet/ResultSet传递数据的确在开发的过程中很省事，将可能的变化封装到参数中了，但是，如果从分析、开发、维护、升级的过程链来看，这样做是危险的。这样，控制层、甚至表现层的设计都要清楚传过来的黑盒里都装了些什么，在数据层就没有完成对数据的封装，也很难做到面向接口的编程，实际的编程还是面向数据的。开发阶段省了事，日后升级、扩展还是要去了解数据表结构，要是前后都不是同一组(个)人做，那后面的人不会很愿意面对这种局面。我认为，数据层尽量将对数据库的操作封装好，传到控制层时的就全是逻辑的东西（当然，不绝对），控制层要的是一个定单，数据层传一个盒子然后说“在里面，自己找！”。将dataset传到控制层，建议越少越好。
2）可能楼上的不太同意我的说法，不妨讨论，欢迎指出我的错误。

如果业务内容比较复杂,且面临必然的升级和改变,就需要定义业务实体对象,以及数据规则层.

数据存取层的出口参数是业务实体对象,可供业务层使用.

数据存取层的进口不直接对业务层开放,而只对数据规则层,业务层存/修改事务使用数据规则层针对业务实体对象开放的相应方法.

比较赞成将数据层按业务对象分。

我正在学习用那种构架设计系统，可惜的是微软公司提供结构
我看了J2EE中的EJB就是将数据层按业务对象分，也就是实体Bean和会话Bean。
我想是否可以在Net中模仿一下，在数据层抽象出用业务实体，层和层间用业务实体传递。

我一直想找这样的例子，那位高手有过这样的设计经验和设计想法，请指教！

　　我曾经用C#为深圳一家贸易公司设计过一个系统，不妨描述一下，大家来讨论一下是否有不妥的地方。
　　系统分内部系统和外部（网页），重点是内部系统，用C＃写的application,在设计时，使用了MVC思想，层间传递80%是对象方式，在设计中，业务层不会直接面对数据层，甚至调用对象层也不是直接的，是经过在对象层上抽象出的组接口(interface)进行的，这种设计在开发的后期起到了很好的效果，每个Use Case的实现几乎是同构，程序员看看自己的代码就知道别人的程序结构，很整齐(都是一个人分析设计的，当然整齐)，整合的时候很轻松。
　　这种设计有个风险，如果对象的封装类没有经过严格的测试，那效果就相反了，可能会花更多的时间，这点上，我的方法用牺牲人力的方法确保质量的，不知各位有没有好的可操作性强的方法。
　　另外，传对象的方式使程序员从字段中解脱出来，可以大大节省时间，当你的共享对象达到一定数量的时候，这个效果特别明显。
　　如果用.net设计，一定要处理好connection的问题，尽量让同步相关的对象共享一个连接句柄，不要让每个对象都创建一个，或者n个对象都共用一个，这是我得到的教训。

　　即使是对象集，我认为也不应该用结果集，可以用hash、map、vector等将结果封装起来，传递出去。我觉得因为逻辑的复杂而牺牲整体的设计是不值得的，但大多数程序员都喜欢这种做法，因为这样可以省事。
不知道我的坚持是不是固执？

　　另外有个问题问一下上铺的兄弟，你是不是金蝶的说客（＾_^,玩笑），据我所闻，ORMapping领域的研究进展不大，oracle都为之头痛，金蝶真的“做得不错”？

　　是，我也认为用HASH，VECTOR等封装，但用RS能省，就省点吧
　　另，我不是金蝶的说客，见过演示，还没实际用过，印象很深。当然感觉上还只是单个对象的MAPPING，对象层次结构可能是不行，说实话，配合他们的BOS框架，开发还是能省很多事的。要找个机会，用用才行。

作者：linchangping 转贴自：www.umlchina.com