在数据库实体层中，我想加入一些方法，如addUser之类的东西，这样做是否层次关系就乱了？

Question

to : lrxz(九月鹰飞.Net)
谢谢您的回答。我想问得是这样是否合适，而且现在我的水平还不能做为数据层组件。
因为我的同事是做数据实体层，这样有一个如addUser,delUser之类的功能到底应该由谁来做呢？再次感谢!

Answer 1

如果你的层是按功能来划分的话，就最好不要把这些数据访问的方法加在里面比如说你开始写了个USER的实体类，里面写了个ADDUSER的方法，（数据库用SQL SERVER）现在你要在另一个系统中复用这个类的话，就会要改很多地方（数据库用ORACLE）

Answer 2

与数据库交互的方法都应该在数据层完成。
你可以用.net Remoting,外层（表现层）即.aspx,中间逻辑层（接口）定义一系列方法，里层数据层是这些方法的具体实现，这样你就可以通过.net Remoting的接口来操纵数据库了！

Answer 3

看看MS的PETSHOP3。0，和Duwamish 7.0
你就明白了

Answer 4

我是看了.net自带的duwamish7.0的例子，才会有这样的疑问。
我刚才说得不太清楚，书中是叫业务实体层。就是把employee,user，order这些都抽象成一个实体。

Answer 5

如果你的addUser方法控制数据实体类的方法，建议你最好将它单独放在一层中，这样既可以使层次的关系很清楚，还能降低层和类耦合度，提高代码重复利用率，便于后期进行维护。

Answer 6

其实可以这么来做
addUser,delUser之类的功能到底都用实体类来实现
按对象操作不涉及数据库的操作
然后对应每个需要操作数据库的类
做个Proxy类来实现操作数据库
让实体类和Proxy类继承同一个接口
可以考虑看一个设计模式的Proxy

Answer 7

谢谢各位，经过又一次的分析，已经决定将业务实体层与数据库的操作分开，就象duwamish7中那样，谢谢大家的帮助！