数据层如何设计
　

---

我想按三层结构设计系统，可是苦于数据层不知如何设计。
看了很多资料，微软的要求无状态，层间用记录集来传递，而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.ECC模式
看了这篇文章，我才发现，我们公司前辈们设计的有点类似ECC模式；
2.微软公司《设计数据层组件并在层间传递数据 》
文章中极力反对一个表对应一个对象，我觉得有道理。

这二篇文章都在中国微软上有

大家有没有看过这二篇文章，和对对象持久化，有好的设计方法
请多多发表意见》

 回复: 数据层如何设计
　

---

我把自己的想法写出来和大家讨论。
1。我觉得要讨论的问题，不适合归纳为用对象还是数据集在多层结构中传递数据。因为记录集其实也是对象，NET中的DataSet,J2EE中ResultSet和RowSet,都封装成对象了。
２。J2EE中，记录集对象和实体对象的区别为：记录集对象是通用的，可以操作不同表结构中取出来的数据，而实体对象基本上只对应特定的表结构，可以做些通用方面的设计，但是通用性方面的改进是很有限的。
３。我在设计时主要使用记录集对象。感觉这样做不用管具体结构的表结构，系统相对简单，而且在表结构做调整时，系统相关部分基本不用改动，而表结构的细微调整，在开发过程中很难避免。

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

当然，如果业务逻辑很简单，自然就不需要实体对象，直接用记录集对象就可以了。反之，在数据存取层（Data Access)以上就应该用业务实体对象了。

 《设计数据层组件并在层间传递数据》是.NET下的不可不读的文章。
　

---

对在.NET下开发的很多有关数据层访问、控制、管理、维护等问题，在该文中已做了全面、深刻描述。
在一定程度上，可以说，它是解决该相关问题的规范性的问题。

但是要提醒一点的是：它是在微软的.NET平台上，这一点很重要。

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

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

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

 回复: 数据层如何设计
　

---

大概看了一遍《设计数据层组件并在层间传递数据》
超级好文。
但是比较同意使用实体对象传递数据。
因为DataSet太重了，自己设计的实体对象可能刚刚比较好的满足自己的性能和业务逻辑上的需求。
另外自不依赖平台和厂商也很重要

如果是单个对象，当然是用实体类好。如果是对象集，目前还是用结果集好。
不过相信在这几年内，OO数据库应有大的发展

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

---

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

我正在学习用那种构架设计系统，可惜的是微软公司提供结构
我看了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框架，开发还是能省很多事的。要找个机会，用用才行。

ECC模式
这篇文章在那里，我搜索了一下，找不到，能给各连接码？