写下这篇博客，主要是想和大家分享我的思路以及碰到的问题
作为开篇，我打算和您分享如下内容：分析系统，技术的选择，系统初步构架图
话不多少，进入正文
假设现在要实现一个学校登记所有教师信息的系统。系统功能十分简单：对教师信息的增删改查。
我们几乎是立即设计出了这样两张表（为了增加一点复杂度，这里将Teacher和Contact设计为一对一关系）：
系统完成之后，我们一个学校一个学校的去兜售。
卖给A学校之后，他们说：“你这个系统不错，但是我们学校的教师信息有一些特有字段，希望你们能帮我们加上。”
B学校买了之后，也表示很满意，但是B学校也有自己独有的字段需要我们添加
简单的说，就是一个通用系统的二次开发。
现在来分析一下系统：
1、表中基础数据是一样的，但是每个学校有自己的差异字段
2、业务逻辑也是一样的，但是不排除哪个学校有自己独特的业务逻辑（比如说Teacher和Contact本来是一对一关系，要改成一对多关系。这种改动出现的概率很小，如果大量出现这种改动，就是需求分析有问题了）
3、每个学校都有自己的服务器，换言之就是每个学校的数据库是分开的
4、由于数据库是分开的，所以表中数据级别估测为10W级。如此之少的数据，就不用考虑分布式了
现在分析出了一个关键点：数据库是分开的
表和表的对应关系（一对一，一对多，多对多）是稳定的，不稳定的是差异字段。为了应对这种差异，我们大概有三种方法：表内冗余、冗余表、直接将每个数据库中的表设计成不同的（Model继承）
因为各个数据库独立，所以采用了Model继承的方法。关于三种方法的优劣比较，请看这里《我们该如何设计数据库(三)(续)》
既然要用Model继承，那么就要使用ORM。我选用的技术是.Net MVC 3 + Entity framework 5
1、Why .Net MVC
每个学校都要有自己的界面，选择.Net MVC主要是因为T4模板可以节省很多做页面的时间
2、Why .Net MVC 3
Razor视图引擎
3、Why EF,not Nhibernata
①EF对Linq的支持好一些
②性能上其实两者相差不多，但是EF更符合个人审美，毕竟还是觉得Nhibernate的映射有点烦人
4、Why EF 5
EF 5快
综合上面的分析，在选择好了技术之后，就可以画出系统大致的构架图了：
ModelBase：Model基类。数据在这一层中不耦合
Model：继承自ModelBase，
DBcontext：数据访问层
Factory：根据配置来决定具体使用哪一个Model与Context（配置到不用数据库并使用合适的Model）
DM（Data Manipulation）：数据操作层，负责数据的增删改查。可重载
Service：业务逻辑层
Controller：获取Service层处理过的数据，返回View显示。可以在这一层中再次处理数据以满足不同用户需求
View：你懂
那么这一篇的内容基本也算写完了。下一篇打算写写Factory和数据操作层。ModelBase和Model比较简单，就不展开来说了，可以看《我们该如何设计数据库(三)(续)》并下载其中示例来理解
就此搁笔
PS：爆照。原来自己年轻过啊
