手动DAL和BLL与ORM

Question

哪种方法更好:1)使用第三方ORM系统或2) 手动编写DAL和BLL代码以使用数据库？

1)在我们的一个项目中,我们决定使用DevExpress XPO ORM系统,我们遇到了许多浪费了很多时间的轻微问题.Amd仍然不时遇到来自这个ORM的问题和例外,我们对这个"黑匣子"没有充分的理解和控制.

2)在另一个项目中,我们决定从头开始编写DAL和BLL.虽然这意味着编写无聊代码很多次,但这种方法被证明更加通用和灵活:我们可以完全控制数据在数据库中保存的方式,从中获取数据等等.所有的错误都可以以直接和简单的方式固定.

哪种方法一般更好？也许问题只是我们使用的ORM(DevExpress XPO),也许其他ORM更好(比如NHibernate)？

是否值得使用ADO Entiry Framework？

我发现DotNetNuke CMS使用自己的DAL和BLL代码.其他项目怎么样？

我想获得有关您个人经历的信息:您在项目中使用哪种方法,哪种更好？

谢谢.

Answer 1

我个人的经验是,ORM通常是完全浪费时间.

首先,考虑一下这背后的历史.早在六十年代和七十年代初期,我们就使用了分层和网络模型这些DBMS.这些使用起来有点痛苦,因为在查询它们时你必须处理所有检索机制:跟踪整个地方的记录之间的链接,并在链接不是你想要的链接时处理这种情况(例如,指向您的特定查询的错误方向).所以Codd想到了关系DBMS的想法:指定事物之间的关系,比如在你的查询中只说你想要的东西,让DBMS处理找出检索它的机制.一旦我们有了几个很好的实现,数据库人员大喜过望,每个人都切换到它,世界很高兴.

直到OO人员进入商业世界.

二OO家伙发现这个阻抗不匹配:在业务程序使用的是的DBMS关系,但内部的OO家伙存储与链接(引用)的东西,并找出其中的链接,他们只好跟着并按照它们的细节中发现的东西.是的:这实际上是分层或网络DBMS模型.因此,他们将许多(通常是巧妙的)努力分层,将层次/网络模型重新分解到关系数据库,从而摒弃了RDBMS给予我们的许多优势.

我的建议是学习关系模型,如果它是合适的(它经常是),围绕它设计你的系统,并使用你的RDBMS的力量.您将避免阻抗不匹配,您通常会发现查询易于编写,并且您将避免性能问题(例如您的ORM层需要花费数百个查询来执行它应该在其中执行的操作).

在处理查询结果时需要进行一定量的"映射",但如果以正确的方式考虑它,这很容易实现:结果关系的标题映射到类,并且关系中的每个元组都是一个对象.根据您需要的进一步逻辑,可能或可能不值得为此定义实际类; 只需要处理从结果生成的哈希列表就可以了.只需通过并处理清单,做你需要做的事情,你就完成了.

Answer 2

也许两者兼而有之.您可以使用像SubSonic这样的产品.这样,您可以设计数据库,生成DAL代码(删除所有无聊的东西),使用部分类使用您自己的代码扩展它,如果您愿意,可以使用存储过程,并且通常可以完成更多的工作.

我就是做这个的.我发现它是自动化和控制之间的正确平衡.

我还要指出,通过尝试不同的方法,看看什么最适合你,我认为你走在了正确的道路上.我认为这最终是你答案的来源.