Unity的目标是为了提升"依赖注入"的思想,去建立更加松耦合的系统.patterns & practices 小组在那个时候实现DI的方式和我们现在认为的DI有所不同,DI不是单一的可重复使用的容器,而是应该专门用于正在使用它的系统.
我们使用一个叫做ObjectBuilder的类库(一个用于创建DI容器的框架),所以,理论上我们可以为我们的每一个项目创建一个容器,这正是我们想要做的.理想很美好,但是它工作的并不是很好,ObjectBuilder是一个高度解耦、抽象的,使用它必须手动组装它,再加上缺乏文档，花了很多时间了解需要去哪里,以及如何将其整合到有用的东西中去,而这些时间花在了编写、调试和优化DI容器上，而不是在实际的项目需求上工作上。有趣的是当有人想要引用CAB（它使用了一个基于一个版本的DI容器ObjectBuilder）和企业图书馆（基于不同版本的ObjectBuilder）在同一个项目中。集成将会变得非常困难。光光在同一个项目中处理两个不同的版本ObjectBuilder，也是一个不小的挑战。还有一次性的容器导致了一次性的可扩展性和集成接口：在企业库中没有用的在CAB中也没有用。
当我们在Web客户端软件工厂项目的末尾又花了一个星期的时间修复了CWAB中的一堆bug:(这些bug和在CAB中的非常相似),所以为什么不用一个容器实现,代替重复的实现一个又一个的容器。
通过上面的挫败,Unity诞生了,企业库4.0小组,将依赖注入应用程序(已知的Unity最原始的版本)放到了产品列表里面,我们对于Unity这个项目的目标很简单,首先，向我们的社区介绍并推广依赖注入的概念没有障碍的通过大量底层实现细节。第二，有一个核心的容器，有一个易于使用的API，我们,微软的其他团队，或者任何组织对使用可用的开放源码感到不舒服的人项目（不管出于什么原因）都可以使用。第三，有各种各样的可扩展性机制任何人都可以添加功能，而不需要打开核心代码。
在我的观点看来,Unity在上面的目标都取得了成功.我对我们对于.Net社区所产生的影响感到骄傲.Unity很快的成为了.Net生态系统中最受欢迎的DI容器.更重要的是,DI不再是"专家技术",而是主流的一部分,甚至是微软自家的框架(ASP. NET MVC and WebAPI)均来自DI的支持.你得知道,一个概念(依赖注入)变成一个核心观点,Unity发挥了很大的作用.
1、动机
当您设计和开发软件系统时，有许多需求需要考虑到。一些是具体的系统问题，一些是通用的问题。您可以将一些需求分类为功能性需求，以及一些非功能性需求。对于每个不同的系统，需求将会有所不同。下面列出的需求是常见的需求，特别是对于业务线的需求（LOB）具有相对较长的预期寿命的软件系统。它们不一定都是重要的
原文地址：https://www.cnblogs.com/GreenLeaves/p/8809786.html