彪悍的人生不需要解釋

現(xiàn)在元數(shù)據(jù)驅(qū)動架構(gòu)的應(yīng)用日益廣泛了。這種模式的應(yīng)用一般為公司的架構(gòu)師根據(jù)經(jīng)驗提供一套schema定義，而業(yè)務(wù)邏輯實現(xiàn)由原來的編碼轉(zhuǎn)為按照此schema定義數(shù)據(jù)。之后有些系統(tǒng)使用代碼生成機制來生成代碼；而有些系統(tǒng)則采用編寫一套框架類，執(zhí)行時解析定義數(shù)據(jù)，從而執(zhí)行數(shù)據(jù)所表達的邏輯。這兩種方式各有利弊。
對于第一種方式，會生成一堆固定模式的代碼，如果允許直接修改這些代碼，將造成很大的維護量；第二種方式，由于是解析執(zhí)行，非常值得懷疑是否會造成JVM hotspot機制失靈，從而導(dǎo)致性能問題；最理想的方式我個人認為是生成代碼，但限制這些代碼為只讀代碼，同時保證這些生成代碼也要建立在框架結(jié)構(gòu)之上，從而可以再靈活動態(tài)攔截進代碼。這樣一方面，提供了MDA外的補充，即可以插寫代碼；另一方面可以充分利用JVM hotspot編譯執(zhí)行機制。
前面也提到了，由于MDA起源于架構(gòu)師的經(jīng)驗，因此schema是不太可能保羅萬象的。MDA在項目上的應(yīng)用必須要提供一種補充機制。一般也就是采用AOP切面編程或回調(diào)機制來做這件補充。首先保證項目的價值實現(xiàn)，然后再后期將這些代碼實現(xiàn)抽象進schema的范圍，從而擴大元數(shù)據(jù)的表達能力。我個人認為元數(shù)據(jù)擴大的極限就是編程語言，呵呵，想想吧，這個認識不是空話，所以我MDA的系統(tǒng)一定是留著補充機制的。