继续侃数据驱动和模型驱动

前天那篇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即完成了这个实现，而且这样的架构对于模型驱动同样支持，^_^，何乐而不为，鱼和熊掌均可得之(其实就只有熊掌，只是一个可能是肥壮一些的，一个是瘦弱一些的，^_^)。




数据驱动、模型驱动作为如今软件设计中两种不同的模型驱动方法，应该说各有各的优缺点以及适用的场合，不能就一概的去认为哪种必然就是更好的。
数据驱动采用的方式是根据对业务的分析建立数据模型来进行系统设计的一种方法，通过数据模型的建立来完成系统的实现，一般来说，在采取数据模型的系统中多采用的是前台直接和数据模型进行绑定的方式，这样在实现起来相对来讲会非常的快速。根据数据驱动的系统设计以及实现方式上来讲，数据驱动适合于数据型的应用系统的建设，而现在大部分的中小型应用系统很多就停留在这个层面上，在这类系统中数据驱动会显得特别的实用和好用，这类系统一个非常突出的共同点就是系统基本属于信息的录入、显示以及查询这样的一个过程，不存在复杂的数据业务逻辑处理。
模型驱动采用的方式根据对业务的分析建立业务对象模型来进行系统设计的一种方法，通过业务对象模型结合系统架构约束来进行系统的实现，一般来说，在采取模型驱动的系统中多采用N层的结构体系，前台显示一般和业务显示模型进行交互，而业务显示模型则通过业务对象模型进行交互来完成业务逻辑的处理，业务对象模型通过与持久对象模型进行业务持久的处理，在这样的情况下，势必增加了系统的复杂度，模型驱动适合与业务型应用系统的建设，这个在行业化的业务应用上显得比较突出，这类系统的共同点在于业务逻辑较为复杂而且多变，系统不仅仅是信息的录入、显示以及查询，更多的是对录入或显示的信息进行业务逻辑的处理。
经过上面的简单介绍后，我觉得对于数据驱动和模型驱动都会有个大概的概念，只能说数据驱动和模型驱动各有优势，要结合系统需求来选择相应的驱动方式。
对于模型驱动个人有些观点，其实从模型驱动我们可以看出如果采用模型驱动面对一个数据型的应用系统时，最后产生的业务对象模型即退化为了数据模型，只是由于模型驱动通常采用的N层架构此时反而约束了此模型的快速实现，是否应该在模型驱动的N层架构中去考虑一种退化的业务对象模型的支持呢？觉得这点是值得思考的，如果支持的话应该说对于模型驱动非常有利或者说是模型驱动的一个补充，相当于对于模型驱动进行分类处理，有些时候架构不能太S，还是要根据系统建设的需求做出适当的调整。
根据这样的观点，其实数据驱动也是模型驱动，只是它采用的是一种退化的业务对象模型的驱动，并同时进行架构层次的调整以适应系统的快速建设，但数据驱动对于复杂多变的业务逻辑系统来说毕竟难去满足了，主要是会在数据模型的建立以及业务逻辑的修改的方面。
综合这样的观点，还是更为倾向模型驱动，同时也认为，模型驱动的架构应该考虑对于退化的业务对象模型的支持。