.NET MVC+EF CodeFirst+IOC+EasyUI 框架设计教程（概述）
一，开发环境：Win7 + VS2013 C# + SQL Server2008 R2
二，总体源代码结构如下：
说明（这个分层按个人理解，不一定要照我的；如果做过开发，会三层架构之类的理解起来就容易）：
01 Infrastructure 基础构件
NetDevelop.Core：配置读写，缓存，等等及其它常用的底层基础操作都可以放这儿；
NetDevelop.Data：数据基础操作接口，等等；
NetDevelop.Utility：通用工具类，如文件操作，加解密，各种转换等；
02 Domain 领域层（相当于三层中的DAL+Model层，但有些差别 ）
01. DbFactory
NetDevelop.DbFactory：用以支持多数据库；
NetDevelop.DbServer：数据操作业务基类，可以理解为普通三层架构中BLL类的基类，用以减轻代码编写量。
02. Framework（这个一般是用来做软件用户与权限管理的，也可以和主程序不分开）
Framework.Container：实体类，EF上下文等；
Framework.IRepository：仓储接口，主要是针对数据库上下文的具体操作；
Framework.Repository：仓储接口实现；
03. Mes（具体子系统，如MES,OA,CRM等等不同的子系统；内容和上面Framework下的三个工程文件是一样的，只不过对应不同的数据库或业务）
Mes.Container：实体类，EF上下文等；
Mes.IRepository：仓储接口，主要是针对数据库上下文的具体操作；
Mes.Repository：仓储接口实现；
03 Services 应用服务层（这个相当于三层中的BLL层）
01. Framework
Framework.IService：服务接口
Framework.Service：服务接口实现
02. Mes
Mes.IService：服务接口
Mes.Service：服务接口实现
04 Presentation UI呈现层
MvcApplication：这是一个MVC的WEB应用程序；
Common：这里面有一些公共类；IOC映射也在这儿，建议将其拿出去，另外建一个工程处理它；IOC容器使用Ninject；
Areas：这是MVC的区域（分离各子系统，如ERP，MES，OA等，有多少个子系统，就在这里加；AREAR的好处是可以把整个公司的各种系统整合起来开 发，但实质上它就是一个类似目录的功能，不过要和具体的路由挂勾）。
Admin：这是区域下的，用户与权限管理处理；（再下面就是页面视图与控制器了）
Mes：这是MES子系统；
Crm：这是CRM子系统；
WinApplication：这是一个C/S结构的桌面应用程序；
。。。另外还可以是其它的类型应用程序。。。
三，各模块间调用关系：
注：1，图二是网上截的，之前也参考过。另时间久了没再核对，具体的和这个图会有出入；但原理上基本上差不多的。
2，图一项目上有对号勾勾，是因为是从SVN源码管理中签出来的，可以不用理会。
四，未使用AOP劫持做日志记录，可以另外自行添加。
五，为什么写这个简明教程？
一是现在个人已不使用这种方式的架构了，二是网上找相关具体的资料也不是很多，对有需要的同行可以分享一下，也许用的着。
六，为何使用.NET MVC+EF CodeFirst+IOC+EasyUI方式？
1，C#：使用C#.Net 是因为05年以后长三角与珠三角的制造企业与很多公司基本上都转向了C#.Net来开发新的系统，被动选择。不过C#与VS确实也很好用。
2，EF：MS推广的ORM框架，与VS集成是一方面；最主要的是MS推广的东西无论好坏，至少对企业内的开发工作者会有一定帮助。说简单点，大家都在用，总不能不会用吧？如果你不用找工作，也可以不用它的，有更多的选择。EF要复杂一些，特别是多表关连的过多之后。
3，CodeFirst方式：这种模式更方便一些。
注：（当然，我这里为了简化操作，是禁止自动生成数据库表的；而且多表连接操作为了少在框架中做处理，多表在数据库中写成了视图，前端当单表用；但这种方式不值得推荐，只是为了简单）。
4，IOC/DI/AOP：这些都是一些好的设计方法，也在现在流行的比较新的技术。利于解耦。不过也不要滥用，什么东西再好，也都要保证用的恰如其分才是合适的。千万不要在能用的上的地方都用，IOC在页面与逻辑层间的调用上用一次就好了，AOP在日志记录或个性化需要的地方用下就行了。
为何是Ninject做依赖注入的容器？
这个看个人喜好，哪个都行，觉得它简单清晰易用。不过这类东西，只用的话都差不多的，但看源码的实现还是各自它们都有挺大区别的。
5，EasyUI：简单好用，上手快。如不喜欢还有个ExtJS的也可以，看个人喜好，感觉其实都差不多。企业信息系统主要是与数据库相关的，这两种更适合后台开发一些。
6，为何是B/S而不是C/S？
都可以的，分离了之后，也可以C/S方式的程序使用的。
7，为何框架中没有WCF？
一是这个是原来内部为了快速使用的，用WCF等开发效率会慢一些，具体原因嘛各有各的具体情况，不解释。如果需要，你把业务逻辑与数据处理相关的，用WCF方式的做就好了，也一样的。但使用WCF的时候有半全双工之分，另外还要注意选择通信协议，否则有的环境中你可能要重新去更正另写。
8，这个框架的目的？
当时并未想太多，只是为了在工作中减轻编码工作量，再就是起到规范编码的作用，增强一些可靠性。（程序员不用写增删改查，只用生成贫血模式的实体类，再就是写几个接口，没几句代码的；然后就是页面了，这种信息系统基本上每个界面都差不多的，也就是复制改一改）；
总结，就是减轻不必要的工作量，程序执行效率也还可以，整体代码结构清爽易懂，相对动软之类的普通三层等方式，起到了一些强制性作用，要更规范许多。如果熟悉普通三层等，对比一下，就知道这种框架要好非常多了，而且因为修改数据库表结构等原因人为出错的可能性也基本上没有了，工作量要小太多了。如果你工作中的开发任务繁重，才能体会到它的好处。
9，有没别的更好的方式？
这种数据库相关的应用系统，主要研究的都是软件工程方面的及后台数据库操作的不断改进与封装上；
另外，个人对更简洁的与动态编译等相关的方式会更感兴趣一些，因此放弃了这种框架。但不是说这种框架就不值的学，毕境也是现在非常好也非常流行的。
