你对微软应用程序块有什么经验?

他们是 过度设计 这是我最大的问题,最后我摆脱了它,不再使用它。

它们不够有用,需要在系统中进行过多的配置和修改,并且不断地改变其中的内容。只需添加一个日志记录功能,您就可以花两天时间来纠正它。

外面有图书馆,你可以在10分钟内正常工作。

我并没有经常使用它们,主要是因为一些更强大的东西使我从中动摇。例如,在处理异常时,我使用了codeplex.diagnostics,这是一个很好的包,可以在SQL Server上记录数据。对于Web应用程序来说非常简单和有用。对于日志记录,我在log4postsharp控制下使用log4net。当然,我使用postsharp而不是piab,这仅仅是因为根据定义,预编译比动态代理更快。

一件很酷的事情是Unity应用程序块:它似乎把其他DI框架学到的一些经验铭记在心,而且实际上相当容易使用(当然,还有Postsharp4Unity)。

数据访问和异常处理块(我只使用了2个)是非常好的,如果您不需要寻找任何超出基本特性的东西。当然,还有其他更强大的框架,但是有了最小的配置和非常浅的学习曲线,您可以很快完成这两个模块并运行。

由于它们使用工厂模式,因此如果需要,它们很容易扩展。我们定制了异常处理块来显示所有类型的Active Directory数据以及抛出的异常。它把我们的支持时间减少了一大块。

你有没有 单一的 要维护的应用程序?检查AB(或其他任何组件)是否可以帮助您,测试它们,如果它们通过集合,则使用它们,否则不使用。

你有没有 大量且不断增长的应用程序集 维护?然后,您要么构建相同类型的代码来处理,例如日志记录、身份验证和授权、远程通信和类似的重复问题(具体取决于您的业务和IT环境);滚动您自己的代码或组件来解决问题(并维护它!)或者用现成的东西。这些方法中的一种通常(如果不总是)倾向于更好地处理大量的应用程序和公司内部的工作轮换。猜猜看哪一个!(尤其是,千万不要低估培训新的开发人员/维护人员在2年以上的应用程序中高效工作所需的时间,而这些应用程序与他们以前工作过的其他东西没有相似之处或共享组件!)

我使用MS应用程序块是几年前的事了。当时,异常处理块和数据库访问块帮了很大的忙;日志AB相当不错(尽管我更喜欢log4net进行细粒度控制);而且大多数当前AB都不在那里。我的看法是 AB解决了当前框架中的缺陷 .如果它们成功(并且确实解决了现有的症结),您应该考虑它们很可能会被转移到框架的未来版本中,或者语言和/或框架将被扩展以直接解决症结。

代码本身永远不会过度或过低地设计,只是为了特定的目的。评估现成组件的最大挑战是找出其实际用途,而不是市场言论或过于乐观的拯救世界和厨房水槽宣言。女士 P&P group 似乎远离了产品开发团队, occasionally address the wrong problems 对最新产品版本的了解不足…

实际上,我没有在实践中使用任何应用程序块,但我已经阅读了文档并查看了示例。在我看来,当需要很快地做一些事情时,它们可能是一种很好的资源,但否则,当微软发布一个不一定按你希望的方式工作的更新时,这是一种很好的让你回到困境的方法。

我一直觉得最好是自己写日志和异常处理工具。这样,我就可以根据应用程序的需要决定添加和删除的内容。至于重新发明轮子,我不那么担心。我宁愿按照我的规范构建一些东西,而不是使用我必须修改的、按照通用编程社区的规范构建的东西。

我们用团结来取得一些成功。一般来说,我反对DI容器,但是如果必须使用一个容器,Unity就足够好用了。

我对其他大多数人不太信服。尤其是伐木库一直让我抓狂。巨大的、过度设计的,但是硬编码到一些特定的(和简化的)场景中,需要您重新实现一些愚蠢的代码,以实际扩展具有一些相当明显的功能的库。除了绝对的基础知识外,文档还大致介绍了如何自定义和配置它。

我也不认为数据访问块有什么好处。

总的来说,我不是一个大粉丝。

我从.NET 1.1/早期的.NET 2.0开始就没有使用过它们,而且数据的应用程序块非常有限。老实说,我最近没有真正考虑过使用任何东西,我应该看看他们目前有什么。

在实践中,对我来说,写自己的解决方案更容易。通常,我会看到一些非常具体的案例,我确实需要跳过几个圈才能让事情按我想要的方式运行。然后我又做了更多的ASP.NET工作(这似乎是有很多篮球与Web开发一般),我现在主要是Windows应用程序,这似乎有点直截了当。

我认为这真的需要一个个案的基础。如果它对你有用并且满足你的需要,那就使用它。如果有一个完全可行的解决方案,就不需要花时间重新创建。另外,除非您更改框架版本等,否则您没有必要更新它们,如果它们发布了新版本的dll。以我的经验来看。

我们正在使用日志记录、异常处理和验证块。

我在LoggingAB上的经验和你的类似:它能让你95%的成功率。定制并不容易,会导致各种开销(更新、未知领域的测试等等)。不过,总的来说,我不认为它会更快地滚动我自己,特别是因为配置选项非常方便(在开发过程中不太方便,但在部署时,我真的很喜欢有编辑器和在运行时打开/关闭过滤器等)。我确实写了一个小包装,因为我发现它提供了比我们需要的更多的选项(例如,单独的严重性/优先级-又有什么区别?等)。

异常处理我们用了一段时间,但把它扔掉了。最终我们认为这是太多的配置。app.config中的配置有一个主要问题:它不是模块化的(即,您不能轻易地合并来自不同来源的配置)。

验证:不是一个大粉丝。没有特别的原因,只是不太适用。

因此,最后,我们只使用定制的日志记录ab。得出您对整件事情有多有用的结论;)

所以我同意AB不是真的 指导 -它们提供了多种选择,您需要自己决定如何使用它。

我们使用cab(复合用户界面ab)的经验不好。不幸的是,我们现在还远远不能改变它,但如果我再次做同样的项目,我将不会使用出租车。它似乎并不能完全满足我们的需要,所以它比其他任何东西都更具阻碍性,而且它使很多事情变得模糊。