手动DAL & BLL诉ORM

Question

哪种方法更好：1)使用第三方ORM系统还是2) 手动编写DAL和BLL代码来处理数据库？

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

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

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

是否值得使用ADO Entiry Framework？

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

我想了解一下，你的个人经历，：你在你的项目中使用哪种方法，哪种更好？

谢谢。

Answer 1

也许两者都有一点是合适的。您可以使用像SubSonic这样的产品。这样，您就可以设计数据库，生成DAL代码(删除所有无聊的东西)，使用部分类对自己的代码进行扩展，如果愿意的话可以使用存储过程，并且通常可以完成更多的工作。

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

我还想指出，我认为通过尝试不同的方法，看看什么对你最有效，你走上了正确的道路。我认为这最终是你答案的来源。

Answer 2

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

首先，考虑一下这背后的历史。早在60年代和70年代初，我们就有了使用分层和网络模型的DBMSes。使用这些链接有点痛苦，因为在查询它们时，您必须处理所有的检索机制:在各地记录之间跟踪链接，并处理链接不是您想要的链接的情况(例如，您的特定查询指向了错误的方向)。因此，Codd提出了关系DBMS的概念:指定事物之间的关系，只在查询中说明您想要的内容，让DBMS处理检索它的机制。一旦我们有了几个很好的实现，数据库的家伙们都非常高兴，每个人都转向它，整个世界都很开心。

直到OO的人进入了商业世界。

OO人员发现了这种阻抗不匹配:业务编程中使用的DBMSes是关系型的，但在内部OO人员使用链接(引用)存储东西，并通过确定他们必须遵循和遵循的链接的细节来发现事物。是的:这本质上是一种分层或网络DBMS模型。因此，他们投入了大量(通常是独创性的)努力，将这个层次/网络模型重新分层到关系数据库上，偶然地抛弃了RDBMSes给我们带来的许多优势。

我的建议是学习关系模型，在合适的情况下设计系统(经常是这样)，并使用RDBMS的功能。您将避免阻抗不匹配，您通常会发现查询很容易编写，并且您将避免性能问题(例如ORM层需要数百个查询来完成它应该在其中执行的任务)。

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

Answer 3

最近，我决定在一个新项目中使用Linq到SQL，我真的很喜欢它。它是轻量级的，高性能的，直观的，并且有很多微软的专家(和其他的)关于它的博客。

Linq的工作方式是从数据库中创建c#对象的数据层。DevExpress XPO向相反的方向工作，为C#业务对象创建表。实体框架应该以任何一种方式工作。我是个数据库专家，所以为我设计数据库框架的想法没有多大意义，尽管我看到了它的吸引力。

我的Linq项目是一个中等规模的项目(数百名，甚至数千名用户)。对于较小的项目，有时我只使用SQLCommand和SQLConnection对象，直接与数据库对话，效果很好。我还使用SQLDataSource对象作为CRUD的容器，但这些容器似乎很笨重。

项目规模越大，DALs就越有意义。如果它是一个web应用程序，我总是使用某种DAL，因为它们对SQL注入攻击、更好地处理空值等有内置保护。

我讨论了是否在我的项目中使用实体框架，因为微软说这将是他们未来数据访问的解决方案。但是EF对我来说是不成熟的，如果你在StackOverflow中搜索实体框架，你会发现有几个人正在为小而迟钝的问题而挣扎。我想第2版会好得多。

我对nHibernate一无所知，但有些人喜欢它，不愿使用其他任何东西。