哪种方法更好：1)使用第三方 ORM系统或2) 手动编写 DAL 和 BLL 代码以使用数据库？
1)在我们的一个项目中，我们决定使用 DevExpress XPO ORM 系统，但我们遇到了很多小问题，浪费了我们很多时间。amd 仍然时不时会遇到来自这个 ORM 的问题和异常，我们对这个“黑匣子”还没有完全的了解和控制。
2)在另一个项目中，我们决定从头开始编写 DAL 和 BLL。虽然这意味着要多次编写无聊的代码，但这种方法被证明更加通用和灵活：我们可以完全控制数据在数据库中的保存方式，如何从中获取数据等。所有的错误都可以以直接和简单的方式进行修复。
哪种方法通常更好？也许问题只是我们使用的 ORM（DevExpress XPO），也许其他 ORM 更好（例如 NHibernate）？
是否值得使用ADO 整体框架？
我发现 DotNetNuke CMS 使用自己的 DAL 和 BLL 代码。其他项目呢？
我想了解您的个人经历：您在项目中使用哪种方法，哪种方法更可取？
谢谢你。
我个人的经验是，ORM 通常完全是在浪费时间。
首先，考虑这背后的历史。早在 60 年代和 70 年代初，我们就有这些 DBMS 使用分层和网络模型。这些使用起来有点麻烦，因为在查询它们时，您必须处理所有检索机制：跟踪各处记录之间的链接，并处理链接不是您想要的链接的情况（例如，为您的特定查询指向错误的方向）。所以 Codd 想到了关系 DBMS 的想法：指定事物之间的关系，在查询中只说你想要的，然后让 DBMS 处理找出检索它的机制。一旦我们有几个很好的实现，数据库人员就喜出望外，每个人都转向它，整个世界都很开心。
直到 OO 人进入商业世界。
OO 人员发现了这种阻抗不匹配：业务编程中使用的 DBMS 是关系型的，但 OO 人员在内部存储了带有链接（引用）的东西，并通过找出他们必须遵循的链接的细节并遵循它们来找到东西。是的：这本质上是分层或网络 DBMS 模型。因此，他们投入了很多（通常是巧妙的）努力，将分层/网络模型分层回到关系数据库，顺便丢掉了 RDBMS 给我们的许多优势。
我的建议是学习关系模型，在合适的情况下围绕它设计系统（经常如此），并使用 RDBMS 的强大功能。您将避免阻抗不匹配，您通常会发现查询易于编写，并且您将避免性能问题（例如您的 ORM 层需要数百个查询来完成它应该做的事情）。
在处理查询结果时需要完成一定数量的“映射”，但如果您以正确的方式考虑它，这很容易：结果关系的标题映射到一个类，并且关系中的每个元组都是一个对象。根据您需要的进一步逻辑，为此定义一个实际的类可能值得，也可能不值得；只需处理从结果生成的哈希列表就很容易了。只需浏览并处理列表，做你需要做的事情，你就完成了。
也许两者都适合。您可以使用像 SubSonic 这样的产品。这样，你可以设计你的数据库，生成你的 DAL 代码（删除所有无聊的东西），使用部分类来用你自己的代码扩展它，如果你愿意，可以使用存储过程，并且通常可以完成更多的事情。
我就是做这个的。我发现这是自动化和控制之间的正确平衡。
我还要指出，通过尝试不同的方法并查看最适合您的方法，我认为您走在正确的道路上。我认为这最终是您答案的来源。
最近我决定在一个新项目上使用 Linq to SQL，我真的很喜欢它。它是轻量级的、高性能的、直观的，并且在微软（和其他人）的博客中有很多关于它的大师。
Linq to SQL 通过从数据库创建 c# 对象的数据层来工作。DevExpress XPO 的工作方向相反，为您的 C# 业务对象创建表。实体框架应该以任何一种方式工作。我是一名数据库专家，因此为我设计数据库的框架的想法没有多大意义，尽管我可以看到它的吸引力。
我的 Linq to SQL 项目是一个中型项目（数百，可能有数千名用户）。对于较小的项目，有时我只使用 SQLCommand 和 SQLConnection 对象，直接与数据库对话，效果很好。我还使用 SQLDataSource 对象作为CRUD的容器，但这些看起来很笨重。
您的项目越大，DAL 就越有意义。如果它是一个 Web 应用程序，我总是使用某种 DAL，因为它们具有针对 SQL 注入攻击、更好地处理空值等的内置保护。
我争论过是否在我的项目中使用实体框架，因为微软表示这将是他们未来数据访问的首选解决方案。但是我觉得 EF 不成熟，如果你在 StackOverflow 上搜索 Entity Framework，你会发现有几个人在为小而迟钝的问题苦苦挣扎。我怀疑第 2 版会好很多。
我对 nHibernate 一无所知，但有些人喜欢它并且不会使用其他任何东西。
您可以尝试使用 NHibernate。由于它是开源的，因此它并不完全是一个黑匣子。它非常通用，并且有许多扩展点供您插入自己的附加或替换功能。
NHibernate 是一个真正的ORM，因为它允许您在任意域模型（类）和任意数据模型（表、视图、函数和过程）之间创建映射。你告诉它你希望你的类如何映射到表，例如，这个类是映射到两个连接表还是两个类映射到同一个表，这个类属性是否映射到多对多关系等。 NHibernate 期望您的数据模型大部分被规范化，但它不需要您的数据模型与您的域模型精确对应，也不会生成您的数据模型。
NHibernate 的方法是允许您编写任何您喜欢的类，然后告诉 NHibernate 如何将这些类映射到表。没有要继承的特殊基类，没有所有一对多属性都必须具有的特殊列表类，等等。NHibernate 可以在没有它们的情况下发挥它的魔力。事实上，您的业务对象类根本不应该对 NHibernate 有任何依赖。您的业务对象类本身绝对没有持久性或数据库代码。
您很可能会发现您可以对 NHibernate 使用的数据访问策略进行非常精细的控制，以至于 NHibernate 也可能是您复杂案例的绝佳选择。但是，在任何给定的上下文中，您可以随意使用 NHibernate 或不使用它（支持更定制的 DAL 代码），因为 NHibernate 在您不需要它时会尽量不妨碍您。因此，您可以在一个 BLL 类（或方法）中使用自定义 DAL 或 DevExpress XPO，并且可以在另一个中使用 NHibernate。
我最近参加了一个足够大的有趣项目。我没有从一开始就加入它，我们必须支持已经实现的架构。对所有对象的数据访问是通过存储过程实现的，并在 .NET 上自动生成返回 DataTable 对象的包装方法。这种系统的开发过程非常缓慢且效率低下。我们必须为每个查询在 PL/SQL 上编写庞大的存储过程，这可以用简单的 LINQ 查询来表达。如果我们使用 ORM，我们的项目实施速度会快几倍。而且我没有看到这种架构的任何优势。
我承认，这只是一个不太成功的项目，但我得出以下结论：在拒绝使用 ORM 之前，请三思，你真的需要这样的灵活性和对数据库的控制吗？我认为在大多数情况下，浪费时间和金钱是不值得的。
正如其他人所解释的那样，ORM 存在一个根本性的困难，这使得大多数时候没有现有的解决方案能够很好地做正确的事情。这篇博文：计算机科学的越南与我的一些感受相呼应。
执行摘要类似于对象模型和关系模型之间不兼容的假设和优化。尽管早期的回报很好，但随着项目的进展，ORM 的抽象不足，而且围绕它工作的额外开销往往会抵消成功。
我已经在 Delphi 中使用 Bold四年了。它很棒，但它不再出售，并且缺少数据绑定等一些功能。继任者ECO拥有这一切。不，我不是在销售 ECO 许可证或其他东西，但我只是觉得遗憾的是，很少有人意识到 MDD（模型驱动开发）可以做什么。能够在更短的时间和更少的错误中解决更复杂的问题。这很难衡量，但我听说过 5-10 更有效的开发。当我每天使用它时，我知道这是真的。
也许一些以数据和 SQL 为中心的传统开发人员会说：
好...
如果您想尽可能快地加载表的 10000 个实例，使用存储过程可能会更好，但大多数应用程序不这样做。Bold 和 ECO 都使用简单的 SQL 查询来加载数据。性能高度依赖于加载一定数量数据的数据库查询次数。开发人员可以通过说这些数据属于彼此来提供帮助。尽可能高效地加载它们。
当然可以记录实际执行的查询以捕获任何性能问题。如果你真的想使用你的超优化 SQL 查询，只要它不更新数据库就没有问题。
有许多 ORM 系统可供选择，特别是如果您使用 dot.net。但老实说，做一个好的 ORM 框架是非常非常困难的。它应该集中在模型周围。如果模型发生变化，更改数据库和模型依赖的代码应该是一件容易的事。这使它易于维护。进行小而多的更改的成本非常低。许多开发人员错误地以数据库为中心并围绕它进行调整。在我看来，这不是最好的工作方式。
更多应该尝试ECO。只要模型不超过12个班级，就可以无限次免费使用。你可以用 12 节课做很多事情！
我建议您使用 Code Smith Tool 来创建 Nettiers，这对于开发人员来说是一个不错的选择。