C# 使用企业库的优缺点
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/241054/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Advantages and disadvantages of using Enterprise Library
提问by Gustavo Rubio
Im just starting a project and since this project is personal I was wondering what are the advantages of using Enterprise Library? We use the version 2 for several projects in the office but im not quite sure (aside of the good practices) of the advantages of it, especially in the database component. Any advice? Thanks
我刚开始一个项目，因为这个项目是个人的，我想知道使用企业库有什么好处？我们在办公室的几个项目中使用版本 2，但我不太确定（除了良好的实践）它的优点，尤其是在数据库组件中。有什么建议吗？谢谢
采纳答案by Paul Lalonde
For the database application block, the main advantage is that it makes it easier to produce database-agnostic code. The developer interacts mainly with generic Database and DbCommand objects, rather than eg SqlConnection, SqlCommand, etc. Thus, switching to a different database (ie Oracle) becomes more feasible. Depending on your business needs, this could be a definite advantage. EntLib also gently prods the developer in the direction of using DbParameter for query parameters, which reduces the risk of SQL injection attacks.
对于数据库应用程序块，主要优点是可以更轻松地生成与数据库无关的代码。开发人员主要与通用数据库和 DbCommand 对象交互，而不是例如 SqlConnection、SqlCommand 等。因此，切换到不同的数据库（即 Oracle）变得更加可行。根据您的业务需求，这可能是一个明确的优势。EntLib 还温和地促使开发人员朝着使用 DbParameter 作为查询参数的方向发展，从而降低了 SQL 注入攻击的风险。
As another poster mentionned, the data app block is somewhat higher-level than the straight ADO.NET classes, so it tends to require fewer lines of code to do the same thing.
正如另一位发布者提到的，数据应用程序块比直接的 ADO.NET 类更高级别，因此它往往需要更少的代码行来做同样的事情。
From my point of view, the data, exception and logging blocks are the most useful. Exception and Logging together make it very easy to log exceptions (duh) to a number of places and in a number of formats. For example, they can put the entire exception log entry, including the stack trace, in the Windows event log making it relatively easy to diagnose a problem.
在我看来，数据、异常和日志块是最有用的。异常和日志一起使将异常 (duh) 记录到许多地方和多种格式变得非常容易。例如，他们可以将整个异常日志条目（包括堆栈跟踪）放在 Windows 事件日志中，从而相对容易地诊断问题。
One disadvantage of EntLib is that some app blocks place quite a bit of logic into configuration files. So your logic is more spread out; some of it is in code, some in config files. The upside is that the configuration can be modified post-build and even post-deployment.
EntLib 的一个缺点是一些应用程序块在配置文件中放置了相当多的逻辑。所以你的逻辑更加分散；其中一些在代码中，一些在配置文件中。好处是可以在构建后甚至部署后修改配置。
回答by Jason Hymanson
My team did an evaluation of the Microsoft Patterns and Practices Enterprise Libraryabout 2 years ago as part of a re-engineering of our product line. The only part we ended up using was the database block. We even wrapped that in some classes that we could instantiate so we could mock out the DAL for unit testing; the Microsoft code block used static calls for database work. I am not sure if Microsoft has integrated any of the LINQtoSQL or Entity Framework stuff into the db block. I would be hesitant to use the db block now if it did not leverage one of those.
大约 2 年前，作为我们产品线重新设计的一部分，我的团队对Microsoft 模式和实践企业库进行了评估。我们最终使用的唯一部分是数据库块。我们甚至将它封装在一些可以实例化的类中，以便我们可以模拟 DAL 进行单元测试；Microsoft 代码块使用静态调用进行数据库工作。我不确定 Microsoft 是否已将任何 LINQtoSQL 或实体框架内容集成到 db 块中。如果它不利用其中之一，我现在会犹豫是否使用 db 块。
As far as logging goes, we found Log4Netto be a much more robust and flexible solution that the Microsoft logging. We went with that for our logging needs.
就日志记录而言，我们发现Log4Net是一个比 Microsoft 日志记录更加强大和灵活的解决方案。我们采用了它来满足我们的日志记录需求。
For exception handling, we rolled our own. The Microsoft code did not handle the remoting cases we wanted to handle, and since we were using a 3rd party logging framework it made more sense to write our own exception library and integrate with that. I have found that some level of integration of the logging framework into the exception framework can be very useful. We wrote some lightweight wrapper classes around Log4Net and called those from our exception logging so we didn't introduce dependencies on Log4Net.
对于异常处理，我们推出了自己的。Microsoft 代码没有处理我们想要处理的远程处理案例，而且由于我们使用了 3rd 方日志记录框架，因此编写我们自己的异常库并与之集成更有意义。我发现将日志框架某种程度地集成到异常框架中非常有用。我们围绕 Log4Net 编写了一些轻量级包装类，并从我们的异常日志中调用这些类，因此我们没有引入对 Log4Net 的依赖。
回答by Mitchel Sellers
In addition to the items mentioned by Paul about the data application block I also would like to point out that in my experience the data application block aslo provides a much FASTER way to write the needed database code, with the helpers that exist. I use it for its consistent look/feel and the speed of development.
除了 Paul 提到的有关数据应用程序块的项目之外，我还想指出，根据我的经验，数据应用程序块还提供了一种更快的方式来编写所需的数据库代码，并使用现有的帮助程序。我使用它是因为它一致的外观/感觉和开发速度。
回答by Monu Sharma
The choice of not being able to use EF for me is bind by the constraints I have in my environment that requires the applications to process millions of transactions per hour. This is the volume of processing in Telco environment.
无法为我使用 EF 的选择是由我在我的环境中所具有的约束所约束的，这些约束要求应用程序每小时处理数百万个事务。这是电信环境中的处理量。
Whether to use EF or not is entirely up to your environment and choice (as long as you know the limitations of the chosen technology). If your system does not require such high loads, I don't foresee you will have any problems in using EF.
是否使用 EF 完全取决于您的环境和选择（只要您知道所选技术的局限性）。如果您的系统不需要这么高的负载，我预计您在使用 EF 时不会有任何问题。
