Microsoft 2013 新技术学习笔记 二

在探讨系统重构的代码结构组织以前，先初步考虑框架与数据库的交互，在.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方式简单的开发流程可归纳以下：

1. 直接在Model中建立表明业务实体(Entity)的类(class)，如下是几个基本规则(更复杂的Entity定义规格可参阅这里)
   1. Entity(或者说数据表)的关键字默认规则："ID" or "classsnameID"属性为关键字。固然DatabaseGenerated标签可容许本身定义关键字
   2. Entity间的一对多关联用泛型集合类型的navigation property来表示
   3. Entity类名默认是数据表名，Entity类属性默认是数据表字段名
   4. foreign key的默认定义规则：<navigation property name><primary key property name>
2. 建立Database Context(这里除了建立数据库链接外，还将数据表与Entity关联起来)
   1. 用DbSet<T>将数据表与定义的Model类关联起来，且DbSet会完成常见的数据表CRUD操做
3. 建立视图显示Entity对象

开发流程的核心基本就是如此，中间涉及的各类规则可参阅这里，包括数据库链接字符串规则、Entity关联规则、甚至你能够自定义规则

 一句话小结三种方式的选择：Code First适合作演示系统，不少东西不用费时间考虑，Database First显然适合导入现有的数据结构，从头实施大型项目仍是以模型先着手，完整的模型视图有利于理清各个对象间的关系。

肯定了asp.net mvc + EF 后，接下来如何进行呢？对我来讲，涉及的新技术好多哦，系统的学习是不可能的，我决定采起这样的方式进行：搜集asp.net mvc的最佳实践经验，以此为基础来展开本次重构，整体来说从如下几个方面着手搜集

• 代码结构的组织
• 身份验证机制的新实现(针对我原系统而言)
• 权限管理机制的新实现(针对我原系统而言)
• 资源管理机制(一项具体业务，这里不详述其内容)