继续使用Microsoft Enterprise Library？

Question

我之前一直在使用Microsoft企业库,因为它被标记为抽象数据访问,而不是编写我自己的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.当然,编辑器的支持非常棒,并且它为您创建了大部分代码,我对飞行数据库更改的生存能力并没有留下深刻的印象,也不会让您对必须跳过的箍感到印象深刻,以获得不错的性能.

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

Answer 2

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

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

在EntLib之外,您可能还会看一下Prism.

Answer 3

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

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

Answer 4

就个人而言，我认为 Enterprise Library 遭受软件膨胀。我不会“仅仅因为”选择它作为基础作品。我需要有一个非常令人信服的理由才能在项目中使用它。我使用了一些以前发布的应用程序块 - 当它们被提供时 - 但我一直怀疑现在跳入完整的企业库只是因为我们使用了许多中的一个。将项目的复杂性保持在最低限度是有价值的，项目复杂性的一部分是引用的额外组件和库。