彪悍的人生不需要解釋

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