我很好奇其他商店在基础应用程序框架方面做了什么？ 我将应用程序框架视为能够提供附加或扩展功能以提高由此构建的应用程序的质量。
有各种各样的开箱即用的框架，例如Spring（或Spring.NET）等。我发现这些框架最大的问题是它们不是点菜式的。 基本上，它们具有太多的功能，除非每个功能都是可用的最佳实现，否则您最终可能会使用多个框架的拼凑来完成这些任务 - 导致臃肿和混乱。 我认为这适用于免费和商业系统。
当然，写作很大程度上是重新发明轮子。 不过，我不认为它没有优点，因为它提供了最可定制的选项。 然而，有些事情太大而无法开发，并且在这种情况下似乎实施得很差或根本没有实施，因为在承担开发的前期成本方面犹豫不决。
有大量的开源项目也可以解决可能的应用程序框架的各个部分。 可以采用或吸收这些内容（显然取决于许可协议），以帮助构建来自不同来源的综合框架。
我们通过查看整个企业应用程序中的一些较大问题来处理这种情况，并列出了有效的跨领域问题和反复出现的实施问题。 最后，我们提出了部分开源、部分基于现有开源选项、部分定制开发的混合解决方案。
我们框架中的一些示例：
- 异常和事件日志记录提供程序。 一种简单、统一的方法，每个应用程序都可以通过最少的编码工作以相同的方式记录异常和事件。 它开箱即用，可以记录到 SQL Server、文本文件、事件查看器等。它还包含记录到其他源的扩展点。
- 变量赋值强制执行。 一个通用类，它使用受 JUnit 启发的语法公开基于对象类型的扩展方法。 例如，要确定 myObject 是否不为 null，我们可以执行简单的 Enforce.That(myObject).IsNotNull(); 或者通过执行简单的 Enforce.That(myObject).IsOfType(typeof(Hashtable)); 来确定它是否是特定类型 执行失败会引发适当的异常，既减少了代码量，又提供了实现的一致性。
- 单元测试助手。 一系列基于反射的类，可以自动测试类及其属性。 （受到 CodePlex 的自动类测试器的启发），但从头开始编写。 有助于简化传统上难以或耗时的测试的单元测试的创建。
我们还直接采用了其他一些功能。 例如，我们使用 PostSharp 进行 AOP，moq 用于模拟，以及 autofaq 对于DI。
只是想知道其他人可能做了什么，以及您的框架解决了哪些您没有找到令您满意的工具的问题？ 就我们的经验而言，我们肯定会从新框架中获益，并对我们所采取的方法感到满意。
I was curious as to what other shops are doing regarding base application frameworks? I look at an application framework as being able to provide additional or extended functionality to improve the quality of applications built from it.
There are a variety of out of the box frameworks, such as Spring (or Spring.NET), etc. I find that the largest problem with these being that they are not a la carte. Basically, they have too much functionality and unless every piece of that functionality is the best implementation available, chances are that you will end up using a patchwork of multiple frameworks to accomplish these tasks - causing bloat and confusion. This applies to free and commercial systems, in my opinion.
Of course, writing is largely re-inventing the wheel. I don't think it is without merit, though, as it provides the most customizable option. Some things are just too large to develop, though, and seem to be poorly implemented or not implemented at all in this case because of the hesitation to commit to the upfront costs of development.
There are a large variety of open source projects that address individual portions of a could-be application framework as well. These can be adopted or assimilated (obviously depending upon license agreements) to help frame in a comprehensive framework from diverse sources.
We approached the situation by looking at some of the larger concerns in our applications across the entire enterprise and came up with a list of valid cross-cutting concerns and recurring implementation issues. In the end, we came up with hybrid solution that is partially open source, partially based on existing open source options, and partially custom developed.
A few examples of things that are in our framework:
- Exception and event logging providers. A simple, uniform means by which every application can log exceptions and events in an identical fashion with a minimal coding effort. Out of the box, it can log to a SQL Server, text file, event viewer, etc. It contains extensibility points to log to other sources, as well.
- Variable assignment enforcement. A generic class that exposes extension methods based upon the object type, using a syntax that is inspired by JUnit. For example, to determine if myObject is not null, we can do a simple Enforce.That(myObject).IsNotNull(); or determine if it is a specific type by doing a simple Enforce.That(myObject).IsOfType(typeof(Hashtable)); Enforcement failures raise the appropriate exception, both reducing the amount of code and providing consistency in implementation.
- Unit testing helpers. A series of classes, based upon reflection that can automatically test classes and their properties. (Inspired by Automatic Class Tester from CodePlex) but written from the ground up. Helps to simplify the creation of unit tests for things that are traditionally hard or time-consuming to test.
We have also outright adopted some other functionality, as is. For example, we are using PostSharp for AOP, moq for mocking, and autofaq for DI.
Just wondering what other people might have done and what concerns your framework addresses that you did not find tooling that you were satisfied with? As for our experience, we are definitely reaping the benefits of the new framework and are content with the approach that we have taken.
发布评论
评论（2）
我们的方法是让整个架构师团队（即“技术架构师”）致力于：
无论采用哪种方法，这些框架都需要有很好的文档记录（至少有完整的公共 API），并且它们的发布需要广告做得很好：
由于所有团队都将基于这些框架进行工作，因此他们需要尽快升级框架版本，以便构建自己的交付。
Our approach was to devote an entire team of architects (namely 'Technical Architects') for:
Whatever the approach, those frameworks need to be very well documented (at least with a complete public API), and their release need to be well advertised:
Since all teams will based their work on those frameworks, they need to upgrade their versions of framework as soon as possible, in order to build their own deliveries.
我的简单建议是您使用适合您需求的框架。 当然，为了做到这一点，您必须进行实验并事先了解您在寻找什么。 即使该框架提供的功能远远超出您的需要，但这样做的成本是多少？ 对于一般问题，成本只是在一个 jar 中额外增加几个 Mb，我认为这对于大多数项目来说是可以的。
最后，您应该选择一个能够正确完成工作的框架，以便您的重点是提供用户价值并简化开发人员的维护。 当然，没有一个框架可以解决每个人的问题，但有一些框架能够满足他们的目标。 这一切都取决于最佳妥协。
My simple advice is that you use a framework that suits your needs. Of course, in order to do this you have to experiment and know beforehand what are you looking for. Even if the framework comes with much more than you need, what is the cost of this? For the average problem, the cost is only a few extra Mbs in a jar, which I think is OK for most projects.
In the end, you should choose a framework that does the job right, so that your focus is at providing user value and easing the maintenance of the developer. Of course, there isn't a single framework that addresses everyone's problems, but there are some frameworks that hit the sweet spot on what they aim for. It's all a matter of going with the best compromise.