手动DAL＆amp; 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层需要花费数百个查询来执行它应该在其中执行的操作）。

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

Answer 2

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

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

我还要指出，我认为你通过尝试不同的方法并看到最适合你的方法走在正确的道路上。我认为这最终是你答案的来源。

Answer 3

最近我决定在一个新项目中使用Linq to SQL，我真的很喜欢它。它轻巧，高性能，直观，并且在微博（和其他人）上有很多关于它的博客。

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

我的Linq to SQL项目是一个中型项目（数百甚至数千名用户）。对于较小的项目，有时我只使用SQLCommand和SQLConnection对象，并直接与数据库对话，效果良好。我还使用SQLDataSource对象作为CRUD的容器，但这些看起来很笨拙。

DAL更有意义，你的项目越大。如果它是一个Web应用程序，我总是使用某种DAL，因为它们具有针对SQL注入攻击，更好地处理空值等内容的内置保护。

我讨论了是否为我的项目使用实体框架，因为微软表示这将成为他们未来数据访问的首选解决方案。但EF对我来说感觉不成熟，如果你搜索StackOverflow for Entity Framework，你会发现有几个人正在努力解决小而钝的问题。我怀疑版本2会好得多。

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

Answer 4

您可以尝试使用NHibernate。由于它是开源的，它不完全是一个黑盒子。它非常通用，它有许多扩展点，可以插入您自己的附加或替换功能。

评论1：

NHibernate是一个 true ORM，它允许您在任意域模型（类）和任意数据模型（表，视图，函数和过程）之间创建映射。您可以告诉它您希望如何将类映射到表，例如，此类是映射到两个连接表还是两个类映射到同一个表，此类属性是否映射到多对多关系等。 NHibernate希望您的数据模型大部分都是标准化的，但它不要求您的数据模型与您的域模型精确对应，也不要生成您的数据模型。

评论2：

NHibernate的方法是允许你编写你喜欢的任何类，然后告诉NHibernate如何将这些类映射到表。没有特殊的基类可以继承，没有特殊的列表类，所有的一对多属性都必须等等.NHibernate可以在没有它们的情况下实现它的魔力。实际上，你的业务对象类根本不应该对NHibernate有任何依赖。您的业​​务对象类本身绝对没有持久性或数据库代码。

你很可能会发现你可以对NHibernate使用的数据访问策略进行非常精细的控制，以至于NHibernate也可能是你复杂案例的最佳选择。但是，在任何给定的上下文中，您可以自由地使用NHibernate来使用它（支持更多自定义的DAL代码），因为NHibernate会在您不需要时尽量不妨碍它。因此，您可以在一个BLL类（或方法）中使用自定义DAL或DevExpress XPO，并且可以在另一个BLL类中使用NHibernate。

Answer 5

我最近参加了一个足够大的有趣项目。我从一开始就没有加入它，我们不得不支持已经实现的架构。对所有对象的数据访问是通过存储过程实现的，并且在.NET上自动生成了返回DataTable对象的包装器方法。这种系统的开发过程非常缓慢且效率低下。对于每个查询，我们必须在PL / SQL上编写大量存储过程，这可以用简单的LINQ查询表示。如果我们使用了ORM，我们将实现项目的速度要快几倍。我认为这种架构没有任何优势。

我承认，这只是一个特别不成功的项目，但我得出以下结论：在拒绝使用ORM三思之前，你真的需要这样的灵活性和对数据库的控制吗？我认为在大多数情况下，不值得浪费时间和金钱。

Answer 6

正如其他人所解释的那样，ORM存在一个根本性的困难，即在大多数情况下，没有现成的解决方案可以很好地做正确的事情。这篇博文：The Vietnam Of Computer Science回应了我对此的一些看法。

执行摘要与对象和关系模型之间不兼容的假设和优化有关。虽然早期的回报是好的，但随着项目的进展，ORM的抽象不足，而解决它的额外开销往往会抵消成功。

Answer 7

我已经使用了Bold for Delphi四年了。它很棒，但它不再销售，它缺乏数据绑定等功能。 ECO继任者拥有这一切。 不，我不是在销售ECO许可证，但我只是觉得很少有人意识到MDD（模型驱动开发）可以做什么。能够在更短的时间内解决更复杂的问题，减少错误。这很难衡量，但我听说过5-10个更高效的开发。每天我都在使用它，我知道这是真的。

也许一些以数据和SQL为中心的传统开发人员说：

1. “但是性能怎么样？”
2. “我可能无法控制运行什么SQL！”

嗯...

1. 如果要尽快加载10000个表的实例，最好使用存储过程，但大多数应用程序不这样做。 Bold和ECO都使用简单的SQL查询来加载数据。性能高度依赖于数据库加载一定数量数据的查询数。开发人员可以通过说这些数据彼此属于帮助。尽可能装入它们。

2. 当然可以记录执行的实际查询以捕获任何性能问题。如果你真的想要使用超优化的SQL查询，只要它不更新数据库就没问题。

有许多ORM系统可供选择，特别是如果你使用dot.net。但老实说，做一个好的ORM框架非常困难。它应该集中在模型周围。如果模型发生变化，则更改数据库和依赖于模型的代码应该是一项简单的任务。这使其易于维护。进行少量但很多变化的成本非常低。许多开发人员错误地以数据库为中心并围绕数据库进行调整。在我看来，这不是最好的工作方式。

更应该尝试ECO。只要模型不超过12个班级，就可以免费使用无限时间。你可以用12节课做很多事情！

Answer 8

我建议您使用Code Smith Tool创建Nettiers，这对开发人员来说是个不错的选择。