与编写自己的解决方案相比，您对Microsoft应用程序块和其他Microsoft解决方案的实际体验是什么？
我开始了一个新项目并决定给他们一个机会。我使用了异常处理和日志记录块。异常处理块适用于我需要的东西。记录块占我所需要的95％，其余需要定制。花了一段时间研究如何自定义它，然后有一些版本参考问题。无论是写入文件还是数据库（在这个项目中），日志记录都是一项非常简单的任务。事后来看，编写自己的文章会更快。
该项目还需要与PDA同步数据。通过一些研究，微软指出的方向似乎很明显是同步服务。在花了大约3天试图获得不同软件的所有正确版本后，我无法使样本正常工作Windows Mobile Synchronization Error。我选择使用简单的OpenNETCF桌面通信将文件复制到pda或从pda复制文件，使用二进制对象序列化，并编写我自己的基本同步代码，这花费的时间更少，并且按照我想要的方式完成所有操作（并且不感觉好的:)）
一些积极因素：
底片：
这是我的学习经历，这将使我能够更好地决定是否使用Microsoft解决方案（或其他第三方解决方案）而不是自己编写。
你的经历如何？
答案 0 :(得分：6)
他们过度设计，这是我最大的问题，最后我摆脱了它，不再使用它了。
它们不够用，需要太多配置，系统中的修改以及它们不断更改的内容。要简单地添加日志记录功能，您最终需要花费2天才能做到正确。
有些图书馆在10分钟内可以正常运作。
答案 1 :(得分：2)
我没有太多使用它们，主要是因为其他更强大的东西让我感到震惊。例如，在处理异常时，我使用了CodePlex.Diagnostics，这是一个很好的包，用于记录SQL Server上的内容。对于Web应用程序非常简单和有用。对于日志记录，我在Log4PostSharp的控制下使用log4net。当然，我使用PostSharp而不是PIAB，只是因为根据定义，预编译比动态代理更快。
一个很酷的事情是Unity应用程序块：它似乎已经将其他DI框架学到的一些经验教训用于实践，并且实际上相当容易使用（当然，还有PostSharp4Unity）。
答案 2 :(得分：1)
我实际上并没有实际使用过任何应用程序块，但我已阅读文档并查看了示例。在我看来，当一些事情必须很快完成时，它们可能是一个很好的资源，但是，当微软发布一个不一定按你想要的方式工作的更新时，这是一个让自己陷入困境的好方法。
我总是发现最好编写自己的日志记录和异常处理工具。这样，我根据应用程序的需要决定添加和删除的内容。至于重新发明轮子，这并不会让我感到烦恼。我宁愿按照我的规范构建一些东西，而不是根据我必须要破解的一般编程社区的规范来构建一些东西。
答案 3 :(得分：1)
数据访问和异常处理块（我使用过的只有2个）非常出色，如果您没有寻找超出基本功能的开箱即用的东西。当然还有其他更强大的框架，但只需最少的配置和非常浅的学习曲线，您就可以立即启动并运行这两个模块。
由于他们使用工厂模式，如果需要，它们很容易扩展。我们定制了异常处理块，以显示所有类型的Active Directory数据以及抛出的异常。它把我们的支持时间减少了一大块。
答案 4 :(得分：1)
您是否需要维护单个应用程序？检查一个AB（或那里的任何其他组件）是否可以帮助你，测试他们，如果他们通过集合则使用'，否则不会。
您是否拥有庞大且不断增长的应用程序来维护？那么你要么要构建相同类型的代码来处理，例如记录，认证和授权，远程通信和类似的经常性问题（具体取决于您的业务和IT环境）;滚动您自己的代码或组件来解决问题（并维护它！）;或者使用现成的东西。这些方法中的一种通常（如果不总是）倾向于在大量应用程序和公司内部的工作轮换中更好地工作。猜猜哪个！ （特别是，永远不要低估培训新开发人员/维护人员在2年以上的应用程序中提高工作效率所需的时间，与其他人之前没有相似之处或共享组件！）
几年前我使用MS应用程序块。那时，异常处理块和数据库访问块帮助了很多;日志记录AB相当不错（虽然我更喜欢使用log4net进行细粒度控制）;目前AB的大部分都不在那里。我的观点是 AB在当前框架中的地址缺陷。如果它们成功（并且真正解决了现有的痛点），您应该考虑将它们转移到框架的未来版本中，或者扩展语言和/或框架以直接解决痛点。
代码本身永远不会过度或过度设计，仅用于特定目的。评估现成组件的一大挑战是找出实际目的是什么，而不是市场说话或过于乐观的拯救世界和厨房水槽宣言。 MS“P&P group似乎与产品开发团队相差甚远，occasionally address the wrong problems对最新产品版本的洞察力不足......
答案 5 :(得分：1)
我们正在使用Unity取得了一些成功。我一般反对DI容器，但是如果你必须使用它，那么Unity运行得很好。
我不太相信其他大多数人。特别是日志库让我疯狂。巨大而过度设计，但硬编码到某些特定（和简化）场景，要求您重新实现愚蠢的代码量，以实际扩展库具有一些相当明显的功能。除了绝对的基础知识之外，文档还有关于如何自定义和配置的概述。
我在数据访问块中看不到多少好处。
总的来说，我不是一个大粉丝。
答案 6 :(得分：0)
我从.NET 1.1 /早期的.NET 2.0开始就没有使用它们，而且它的数据应用程序块非常有限。说实话，我最近没有考虑过使用任何东西，我应该看看他们目前的情况。
在实践中，我可以更轻松地编写自己的解决方案。通常情况下，我会看到一些非常具体的案例，但我确实需要通过一些箍来让事情以我想要的方式运作。然后我又做了更多的ASP.NET东西（看起来一般有很多关于web开发的箍）我现在主要是Windows应用程序，这似乎更直接。
我认为这确实需要根据具体情况而定。如果它适合您并满足您的需求，请使用那里的东西。当一个完全可行的解决方案存在时，无需花时间重新创建一些东西。除非你更新框架版本等，否则没有理由你必须更新，如果他们发布了新版本的DLL。根据我的经验，无论如何。
答案 7 :(得分：0)
我们正在使用日志记录，异常处理和验证块。
我对伐木AB的体验与你的相似：它可以让你获得95％的路程。定制并不容易，并导致各种开销（更新，在未知领域进行测试，......）。总的来说，我不认为它会更快地滚动我自己，特别是因为配置选项非常方便（在开发过程中没那么多，但是当它部署时，我真的很喜欢编辑器打开/关闭运行时过滤器等）。我确实在它周围写了一个小包装，因为我发现它提供了比我们需要的更多选项（例如，单独的严重性/优先级 - 又有什么区别？等等）。
我们暂时使用的异常处理但将其抛弃了。最终我们认为配置太多了。 app.config中的配置有一个主要问题：它不是模块化的（即你不能轻易地合并来自不同来源的配置）。
验证：不是一个大粉丝。没有特别的原因，只是不太适用。
所以，最后，我们只使用自定义的Logging AB。得出关于整个事情有多有用的结论;）
所以我同意AB不是真正的指南 - 它们提供了广泛的选项，您需要自己决定如何使用它。
我们在使用CAB（Composite UI AB）方面遇到了不好的经历。不幸的是我们现在太过改变了，但如果我再次做同样的项目，我根本不会使用CAB。它似乎没有做到我们需要的东西，所以它比其他任何东西都更重要，它会混淆很多正在发生的事情。