使用微软的应用程序块
我没有做过很多 .NET 编程，但我检查了 Microsoft 模式和实践小组发布的一些应用程序块。 我想知道它们通常如何使用：
- 直接链接到应用程序
- 将源代码添加到应用程序中并使用它们构建，也许
- 在编写特定于应用程序的代码时将一些自定义的示例代码用作参考
我确信这三种用法都是常见的，但是最典型的使用模式是什么？
是否有一些“每个人”都使用的特定应用程序块？
注意：此问题与企业图书馆应用程序相关，但不相同块还是自制框架？。
I haven't done a lot of .NET programming, but I've examined a few of the application blocks published by Microsoft's Patterns and Practices group. I was wondering how these are typically used:
- Linked directly into applications
- Source added into applications and built with them, perhaps with some customization's
- Sample code used as reference while writing application-specific code
I'm sure all three of these usages are common, but what are the most typical usage patterns?
Are there a few particular application blocks that are used by "everyone?"
Note: This question is related to, but not the same as Enterprise Library Application Blocks OR Home Grown Framework?.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我认为最方便的方法是将 App block\EntLib 添加为解决方案项。 这样，每次构建项目时它们都不会被重新编译（它们根本不会参与构建过程），并且您可以轻松访问它们的源代码\设置断点等。
I think that most convenient way is to add App blocks\EntLib as a solution items. That way they will not be recompiled each time you build your project (they will not participate in build process at all) and you can easily access their source code\set breakpoint etc.
我们通过添加对 DLL 的引用来使用这些块，确保设置“复制本地”，以便将它们与应用程序一起部署到应用程序的 bin 文件夹中。 这意味着我们不必与 GAC 打交道——简单多了！
调试时，Visual Studio 仍然可以单步执行源代码，即使它没有直接包含在您的项目中，只要您的硬盘上有 EntLib 源代码。 第一次使用时它会提示您输入位置，然后记住它。
我们当前使用缓存、异常和日志记录块。 我们还没有想到其余部分的用例。
We use the blocks by adding references to the DLLs, making sure that "copy local" is set so that they are deployed with the app into the app's bin folder. This means that we don't have to muck around with the GAC - much simpler!
When debugging, Visual Studio can still step into the source code even if it's not directly included in your project, as long as you have the EntLib source code on your hard disk somewhere. It will prompt you for the location on first use, and remember it thereafter.
We currently use the Caching, Exception and Logging blocks. We haven't thought of a use case for the rest yet.
我通常将源代码放入我的项目中，然后我可以获得更好的智能感知（以及更好地理解它们）。 但我根本不倾向于定制它们。 我喜欢拥有它们的库存，这样我就可以在需要时随时分发库存二进制文件。
I usually put the source into my project, and then I can get better intellisense (and a better understanding of them). I don't tend to customize them at all though. I like to have them stock so I can just distribute the stock binaries anytime I need them.
我们只是将 EntLib 3.1 二进制文件放入全局程序集缓存中，并在我们的项目中添加引用。 不过，我们通常只使用日志框架。
We just put the EntLib 3.1 binaries in the global assembly cache and add references in our projects. We typically only use the logging framework, though.
我已经尝试了 Enterprise Lib 3.1（2007 年 5 月）的几个应用程序块，这里有一些评论：
缓存应用程序块：在简单场景中不如 System.Web.Caching 有趣（例如内存中缓存）
异常处理与 日志记录：过于复杂。 NLog 或 Log4Net 是更好的解决方案。
我查看了其他块，但它们似乎不适合我们的项目。
最后我们完全放弃了 EntLib，因为定制起来很痛苦......
我建议您真正考虑一个比 EntLib 更不单一的解决方案。
I've tried several Application Blocks of Enterprise Lib 3.1 (May 2007) and here are some comments :
Caching Application Block : Less interesting than System.Web.Caching in simple scenarios (like In-Memory caching)
Exception Handling & Logging : Over-complicated. NLog or Log4Net are better solutions.
I looked at the other Blocks but they didn't seem to fit for our projects.
Finally we completely dropped EntLib because it was painful to customize...
I would advise you to really consider a less monolithic solution than EntLib.
我广泛使用了微软的企业库。 如果可能的话，它们通常不应该包含在您的项目中。 编译的附加成本可能会很高。 此外，没有理由在项目中使用源代码来使用这些类。 只要您在项目中添加对 DLL 的引用，您仍然可以在编码过程中获得智能。 还建议避免在开发环境中出现多个代码库。 如果您需要自定义这些类，请在它们自己的解决方案中打开它们并保持一个版本处于活动状态。 当然，我总是强烈建议使用版本控制（VSS 或 Subversion），以防您需要回滚更改。
还有一些通常编码更好的 Microsoft 类的开源替代品（即 Log4Net、nUnit 等）。 Microsoft 代码往往臃肿且低效。
I have used Microsoft's Enterprise Library extensively. They generally should never be included within your project if possible. The added cost of compiling can be heavy. Additionally, there's no reason to have the source code in your project to use the classes. You will still get intellisence during coding as long as you add a reference to the DLL's in your projects. It is also advisable to avoid having multiple codebases floating around your developer environment. If you need to customize the classes, open them up in their own solution and keep one version active. Of course I always strongly suggest using version control (VSS or Subversion) in case you need to roll back changes.
There are also open source alternatives to the Microsoft classes that are usually better coded (i.e. Log4Net, nUnit, etc.). Microsoft code tends to be bloated and inefficient.