面对一个新项目，如何理解它的模型呢？
要先知道项目提供了哪些模型，模型又提供了怎样的能力。若只知道这些，你只是在了解别人设计的结果，这不足以支撑你后期对模型的维护。
在一个项目中，常常会出现新人随意向模型中添加内容，修改实现，让模型变得难以维护。原因在于对模型的理解不够。
模型都是为解决问题，理解一个模型，需要了解在没有这个模型之前，问题是如何被解决的？
这样，你才能知道新的模型究竟提供了怎样的提升，这是理解一个模型的关键。
本文以Spring的IoC容器为例，来看看怎样理解软件的模型。
耦合的依赖Spring的根基就是IoC容器，即“ 控制反转”，也叫依赖注入。
IoC容器是为了解决什么问题呢？
组件创建和组装问题。
为什么这是个亟待解决的问题？
软件设计需要有个分解过程，必然还面对一个组装过程，即将分解出的各组件组装到一起完成功能。
案例某博客服务提供：根据标题查询博客。
ArticleService处理业务过程中，需用ArticleRepository辅助完成功能，即ArticleService依赖ArticleRepository。
这时你会怎么做？
直男做法，在 ArticleService新增一个ArticleRepository字段：
看起来好像还行。
那这个字段怎么初始化？
直男反应：直接new！
看起好还能用，但实际上DBArticleRepository不能这样初始化。
就如实现类的名字，这里要用到DB。但在真实的项目中，由于资源所限，一般不会在应用中任意打开DB连接，而是会共享DB连接。
所以，DBArticleRepository需要一个DB连接（Connection）参数。
于是你决定通过构造器把这个参数传入：
看上去也还正常。既然开发完了，那么开始测试吧：
要让ArticleService跑起来，就得让ArticleRepository也跑起来；就得准备好DB连接。
是不是太麻烦，想放弃测试了？。但你还是决定坚持一下，去准备DB连接信息。
然后，真正开始写测试时，发现，要测试，还要在DB里准备数据：
- 测查询，得事先插入一些数据吧，看查出来的结果和插入的数据是否一致
- 测更新，得先插入数据，测试跑完，再看数据更新是否正确
咬咬牙准备了一堆数据，你开始困惑了：我在干什么？我不是要测试服务吗？做数据准备不是测试仓库的时候该做的事吗？
所以，你发现问题在哪了吗？
在你创建对象的那刻，问题就出现了。
分离的依赖当我们创建一个对象时，就必须要有个实现类，即DBArticleRepository。
虽然ArticleService写得很干净，其他部分根本不依赖DBArticleRepository，只在构造器里依赖，但依赖就是依赖。
而且由于要构造DBArticleRepository，还引入了Connection类，该类只与DBArticleRepository的构造有关系，与ArticleService业务逻辑毫无关系。
只是因为引入一个具体实现，就需要把它周边全部东西引入，而这一切都与业务类本身的业务逻辑没一毛钱关系。
这就像是，你原本打算买套房子，现在却让你必须了解怎么和水泥、砌墙、怎么装修、户型怎么设计、各个家具怎么组装，而你想要的只是一套能住的婚房。
实际项目，构建一个对象可能牵扯更多内容：
- 根据不同的参数，创建不同的实现类对象，你可能需要用到工厂模式
- 为了解方法执行时间，需要给被依赖的对象加上监控
- 依赖的对象来自于某个框架，你自己都不知道具体的实现类咋样的
……
即便是最简单的对象创建和组装，看起来也不是多简单。
直接构造存在这么多问题，最简单的就是把创建的过程拿出去，只留下与字段关联的过程：
这时的ArticleService就只依赖ArticleRepository。
测试ArticleService也很简单，只要用一个对象模拟ArticleRepository的行为。通常这种模拟对象行为的工作用一个现成的程序库就可以完成，就是那些Mock框架。
之前的代码里，如果我用Mock框架模拟Connection类是不是也可以？
理论上，是可以。但是想要让ArticleService的测试通过，就必须打开DBArticleRepository的实现，只有配合着其中的实现，才可能让ArticleService跑起来。显然，你跑偏了。
对象的创建已经分离了出去，但还是要要有一个地方完成这个工作，最简单的解决方案自然是，把所有的对象创建和组装在一个地方完成：
相比业务逻辑，组装过程很简单，仅仅是个对象创建及传参。
最好的解决方案就是有个框架。Java的这种组装一堆对象的东西一般被称为“容器”。
至此，一个容器就此诞生。它解决的是依赖问题，把被依赖的对象注入到目标对象，所以叫“依赖注入”（Dependency Injection，简称 DI）。这个容器就叫DI容器。
这种创建和组装对象的方式在当年引发了很大的讨论，直到最后Martin Fowler写了一篇《反转控制容器和依赖注入模式》，才算把大家的讨论做了一个总结，行业里总算达成共识。
说了这么多，和我们要讨论的“模型”有什么关系？
很多人习惯性把对象的创建和组装写到了一个类里，导致代码出现大量耦合。
也导致项目很难测试，可测试性是衡量设计优劣的一个重要标准。
有了IoC容器后,你的代码就只剩下关联的代码，对象的创建和组装都由IoC容器完成。不经意间，还做到了面向接口编程，实现是可以替换的，且可测试。
容器概念还能继续增强。比如，我们想给所有与数据库相关的代码加上时间监控，只要在容器构造对象时添加处理即可。这就是 AOP，而这些改动，对业务代码透明。
但还是很多程序员即便用Spring，依然是自己构造对象，静态方法随便写。
理解模型，要知道项目提供了哪些模型，这些模型都提供了怎样的能力。
更重要的是了解模型设计的渊源：
- 可增进对它的了解
- 也会减少我们对模型的破坏或滥用
IoC容器有效地解决了对象的创建和组装的问题，让程序员们拥有了一个新的编程模型。
按照这个编程模型去写代码，整体的质量会得到大幅度的提升，也会规避掉之前的许多问题。这也是一个好的模型对项目起到的促进作用。像DI这种设计得非常好的模型，你甚至不觉得自己在用一个特定的模型在编程。
理解模型，要了解模型设计的来龙去脉。
