在探讨系统重构的代码结构组织之前，先初步考虑框架与数据库的交互，在.net平台上数据访问方案有人总结为三类：DataSet、ADO.net 2.0、ORM组件。我只熟悉ADO.NET方式，众多的企业特性(如连接池、缓存等)均自行写代码实现，在此次重构时，我当然可以直接将原来的数据访问方案直接搬过来在Model中实现与数据层的交互，但既然考虑重构，为何不尝试一下新的ORM呢，在起初我考虑HNibernate框架的，但我在2008年的一个全国应用范围的项目中见过开发团队用Entity Framework作为数据层访问方案，一直对此方案比较好奇，所以这里采用Entity Framework 6.0.1
again, 对此有选择性障碍的人，停止寻找银弹吧，比如Entity Framework框架讨论很多的运行性能问题，我认为可用空间换时间的思路(比较粗暴的说法：硬件空间换响应时间。当然不是这样简单的概念，这里我个人喜欢这样概述此思路而已)来解决，不用钻牛角尖太深。
EF有三种方式(three ways)着手：Database First、Model First、Code First，通俗的话来说：
- Database First：先构建数据库结构，然后通过逆向工程来自动创建数据模型和相关对象代码，最后通过这些对象来与数据库交互
- Model First：先在VS工具中创建数据模型，然后自动生成相关对象代码及数据库，最后通过这些对象来与数据库交互
- Code First：先在VS中创建数据对象类，EF自动转换成模型及数据库，最后通过这些对象来与数据库交互
通常分工明确的项目团队中，设计人员用ORM工具(比如我习惯用PowerDesigner)完成数据库结构的设计，然后交给开发人员进行逻辑代码的开发。 for me, 这部分工作已经完成了，整个后台管理平台的数据结构乖乖的列在数据库中了，看起来我可用Database First方式着手。
这里顺便想提一句Code First方式，这令我回想起早几年的技术销售(TS)的工作，这个角色的工作中涉及的POC要求一个快字，Code First简直就是为快而生的，用户POC需求拿到后，直接进入代码编写业务逻辑，不用花时间在数据层的处理上，最重要的是POC成功后，即使要将POC直接转化到生产环境也是可行的。
Code First方式简单的开发流程可概括如下：
- 直接在Model中创建代表业务实体(Entity)的类(class)，以下是几个基本规则(更复杂的Entity定义规格可参阅这里)
- Entity(或者说数据表)的关键字默认规则："ID" or "classsnameID"属性为关键字。当然DatabaseGenerated标签可允许自己定义关键字
- Entity间的一对多关联用泛型集合类型的navigation property来表示
- Entity类名默认是数据表名，Entity类属性默认是数据表字段名
- foreign key的默认定义规则：<navigation property name><primary key property name>
- 创建Database Context(这里除了创建数据库连接外，还将数据表与Entity关联起来)
- 用DbSet<T>将数据表与定义的Model类关联起来，且DbSet会完成常见的数据表CRUD操作
- 创建视图显示Entity对象
开发流程的核心基本就是如此，中间涉及的各种规则可参阅这里，包括数据库连接字符串规则、Entity关联规则、甚至你可以自定义规则
一句话小结三种方式的选择：Code First适合做演示系统，很多东西不用费时间考虑，Database First显然适合导入现有的数据结构，从头实施大型项目还是以模型先着手，完整的模型视图有利于理清各个对象间的关系。
确定了asp.net mvc + EF 后，接下来如何进行呢？对我来说，涉及的新技术好多哦，系统的学习是不可能的，我决定采取这样的方式进行：搜集asp.net mvc的最佳实践经验，以此为基础来展开本次重构，总体来讲从以下几个方面着手搜集
- 代码结构的组织
- 身份验证机制的新实现(针对我原系统而言)
- 权限管理机制的新实现(针对我原系统而言)
- 资源管理机制(一项具体业务，这里不详述其内容)