我一直覺得基于domain的OOAD的設(shè)計(jì)思想有一個(gè)重大的缺陷,導(dǎo)致我們的設(shè)計(jì)靈活性很差。
OOAD有一個(gè)基本的前提:所以的類以及類之間的關(guān)系在設(shè)計(jì)完成后就已經(jīng)確定了,不可以更改。我覺得正是這種“靜態(tài)性”導(dǎo)致靈活性很差。
比如:在domain層有一個(gè)Employee類,在設(shè)計(jì)的時(shí)候我們必須確定好:Employee有name和address等屬性,如果程序發(fā)布后用戶需要增加一個(gè)屬性,就不得不重新編譯代碼,這就是為什么有時(shí)候僅僅是數(shù)據(jù)庫表增加一個(gè)字段就會(huì)帶來如此大的工作量。我認(rèn)為確定domain類屬性的工作應(yīng)當(dāng)由用戶做而不是程序設(shè)計(jì)師。不僅如此,甚至某些時(shí)候類和類之間的關(guān)系也不應(yīng)該事先確定。比如Department和Employee的關(guān)系,有的公司是一對多,而有的公司是多對多。我覺得我需要一種“動(dòng)態(tài)”性非常強(qiáng)的設(shè)計(jì),才會(huì)滿足不同用戶的需要,才會(huì)真正設(shè)計(jì)出靈活性非常強(qiáng)的框架,后期的維護(hù)量才會(huì)最低。
可惜的是,我至今還沒有找到這樣一種框架,至少hibernate不能!
OOAD有一個(gè)基本的前提:所以的類以及類之間的關(guān)系在設(shè)計(jì)完成后就已經(jīng)確定了,不可以更改。我覺得正是這種“靜態(tài)性”導(dǎo)致靈活性很差。
比如:在domain層有一個(gè)Employee類,在設(shè)計(jì)的時(shí)候我們必須確定好:Employee有name和address等屬性,如果程序發(fā)布后用戶需要增加一個(gè)屬性,就不得不重新編譯代碼,這就是為什么有時(shí)候僅僅是數(shù)據(jù)庫表增加一個(gè)字段就會(huì)帶來如此大的工作量。我認(rèn)為確定domain類屬性的工作應(yīng)當(dāng)由用戶做而不是程序設(shè)計(jì)師。不僅如此,甚至某些時(shí)候類和類之間的關(guān)系也不應(yīng)該事先確定。比如Department和Employee的關(guān)系,有的公司是一對多,而有的公司是多對多。我覺得我需要一種“動(dòng)態(tài)”性非常強(qiáng)的設(shè)計(jì),才會(huì)滿足不同用戶的需要,才會(huì)真正設(shè)計(jì)出靈活性非常強(qiáng)的框架,后期的維護(hù)量才會(huì)最低。
可惜的是,我至今還沒有找到這樣一種框架,至少hibernate不能!
安徽新華電腦學(xué)校專業(yè)職業(yè)規(guī)劃師為你提供更多幫助【在線咨詢】