最近公司要開發(fā)新系統(tǒng)，基本決定使用ORM（高層還在猶豫，擔(dān)心效率問題）。既然使用了ORM，那么自然而然的就想到了用面向?qū)ο蟮乃枷雭碓O(shè)計(jì)數(shù)據(jù)庫。

本篇文章旨在討論如何抽象（以用戶作為抽象的例子），并提出一些解耦的思路。

我也是***次在實(shí)際項(xiàng)目中使用面向?qū)ο蟮乃枷雭碓O(shè)計(jì)數(shù)據(jù)庫，寫下這篇博客，也是希望與大家多多交流。

正文開始

首先來需求分析

我們的系統(tǒng)有前臺(tái)和后臺(tái)，前臺(tái)用戶有：Man，Woman，SuperMan，SpiderMan與IronMan。后臺(tái)用戶為Administrator。

前臺(tái)用戶都要填寫聯(lián)系方式與地址，然后SuperMan，SpiderMan與IronMan都有Ability。

需求很簡(jiǎn)單。那么按照這個(gè)需求，我們來隨手畫一個(gè)繼承關(guān)系圖。其中V代表抽象類（應(yīng)該是abstract，畫圖的時(shí)候腦抽想著是virtual就用V開頭了，懶得改圖了大家湊合著看吧），I代表Interface。如下圖：

從圖中可以看出，由抽象類Person派生出Administration與抽象類User。類Man與類Womam實(shí)現(xiàn)了接口Address與接口Contact，Inhumans則實(shí)現(xiàn)了Ability接口。

然后抽象類代碼：

View Code   
 
    public abstract class Person  
    {  
        public string Username { get; set; }  
        public string Password { get; set; }  
    }  
 
    public abstract class User : Person  
    {  
        public string Name { get; set; }  
    } 

接口代碼：

View Code   
 
    public interface IAddress  
    {  
        string Address { get; set; }  
    }  
 
    public interface IContact  
    {  
         string Email{get;set;}  
         string WorkPhone { get; set; }  
         string MobilePhone { get; set; }  
         string Fax { get; set; }  
    } 

***是Man類和Woman類：

View Code   
 
    public class Man : User, IContact, IAddress  
    {  
        public string Address { get; set; }  
        public string Email { get; set; }  
        public string WorkPhone { get; set; }  
        public string MobilePhone { get; set; }  
        public string Fax { get; set; }  
 
        public bool HasCar { get; set; }       //如果這三項(xiàng)都為false的話  
        public bool HasHouse { get; set; }     //這輩子就甭想結(jié)婚了  
        public bool HasMoney { get; set; }     //T T我淚涌  
    } 

View Code   
 
    class Woman : User, IAddress, IContact  
    {  
        public string Address { get; set; }  
        public string Email { get; set; }  
        public string WorkPhone { get; set; }  
        public string MobilePhone { get; set; }  
        public string Fax { get; set; }  
 
        public bool IsBeauty { get; set; }  //這個(gè)為true，一輩子不愁吃喝  
    } 

代碼非常簡(jiǎn)單。其他幾個(gè)類限于篇幅就不說那么細(xì)了。

那么按照這個(gè)model，使用EF Model First來建立數(shù)據(jù)庫，得到的Woman表如下：

那么接下來就是重點(diǎn)了：為什么不把Contact和Address分表儲(chǔ)存。這樣與Man表、Woman表寫在一起的話，出現(xiàn)改動(dòng)（如新增一種聯(lián)系方式），會(huì)不會(huì)非常痛苦。

如果不是使用ORM，那么這個(gè)改動(dòng)的確是很痛苦；但是如果使用了（這里默認(rèn)使用的ORM可以從Model生成/改動(dòng)數(shù)據(jù)庫），那么這個(gè)改動(dòng)是沒什么大不了的了，只需要修改一下接口定義，然后根據(jù)報(bào)錯(cuò)去改就好了。至于數(shù)據(jù)庫的變動(dòng)，就交給ORM去做就OK了。

這樣有一個(gè)好處，可以在有限的范圍內(nèi)實(shí)現(xiàn)解耦，部分減少了關(guān)系——若將Contact和Address分表的話，取Woman要Join兩次，這看起來沒什么大不了的，但是如果放大了看，如果是join十次呢？這樣弄出來的東西很難去維護(hù)（現(xiàn)在公司老系統(tǒng)就是這樣，動(dòng)不動(dòng)就join十次二十次的，改動(dòng)起來十分費(fèi)力）。

具體怎么去解耦，這個(gè)問題相當(dāng)相當(dāng)?shù)纳願(yuàn)W，就不敢在這班門弄斧了。

原文鏈接：http://www.cnblogs.com/CrazyJinn/archive/2012/08/20/2637459.html