Question

我之前一直在使用Microsoft Enterprise Library，因为它被标记为抽象数据访问，而不是编写我自己的DAL。最初我只是将一个文件（sqlhelper.cs）导入到我的项目中，但后来的版本要求我引用整个dll，除非我想在删除我想要的功能方面投入大量的工作。

我假设在.NET 4.0发布几个月后将发布新版本的Enterprise Library。我公司对库的使用可能与传统用途不同，我们为许多客户设计和开发Web和Windows应用程序。我们要么将完成的项目交给内部开发人员维护，要么是小型客户端，我们将维护应用程序。

由于业务的性质，我有幸在设计新应用程序时“从头开始”大量时间，而不是与更新相同的代码库相关联。如果我们再次使用Microsoft Enterprise Library，下一个项目我可能会问自己同样的问题吗？我们只使用数据访问块，它似乎在开发过程中节省了时间。与此同时，我想知道通过使用对象为项目添加了多少开销和复杂性。

提前感谢您的建议。

更新

这里的讨论确实让我重新考虑了这个问题 - 它可能不是关于访问存储过程的轻量级抽象，而是关于为什么我们仍然依赖于N-Tier模型的更大的架构问题。

如果归结为应用程序中使用的数据库，请告诉我。在经典的3层/ N层世界中，数据库是公司信息的独立存储。不同的应用程序（Web，桌面等）都共享和访问公共存储平台。在这种情况下，存储过程是有意义的，因为它们充当各种应用程序和表之间的抽象层。

对于其他项目，数据库是较大应用程序的独占持久存储。 UI或其他类型的访问（包括Web服务，远程处理等）需要通过应用程序的BLL。由于我们业务的性质，这是我们更常开发的方案。

鉴于这个结论，我将创建两个原型项目，一个使用SubSonic，另一个使用LINQ。虽然我担心LINQ的开销和丢失保真度，但是数据访问所需代码的显着减少以及我们开发的项目类型的一致性，值得一看。

Answer 1

所有数据访问层都有其上下两侧。作为承包商，我遇到了各种各样的项目。我个人开始的每个项目，我都使用了调用S'procs的企业库数据访问块。起床和跑步都很快，但不止于此：我对它非常熟悉。当然，缺点是你必须编写的代码量。

我最近参与的一些项目正在使用LINQ / PLINQO。虽然编辑器的支持很棒，它为你创建了大部分代码，但我对飞行数据库更改的生存能力并没有留下深刻的印象，也没有给你留下深刻的印象，你必须跳过它才能获得不错的性能。

老实说，你应该分道扬and并尝试新的东西。这是找到每种类型陷阱的唯一方法，并且能够做出明智的决定，决定你想要哪种工具。

Answer 2

企业库并不全是坏事，但数据块并不是那么好。因此，请保留企业库的大部分内容。另请注意：现在正在重写大部分企业库，包括数据访问块 http://www.pnpguidance.net/Post/EnterpriseLibrary50UnityConfiguration.aspx

但是对于数据访问，您应该查看Entity Framework，Linq To SQL（它还没有死）或NHibernate（请查看SummerOfNHibernate.com）。

在EntLib之外，您可能还会看一下Prism。

Answer 3

我们在项目中广泛使用EntLib。通常，我们使用的块是数据访问，日志记录，异常处理和缓存。我们还不时使用政策注入。

据我估计，从头开始重新发明这些东西将完全浪费时间。 EntLib有数千个开发时间，QA小时并且是开源的。仅使用一个或两个块仍然值得与部署必要的程序集相关的少量开销。但是，听到你不使用日志记录我很惊讶。您是使用不同的日志框架还是自己编写？

Answer 4

就个人而言，我认为企业库遭遇software bloat。我不会选择它作为“仅仅因为”的基础作品。我需要有一个非常令人信服的理由在项目上使用它。我已经使用了之前发布的一些应用程序块 - 当它们被提供时 - 但是我一直怀疑是因为我们使用的是一块很多而进入完整的企业库。将复杂性保持在项目的最小值是有价值的，项目复杂性的一部分是引用的额外组件和库。

Answer 5

在与几个客户的互动中，我一直在努力做出这个决定。像大多数架构决策一样，确实没有错误或正确的答案，只需要一组需要应用于不同客户端环境的权衡。在考虑这些权衡时，决定通常归结为以下优点和缺点：

EL PROs

Microsoft在命名空间中。毫不奇怪，对于许多大型组织而言，这是考虑因素＃1。另外，许多人在阅读EULA并了解微软对EL的实际支持水平时感到惊讶。
在全球许多大型企业中得到证实。这并不意味着它是最好的解决方案，只是它的稳定性和对运行时性能的影响可以忽略不计。
[数据访问]如果您希望坚持使用旧手工制作或生成的SQL /存储过程，则可能是最佳解决方案

EL CONs

对有前途的实践（如ORM，DI / IoC或AOP）的上市速度缓慢或不存在
重量级，具有比其他框架（例如日志记录域中的Log4Net）更高的相应开销。
如果您走出提供者模型，则很难自定义。处理源代码更改，签名和GAC部署/版本控制问题对于复杂的EL DLL网络来说可能比使用更轻量级框架更加容易。
大型企业有一些关键需求的东西，例如批处理框架，没有进入EL，而且仍然是Avanade ACA框架中的专有代码。

Answer 6

我没有反对EntLib。事实上，我自己使用它主要用于几个项目的日志记录和异常处理。

正如您所注意到的那样，数据访问部分库只会给您带来很少的帮助。即使在你的项目中使用它的成本很小（因为你已经有了一些经验），那里仍然有更好的数据访问“产品”（Linq2Sql，EF，SubSonic，NHibernate，LLBLGen ......）长期运行将为您节省大量时间。

底线是：如果它没有给你任何重大好处，不要仅仅因为你习惯了它就把它包含在项目中。在一个较新的技术/产品上度过一个周末，我相信它比坚持DAAB更有利。

Answer 7

我们还在所有项目中使用EntLib。我们独立评估了每个块，最终使用了缓存，异常处理，日志记录和验证。我们将它们作为本地DLL部署在应用程序文件夹中，既简单又简单。

底线是，挑选你想要的东西。如果它看起来过于臃肿，那么首先要检查你是否吸引了比实际需要更多的东西。

Answer 8

我认为企业图书馆是个不错的选择。它经过充分记录并经常使用。这是一个奖励，特别是当您将代码传递给其他开发人员时。我不认为你在开销或复杂性方面增加了太多，因为它包装得非常好，并安装在GAC中。

Answer 9

这是关于Linq-to-SQL: The Data Access Layer (DAL) Shrinker的非常有见地的文章。

几年前我第一次开始使用微软的数据访问应用程序块。一旦Linq被介绍，我就强迫自己去学习它。从那以后，我把它整合到我的所有项目中。

Answer 10

为什么不在较小的项目上分支并评估SubSonic？ Rob Connery现在为MS工作，并且创造了ORMS的“瑞士军刀”。该项目当然是一个知名的产品，所以你可以更好地将它介绍给客户和同事。

SubSonic包含：

Fluent界面
支持MS SQL，Oracle，MySql

汇总查询：

const double expected = 55.5922;

// overload #1
double result = new
    Select(Aggregate.Avg("UnitPrice"))
    .From(Product.Schema)
    .ExecuteScalar<double>();
Assert.AreEqual(expected, result);

加速时间大约是半小时。如果你最终讨厌它，你甚至不会浪费一天！

继续使用Microsoft Enterprise Library？

更新

10 个答案: