建站
咨詢
售后
建站咨詢
新聞中心
最近公司要開發(fā)新系統(tǒng)，基本決定使用ORM（高層還在猶豫，擔心效率問題）。既然使用了ORM，那么自然而然的就想到了用面向?qū)ο蟮乃枷雭碓O計數(shù)據(jù)庫。
創(chuàng)新互聯(lián)公司長期為成百上千客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為尉氏企業(yè)提供專業(yè)的成都網(wǎng)站建設、成都網(wǎng)站制作，尉氏網(wǎng)站改版等技術服務。擁有10多年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
本篇文章旨在討論如何抽象（以用戶作為抽象的例子），并提出一些解耦的思路。
我也是***次在實際項目中使用面向?qū)ο蟮乃枷雭碓O計數(shù)據(jù)庫，寫下這篇博客，也是希望與大家多多交流。
正文開始
首先來需求分析
我們的系統(tǒng)有前臺和后臺，前臺用戶有：Man，Woman，SuperMan，SpiderMan與IronMan。后臺用戶為Administrator。
前臺用戶都要填寫聯(lián)系方式與地址，然后SuperMan，SpiderMan與IronMan都有Ability。
需求很簡單。那么按照這個需求，我們來隨手畫一個繼承關系圖。其中V代表抽象類（應該是abstract，畫圖的時候腦抽想著是virtual就用V開頭了，懶得改圖了大家湊合著看吧），I代表Interface。如下圖：
從圖中可以看出，由抽象類Person派生出Administration與抽象類User。類Man與類Womam實現(xiàn)了接口Address與接口Contact，Inhumans則實現(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; } //如果這三項都為false的話
- public bool HasHouse { get; set; } //這輩子就甭想結婚了
- 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; } //這個為true，一輩子不愁吃喝
- }
代碼非常簡單。其他幾個類限于篇幅就不說那么細了。
那么按照這個model，使用EF Model First來建立數(shù)據(jù)庫，得到的Woman表如下：
那么接下來就是重點了：為什么不把Contact和Address分表儲存。這樣與Man表、Woman表寫在一起的話，出現(xiàn)改動（如新增一種聯(lián)系方式），會不會非常痛苦。
如果不是使用ORM，那么這個改動的確是很痛苦；但是如果使用了（這里默認使用的ORM可以從Model生成/改動數(shù)據(jù)庫），那么這個改動是沒什么大不了的了，只需要修改一下接口定義，然后根據(jù)報錯去改就好了。至于數(shù)據(jù)庫的變動，就交給ORM去做就OK了。
這樣有一個好處，可以在有限的范圍內(nèi)實現(xiàn)解耦，部分減少了關系——若將Contact和Address分表的話，取Woman要Join兩次，這看起來沒什么大不了的，但是如果放大了看，如果是join十次呢？這樣弄出來的東西很難去維護（現(xiàn)在公司老系統(tǒng)就是這樣，動不動就join十次二十次的，改動起來十分費力）。
具體怎么去解耦，這個問題相當相當?shù)纳願W，就不敢在這班門弄斧了。
網(wǎng)站標題：我們該如何設計數(shù)據(jù)庫(二)
文章網(wǎng)址：http://fisionsoft.com.cn/article/djpjidg.html
