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

Question

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

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

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

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

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

我们框架中的一些例子:

• 异常和事件记录提供商。一种简单、统一的方式，每个应用程序都可以通过这种方式以相同的方式记录异常和事件，而编码工作量最少。它开箱即用，可以记录到 SQL Server、文本文件、事件查看器等。它还包含可扩展点以记录到其他来源。
• 变量赋值执行。一个通用类，它使用受 JUnit 启发的语法，根据对象类型公开扩展方法。例如，要确定 myObject 是否不为空，我们可以执行一个简单的 Enforce.That(myObject).IsNotNull();或通过执行简单的 Enforce.That(myObject).IsOfType(typeof(Hashtable)); 来确定它是否是特定类型执行失败会引发适当的异常，既减少了代码量又提供了执行的一致性。
• 单元测试助手。一系列基于反射的类，可以自动测试类及其属性。 (灵感来自 CodePlex 的 Automatic Class Tester)但从头开始编写。有助于简化为传统上难以测试或测试耗时的事物创建单元测试。

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

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

Answer 1

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

• 要么调整现有的开源框架，在某些情况下将它们封装在内部 API 中，以便能够在需要时更改框架
• 或根据特定需求创建新框架，为多个项目找到多个团队。

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