关于封装Ado.net的问题,在线等，急，拜托了！！！！！！！

[legend-never-die]

现在有一个问题,麻烦各位给些意见

情况是这样的，我们公司有个项目，和另一公司合作，他们公司有个这种要求:与数据表交互的对象模型的构造必须从BasicObject 类模块继承过来,操作数据库必须通过DataManager来操作，如Open,Insert,Update等，不允许我们直接使用Ado.net，说用他们的效率更高。

我对此极为不满，要求直接使用ADO.Net，各位认为如何，还请赐教！！！

急~~

[chnking]

分层的好处上面都说了,直接用ado.net也说不上有什么不好,不过项目大了,还是分开的好.

[raingod]

p

[stuhome]

你可以将这些insert,update,delete做成一个WebService接口,然后大家相安无事，各用各的。

[legend-never-die]

又，那个BasicObject还有DataManager都是他们公司的东西，他们一直是这样开发，但这个项目是我们公司自己用的项目，和他们公司没有任何关系，只是用他们公司的程序员一起开发

[acewang]

要求看看他们的代码

[chnking]

这是他们公司自己做的一个数据访问层，软件项目采用多层结构会有很多好处，结构清晰，开发效率高，部署灵活等等。
要是你们自己没这方面的考虑，使用他们的数据访问层也是好事

[CMIC]

可以给他们出个难题，要求他们开放BasicObject、BasicObject源代码，看看源代码这么样，如果好用也无所谓，还可以学些东西，如果不好自然就有了不用的理由。

[jackie615]

[ZT]
chnking(kent)：这是他们公司自己做的一个数据访问层，软件项目采用多层结构会有很多好处，结构清晰，开发效率高，部署灵活等等。
要是你们自己没这方面的考虑，使用他们的数据访问层也是好事

[seesea125]

用他们的对你来说增加不少难度把，用他们的同时要求开放他们的源码，自己可以学习，而且出问题知道哪里的原因，要不然干脆拒绝算了

[blackcatiii]

合作开发就不能随心所欲了，呵呵。
关键是他们的东西是否提供了足够的接口，能满足你们项目的需要，比如事务处理，多表操作等。如果能满足那用他们的也无所谓，毕竟出了问题就很容易知道是谁的错。我个人感觉如果你们自己写程序最好也不要直接操作ADO.NET，还是封装起来通过接口访问的好，这样系统耦合度能降低很多，而且可复用性也强，关键是接口要设计好。

[blackcatiii]

源码他们不给你也应该知道是怎么回事，所以看不看也问题不大，实在想看而人家不给也可以找个工具把他的dll解开来，推荐用Anakrino，专为.net度身定做的，不要太方便哦，我甚至可以看看System.Data是怎么写出来的：），但也有缺憾，就是对局部变量只能看到local1,local2等，还有就是继承关系看不出来。

[legend-never-die]

直接用Ado.net有什么不好?

[blackcatiii]

to joise(卓一思_我爱VC&.Net):
直接用Ado.net的话你的代码和你的设计思想就只限于该项目，如果再做其他项目你又不得不从头再来，再一个个的写添加、修改、删除、查询的sql语句，虽然是功能多了些，但也很辛苦的说。如果你的项目比较大的话，大家都可以随便用ADO.NET操作数据库，很难确保没有任何人犯错。而且如果客户突然说我不想用这个数据库了，你就吐血去吧：）
把ADO.NET封装起来还是有必要的，我最近就在研究，想写个通用的中间件来，实现类似EJB的CMP的功能，不过太复杂了，以前也没做过大项目，感觉有些力不从心，不知道有没有人熟悉这方面的。