一步一步搭架子（分析篇）

写下这篇博客，主要是想和大家分享我的思路以及碰到的问题

作为开篇，我打算和您分享如下内容：分析系统，技术的选择，系统初步构架图

话不多少，进入正文

 

假设现在要实现一个学校登记所有教师信息的系统。系统功能十分简单：对教师信息的增删改查。

我们几乎是立即设计出了这样两张表（为了增加一点复杂度，这里将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：爆照。原来自己年轻过啊