language-agnostic - 应用程序框架 - 购买、构建还是吸收？

我很好奇其他商店在基本应用程序框架方面做了什么？我认为应用程序框架能够提供额外或扩展的功能，以提高从它构建的应用程序的质量。

有多种开箱即用的框架，例如 Spring(或 Spring.NET)等。我发现这些框架最大的问题是它们不是点菜式的。基本上，它们具有太多功能，除非该功能的每一个部分都是可用的最佳实现，否则您最终可能会使用多个框架的拼凑来完成这些任务 - 导致膨胀和困惑。在我看来，这适用于免费和商业系统。

当然，写作在很大程度上是在重新发明轮子。不过，我不认为它没有优点，因为它提供了最可定制的选项。但是，有些东西太大而无法开发，并且在这种情况下似乎实现不佳或根本没有实现，因为犹豫是否承担开发的前期成本。

有各种各样的开源项目也可以解决可能成为应用程序框架的各个部分。这些可以被采用或吸收(显然取决于许可协议(protocol))以帮助构建来自不同来源的综合框架。

我们通过查看整个企业的应用程序中的一些更大的关注点来解决这种情况，并提出了有效的横切关注点和反复出现的实现问题的列表。最后，我们提出了部分开源、部分基于现有开源选项、部分自定义开发的混合解决方案。

我们框架中的一些示例:

异常和事件记录提供程序。一种简单、统一的方法，通过该方法，每个应用程序都可以以相同的方式以最少的编码工作记录异常和事件。开箱即用，它可以登录到 SQL Server、文本文件、事件查看器等。它还包含可扩展点以登录到其他源。

变量赋值强制执行。使用受 JUnit 启发的语法公开基于对象类型的扩展方法的通用类。例如，要确定 myObject 是否不为 null，我们可以执行一个简单的 Enforce.That(myObject).IsNotNull();或者通过执行简单的 Enforce.That(myObject).IsOfType(typeof(Hashtable)); 来确定它是否是特定类型。执行失败会引发适当的异常，既减少了代码量又提供了实现的一致性。

单元测试助手。一系列基于反射的类，可以自动测试类及其属性。 (受 CodePlex 的 Automatic Class Tester 的启发)但从头开始编写。有助于简化为传统上难以或耗时测试的事物创建单元测试。

我们还完全采用了其他一些功能。例如，我们将 PostSharp 用于 AOP，moq 用于模拟，autofaq 用于 DI。

只是想知道其他人可能做了什么，以及您的框架解决了哪些您没有找到令您满意的工具的问题？至于我们的经验，我们肯定会从新框架中获益，并对我们采取的方法感到满意。

最佳答案

我们的方法是投入整个架构师团队(即“Technical Architects”):

要么适应现有的开源框架，在某些情况下将它们封装在内部 API 中，以便能够在需要时更改框架

或根据特定需求创建新框架为多个项目找到了几个团队。

无论采用哪种方法，这些框架都需要有很好的文档记录(至少有完整的 public API )，并且需要很好地宣传它们的发布:
由于所有团队的工作都基于这些框架，他们需要尽快升级他们的框架版本，以便构建自己的交付。

关于language-agnostic - 应用程序框架 - 购买、构建还是吸收？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/347606/