前天那篇blog更多的是讲了下数据驱动、模型驱动的大致概念，今天更多的是讲数据驱动以及模型驱动在进行系统实现时的方法以及过程。
数据驱动
采用数据驱动进行系统实现时通常采用的是一个这样的过程，建立数据源(DataSource)，同时根据业务对象模型进行数据库表设计，在数据库表设计完成后根据业务场景构成数据集(DataSet)，通常这个时候DataSet本身就是一种业务场景所需的业务数据，在简单的情况下有可能就是对某张表的操作，复杂的情况下则是对于多张表的操作，在DataSet构成后将此DataSet绑定到页面即可进行数据的展现了，如需对数据进行增加、编辑、删除同样通过DataSet方式来进行，这个过程基本上就是一个基于数据驱动进行系统实现的过程了。
模型驱动
采用模型驱动进行系统实现时通常采用的是一个这样的过程，根据业务场景建立业务对象，在进行持久时持久业务对象中需要持久的属性，对于业务场景的实现通过Facade模式对外提供统一接口，此接口通过与持久层进行交互以及操作业务对象(或领域对象)来完成业务场景的实现，而页面则通过此领域对象或显示对象来进行数据的展现，如需对数据进行操作按照显示对象--->Service Facade来完成。
从上面关于实现的过程的描述上来说，会觉得好像模型驱动更为复杂，但模型驱动较之数据驱动的优点我想不用多少，这里更重要的是我觉得是对于数据驱动和模型驱动的一个理解，其实数据驱动同样是模型驱动，呵呵，数据驱动中的业务对象模型我们可以认为和模型驱动中的业务对象模型一致，其和模型驱动的不同点在于数据驱动采用DataSet的方式来实现业务场景，而模型驱动通常采用Service Facade调用各领域对象来实现业务场景，这里有一点非常明显，数据驱动只适合一种简单的业务场景，那就是通过数据关联或简单的数据逻辑处理可以来实现的业务场景，而Service Facade其实对于两者均通用，通过构建类似DataSet的数据关联或简单的数据逻辑处理通过和持久层交互即同样达到了如此的目的，^_^，而且这种方式对于复杂的业务场景同样可以实现，通过领域对象的交互即可完成，而在DataSet方式中这个步骤是比较棘手的，虽然也可以处理，但会带来的问题就是重复代码的增多以及可维护性的降低，其实关键的问题就是其没有形成对象，内聚性不够强。
我的观点仍然是数据驱动是一种退化的模型驱动或者说变相的模型驱动，数据驱动中根据业务对象模型进行数据库表设计的这个过程可以映射为在模型驱动中进行业务对象模型实现的过程，而建立数据集的过程则和模型驱动中的Service Facade颇为相似，只是其Service Facade中的方法比较简单，至于DataSet绑定到页面这个过程其实和模型驱动中将领域对象或显示对象和页面绑定是相同的概念。
模型驱动思想才是王道，
，需要的仅仅是架构体系中对于数据驱动这种变相的模型驱动也提供一个良好的支持，其实我觉得通过上面的描述已经可以看到要去做出这个支持是非常简单的一件事，抽象形成通用Service Facade以及考虑如何建立DataSet即完成了这个实现，而且这样的架构对于模型驱动同样支持，^_^，何乐而不为，鱼和熊掌均可得之(其实就只有熊掌，只是一个可能是肥壮一些的，一个是瘦弱一些的，^_^)。