将Unity引入框架

  我不打算讲述具体怎么作了，因为有兴趣的朋友可以自己下它的代码看一看，再结合它的QuickStart相信可以很快上手的。我想说的是，现在我们在项目初期做设计的时候，就应该考虑到框架和业务模块的分离。

  这段时间，项目处于正式启动前的预研阶段，其中的一个重要的任务就是搭建好项目的框架并且基于这个框架写一个例子。后期真正进入项目后，每个人只要按照规范参照例子就可以完成开发。这样可以保证开发的质量和管理的可控。这个搭建项目的任务是由三个开发协作完成。第一次评审的时候，我就问了他们一个问题，因为我们这个项目是做报表，大概会有8大模块，700多张报表。 我想问他们在搭建项目结构的时候如何考虑处理这么多模块和报表的？是不是全部放在一个项目里面呢？这就是缺乏经验的开发人员常犯的错误。在他们心中框架和复用的方法或者函数等同。其实不然。当我在想看到框架的时候，我觉得我首先看到的是一组定义良好，结构清晰，职责明确的接口。然后看到的是框架如何将这些接口揉捏在一起，让他们运转起来。这样一来，我在添加新功能的时候，只需要了解对应的接口，分头做实现即可。而无需关心这些类是如何互相协作的。因为框架已经帮我们处理完了。我想这就是框架的作用。它既要很小很轻，又要弹性十足。既要考虑80%的常规情况，又得给那20%的特殊情况一定的伸展空间。这些要素是我们在决定项目结构，决定项目框架的时候要照顾到的。

  我在评审完后给他们谈了我的想法，我相信他们也觉得这样去做肯定是好的，方向上没有问题，但是他们顾虑的是实现的问题。我也明确的告诉他们别担心，实现上一定会碰到障碍，这些点其实就是在考验一个框架的成熟度，恰恰就是我们要解决问题的地方。这里得回到标题中的Unity。这里说Unity只是再说一个例子，它代表的是注入式框架。有了它之后我们可以很轻松的将层次关系，引用关系做到清晰的划分和剥离。我们无需再顾虑那些传来传去的对象，以及如何创建这些对象。这些都由框架去完成。而我们只需要尽情的提出需求，向容器去要。应该说此类框架的引入会大大的改变我们对框架的实现方式。合理的使用会让整个项目的结构看上去更加清晰。

  在项目前期的这些准备都是很关键，尤其是技术选型。方向上的错误会拖累整个项目，再敏捷的团队也很难承受这样的痛。