再次调整项目架构是因为和群友dezhou的一次聊天，我原来的想法是项目尽量做简单点别搞太复杂了，仅使用了DbContext的注入，其他的也没有写接口耦合度很高。和dezhou聊过之后我仔细考虑了一下，还是解耦吧，本来按照软件设计模式就应该是高内聚低耦合的，低耦合使项目的模块独立于其他模块,增加了可维护性和移植性!
注：前面写的博客详细记录没项目操作的每一步，其实写起博客来很费时间，而且整片博文里很多无用的信息。对MVC来说会添加控制器，添加视图，添加类这些都最基本的要求了，并且前面博文里都写了，后面也就不再详细写这些东西了，主要写一些思路和关键代码，具体内容以源代码的形式放在博客后面提供下载。
一、默认项目结构
我们看一下，vs2015默认生成的项目结构。
项目中模型、数据访问、业务逻辑和视图相关的内容都在一个项目中，视图、业务逻辑和显示紧紧耦合，前期看着还没什么，到了内容多了项目变大以后，尤其是隔一段时间再更新项目，在看的话一片混乱，有时候一个小的改动造成整个项目导出报错，头痛之极。
二、三层架构
我们再看看三层架构：
- 用户界面表示层(USL)
- 业务逻辑层(BLL)
- 数据访问层(DAL)
三层架构主要是使项目结构更清楚，分工更明确，有利于后期的维护和升级。它未必会提升性能，因为当子程序模块未执行结束时，主程序模块只能处于等待状态。这说明将应用程序划分层次，会带来其执行速度上的一些损失。但从团队开发效率角和维护性上来说易于进行任务分配，可维护性高。
按照三层的思想，MVC中的控制器（C）和视图(V)都是处理界面显示相关的内容属于用户界面表示层(USL) ，模型（M）是控制器和视图间交换的数据,所以MVC框架应该都属于三层中的用户界面表示层。
数据访问层(DAL)和业务逻辑层(BLL) 、业务逻辑层和用户界面表示层(USL) 也要交换数据，干脆把模型（M）独立出来，作为控制器和视图，及三个层次之间交换的数据。
三、高耦合
我们看向Ninesky现在的项目结构，如下图：
包含四个项目：
Ninesky.DataLibrary是数据访问层，提供数据库访问的支持。
Ninesky.Base 是业务逻辑层，负责业务逻辑的处理。
Ninesky.Web 用户界面表示层(USL)，负责显示页面和显示项目的逻辑处理。
Ninesky.Models 就是各层之间交换的数据实体。
从以上可以看到项目按照三层的思想进行了分层。PS:有群友问为什么项目名称叫DataLibrary、Base，不叫DAL,BLL？这可能是强迫症的原因，我反正看着DAL,BLL的项目名称特别不舒服，改了个自己喜欢的名字，其实功能都一样的。
再看一下项目的调用
看一下Ninesky.Base的CategoryService类。
代码中位置1声明了类CategoryRepository，这个类是 Ninesky.DataLibrary中的一个类。位置2将这个项目实例化了，在位置3处我们直接调用了这个类的Find方法。从上面可以看出CategoryService类是依赖CategoryRepository类的；Ninesky.Base项目是依赖于Ninesky.DataLibrary项目的。一个项目的类精确的调用了另一个项目类的方法那么他们之间就是高耦合。发生高耦合就是软件设计有问题，就要解耦，把依赖实现代码转换成依赖逻辑，这时候就要引入抽象层（通常是接口）。
四、依赖接口
我们添加一个dll项目Ninesky.InterfaceDataLibrary，给Ninesky.DataLibrary添加对Ninesky.InterfaceDataLibrary项目的引用。
在Ninesky.InterfaceDataLibrary项目添加InterfaceBaseRepository接口