彪悍的人生不需要解释

现在元数据驱动架构的应用日益广泛了。这种模式的应用一般为公司的架构师根据经验提供一套schema定义，而业务逻辑实现由原来的编码转为按照此schema定义数据。之后有些系统使用代码生成机制来生成代码；而有些系统则采用编写一套框架类，执行时解析定义数据，从而执行数据所表达的逻辑。这两种方式各有利弊。
对于第一种方式，会生成一堆固定模式的代码，如果允许直接修改这些代码，将造成很大的维护量；第二种方式，由于是解析执行，非常值得怀疑是否会造成JVM hotspot机制失灵，从而导致性能问题；最理想的方式我个人认为是生成代码，但限制这些代码为只读代码，同时保证这些生成代码也要建立在框架结构之上，从而可以再灵活动态拦截进代码。这样一方面，提供了MDA外的补充，即可以插写代码；另一方面可以充分利用JVM hotspot编译执行机制。
前面也提到了，由于MDA起源于架构师的经验，因此schema是不太可能保罗万象的。MDA在项目上的应用必须要提供一种补充机制。一般也就是采用AOP切面编程或回调机制来做这件补充。首先保证项目的价值实现，然后再后期将这些代码实现抽象进schema的范围，从而扩大元数据的表达能力。我个人认为元数据扩大的极限就是编程语言，呵呵，想想吧，这个认识不是空话，所以我MDA的系统一定是留着补充机制的。