entity-framework - 手动 DAL & BLL 与 ORM

Question

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

1) 在我们的一个项目中，我们决定使用 DevExpress XPO ORM 系统，我们遇到了许多浪费我们大量时间的小问题。 amd仍然时不时会遇到来自这个ORM的问题和异常，我们对这个“黑匣子”还没有完全的理解和控制。

2) 在另一个项目中，我们决定从头开始编写 DAL 和 BLL。虽然这意味着要多次编写枯燥的代码，但事实证明这种方法更加通用和灵活:我们可以完全控制数据在数据库中的保存方式、如何从数据库中获取数据等。而且所有的错误都可以以直接和简单的方式修复。

哪种做法一般是更好 ?也许问题仅在于我们使用的 ORM(DevExpress XPO)，也许其他 ORM 更好(例如 NHibernate)？

是否值得使用 ADO 完整框架 ?

我发现 DotNetNuke CMS 使用自己的 DAL 和 BLL 代码。其他项目呢？

我想获取有关 的信息您的亲身经历 :您在项目中使用哪种方法，哪种方法更可取？

谢谢你。

Answer 1

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

首先，考虑这背后的历史。早在 60 年代和 70 年代初，我们就拥有使用分层和网络模型的这些 DBMS。这些使用起来有点麻烦，因为在查询它们时，您必须处理所有检索机制:跟踪各处记录之间的链接，并处理链接不是您想要的链接的情况(例如，针对您的特定查询指向错误的方向)。因此 Codd 想到了关系 DBMS 的想法:指定事物之间的关系，在您的查询中只说您想要的内容，然后让 DBMS 处理找出检索它的机制。一旦我们有了几个很好的实现，数据库人员就喜出望外，每个人都转向它，世界很高兴。

直到面向对象的家伙进入商业世界。

OO 人员发现了这种阻抗不匹配:业务编程中使用的 DBMS 是关系型的，但 OO 人员在内部使用链接(引用)存储事物，并通过找出他们必须遵循和遵循哪些链接的详细信息来找到事物。是的:这本质上是分层或网络 DBMS 模型。因此，他们投入了大量(通常是巧妙的)努力将分层/网络模型分层回关系数据库，顺便丢掉了 RDBMS 给我们的许多优势。

我的建议是学习关系模型，围绕它设计你的系统(如果它合适的话)(经常是这样)，并使用你的 RDBMS 的强大功能。您将避免阻抗不匹配，您通常会发现查询易于编写，并且您将避免性能问题(例如您的 ORM 层采用数百个查询来完成它应该做的事情)。

在处理查询结果时需要进行一定量的“映射”，但是如果您以正确的方式考虑，这很容易:结果关系的标题映射到一个类，并且关系中的每个元组都是一个对象。根据您需要什么进一步的逻辑，为此定义一个实际的类可能值得也可能不值得；只需处理从结果生成的哈希列表就足够容易了。只需浏览并处理列表，做你需要做的事情，你就完成了。