C# 使用企业图书馆的利弊

我刚刚开始一个项目，因为这个项目是个人的，我想知道使用企业图书馆有什么好处？我们在办公室的几个项目中使用版本2，但我不太确定（除了良好的实践）它的优点，特别是在数据库组件中。有什么建议吗？感谢

提供了数据库应用程序块，它的主要优点是更容易生成与数据库无关的代码。开发人员主要与通用数据库和DbCommand对象交互，而不是与例如SqlConnection、SqlCommand等交互。因此，切换到不同的数据库（即Oracle）变得更加可行。根据您的业务需要，这可能是一个明确的优势。EntLib还温和地促使开发人员使用DbParameter作为查询参数，从而降低了SQL注入攻击的风险

正如另一张海报所提到的，数据应用程序块的级别比直接的ADO.NET类要高一些，因此它往往需要更少的代码行来完成同样的事情

在我看来，数据、异常和日志记录块是最有用的。异常和日志记录一起使得将异常（duh）以多种格式记录到多个位置变得非常容易。例如，他们可以将整个异常日志条目（包括堆栈跟踪）放在Windows事件日志中，从而相对容易地诊断问题

---

EntLib的一个缺点是，一些应用程序块将相当多的逻辑放入配置文件中。所以你的逻辑更加分散；有些在代码中，有些在配置文件中。好处是，配置可以在构建后甚至部署后进行修改。

我的团队大约在2年前对配置进行了评估，作为我们产品线重新设计的一部分。我们最后使用的唯一部分是数据库块。我们甚至将其包装在一些类中，我们可以实例化这些类，以便模拟DAL进行单元测试；Microsoft代码块对数据库工作使用静态调用。我不确定微软是否已将LINQtoSQL或实体框架的任何内容集成到db块中。如果db块没有利用其中的一个，我会犹豫现在是否使用它

就日志记录而言，我们发现它是一种比Microsoft日志记录更健壮、更灵活的解决方案。我们用它来满足我们的日志记录需求

---

对于异常处理，我们推出了自己的。Microsoft代码没有处理我们想要处理的远程处理案例，而且因为我们使用的是第三方日志框架，所以编写我们自己的异常库并与之集成更有意义。我发现日志框架在某种程度上集成到异常框架中是非常有用的。我们围绕Log4Net编写了一些轻量级包装器类，并从异常日志中调用了这些类，因此我们没有在Log4Net上引入依赖项。

除了Paul提到的关于数据应用程序块的项目之外，我还想指出，根据我的经验，数据应用程序块也提供了一种更快的方法来使用现有的帮助程序编写所需的数据库代码。我之所以使用EF，是因为它具有一致的外观和开发速度。

我选择不使用EF，是因为我的环境中存在限制，要求应用程序每小时处理数百万事务。这是电信公司环境中的处理量

---

是否使用EF完全取决于您的环境和选择（只要您知道所选技术的局限性）。如果您的系统不需要如此高的负载，我不认为您在使用EF时会有任何问题。

只是出于好奇，您花了多长时间才能启动并运行异常块？MS的老医生说“半天”学习曲线，你的经验是什么？如果你的目标是对如何设置异常块有一个基本的了解，那么M$的说法是合理的（配置控制台在这里是非常宝贵的）。使用此应用程序块（实际上，所有应用程序块）确实需要更改代码，因此，YMMV。是否可以通过数据块（例如MySql）使用不同的提供程序，或者只使用框架中包含的内容（Oracle/SQL Server）？Gustavo，可以使用不同的提供程序。我自己也在EntLib中使用了Firebird。“数据库不可知代码”是一个基于FUD的论点，我希望看到一个改变了数据库提供者的项目。我觉得奇怪的是，MS设计了ADO.NET，然后他们在其上设计了应用程序数据块，并说“使用它，”这就是成功的项目所做的，不用说ADO.NET太麻烦了。在那些想用VB编写C#应用程序的程序员中非常流行（以及所有糟糕的做法），10年后我仍然认为EL是无用的。