是否继续使用Microsoft Enterprise Library？

Question

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

我假设新版本的企业库将在.NET 4.0发布后的几个月内发布。我们公司对这个库的使用可能与传统的使用有所不同，我们为许多客户设计和开发web和windows应用程序。我们要么将完成的项目交给内部开发人员维护，要么如果是一个较小的客户，我们将维护应用程序。

由于业务的性质，我有幸在设计新的应用程序时“从头开始”很长时间，而不是被绑在更新相同的代码库上。在下一个项目中，我可能会问自己同样的问题，我们是否应该再次使用Microsoft Enterprise Library？我们只使用数据访问块，而且在开发过程中似乎确实节省了时间。同时，我想知道使用对象会给项目增加多少开销和复杂性。

提前感谢您的建议。

更新：

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

对我来说，归根结底是数据库在应用程序中的用途。在传统的3-Tier/N-Tier环境中，数据库是公司信息的独立存储。不同的应用程序(Web、桌面等)所有组件都共享和访问一个通用存储平台。在这种情况下，存储过程很有意义，因为它们充当各种应用程序和表之间的抽象层。

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

根据这个结论，我将创建两个原型项目，一个使用SubSonic，另一个使用LINQ。尽管我担心LINQ的开销和保真度损失，但数据访问所需的代码显著减少，并与我们开发的项目类型保持一致，这使得它值得一看。

Answer 1

所有的数据访问层都有其优点和缺点。作为一名承包商，我遇到过各种各样的项目。我个人开始的每个项目，我都使用了Enterprise Library的数据访问块，称为S‘’procs。它上手很快，但更重要的是:我对它非常熟悉。当然，缺点是您必须编写的代码量。

我最近参与的几个项目都在使用LINQ / PLINQO。尽管编辑器的支持很棒，而且它为你创建了大部分代码，但我对它对飞行中数据库更改的生存能力并不印象深刻，也不是对你为了获得良好的性能而必须跳过的圈套印象深刻。

老实说，你应该扩展一下，尝试一些新的东西。这是发现每种类型缺陷的唯一方法，并真正能够做出明智的决定，决定您要使用哪种工具。

Answer 2

企业库并不全是坏的，但数据块也不是那么好。因此，保留您从企业库中获得的大部分内容。另请注意:企业库的大部分内容现在正在重写，包括数据访问块。

http://www.pnpguidance.net/Post/EnterpriseLibrary50UnityConfiguration.aspx

但是对于数据访问，你应该看看实体框架，Linq To SQL (它还没有死)，或者NHibernate (查看SummerOfNHibernate.com)。

在EntLib之外，您可能还可以看看棱镜。

Answer 3

我们在我们的项目中广泛使用EntLib。一般来说，我们使用的块是数据访问、日志记录、异常处理和缓存。有时，我们也会使用策略注入。

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