Asp.Net MVC +EF CodeFirst+多层程序设计

1.概述

这是一个基于个人博客的一个项目，虽然博客根本没必要做这么复杂的设计。但是公司有需求，所以先自己弄个项目练练手。项目需要满足下列需求

1.层与层之间需要解耦，在后期上线更新维护时不需要覆盖，只需要更新局部dll即可，也就是插件机制

2.代码安全性，公司有找外包公司要些人，但是又不想让他们得到所有代码，就需要利用接口来规范开发。

3.一开始没有完整的需求说明和数据库设计文档。我们是轻文档开发，也就是说在没有完全上线之前需求随时可能更改，而且数据库一开始也没有设计好，而是开发一点添加一点，也随时会更换需求。

为了保证以上要点，我们就需要搭建一个非常具有灵活性的系统，对一个刚刚开始参加.net开发工作的我来说却是具有很大挑战性，虽然之前也有受过高人指点。

2.程序设计

在程序设计时，我考虑到以上需求，我大致分了一下这些层。

1.实体模型层：CodeFirst实体对象

2.数据访问层：DBContext对象，其实在我接触EF之后就对数据访问层的概念就不太一样了，我现在都觉得数据访问层都没什么太大必要。因为不需要写Sql语句了，都是lambda表达式。这是我一个疑问，大家可以一起讨论下

3.数据库访问接口层：规范数据库访问层

4.数据库访问层工厂：这里我可以通过反射来反射出数据访问层的实例

5.业务逻辑层：业务逻辑代码

6.业务逻辑接口：规范业务逻辑

7.业务逻辑工厂：反射业务逻辑实例

8.MVC：前台展示

1.通过上面我们可以发现，层与层之间是解耦了，比如说我按照某个层的接口规范写好了一个dll，然后更新好服务器，无需将整个项目编译，也无需将整个项目重新覆盖，只需要修改下反射的配置文件即可，也不会影响到网站的正常运行，这才是我要的效果。

2.接口规范些好后，也无需编码人员将整个项目都拿到手，只要自己按照接口规范写好代码，放到测试环境中一测试就OK了。这样对于保证公司代码安全性还是有一定作用的。

3.通过CodeFirst我们可以比较轻松的更换需求，而且也不用一开始就把所有需求罗列出来，然后设计数据库，我们可以一边做功能的时候一边来增加表。

以上思路应该比较适合大众化，中小项目按照这样的设计应该没什么问题。大家如果有什么好的建议或者发现有什么不对的地方，还请提出来，以免误导了他人。

　Email：luozhiqiang@cidtech.cn

Blogs Code