爱威尔-java设计模式----综合案例开篇

说句实话设计模式这东西就像java编程设计的标准一样，还有java编程原则成为衡量java程序好坏和衡量java开发人员的标尺。 
 这些东西都不难理解，我们熟悉这些东西目的是为了可以在实际项目中用到来提高我们程序的质量。 
 其实每一个项目中都会或多或少的用到设计模式，另外每一个设计模式都有其使用的范围边界，那就是必须根据实际需求来考虑使用哪个设计模式。 
 
 之前发布了一些设计模式的范例，后来发现这样太枯燥了，最好的方式是拿项目说事，一切从实践中来到实践中去。 
 
 代码生成器有些人应该不陌生，也有一些框架中自带代码生成的东西，有的还直接和数据库联系起来，直接连数据库设计都包括了，如果单纯的做一个代码生成的程序具有一定的通用性还真不是件容易的事，因为大部分都是有特定模板限制的。通用就意味着设计的复杂度到大大提升，如果还要做到易用性那将对设计要求更高，越是智能程序设计就越复杂。 
 
 另外模板需要自己设计，所谓模板就是你们公司的程序开发的一套规范，开发程序正规一点肯定是要有规范的，无论从后台还是到前台，所以代码生成器最基本的通用性就是可以根据你自己设计出来的模板生成你想要的程序代码，如果通用性能达到这样的要求就可以应对千变万化的私人订制了。 
 
 那么摆在我们面前最大的难题就是通用性怎么实现，我们先放一放这个难啃的问题，我们先了解一下我们的程序都有什么，我们从里到外一个一个解剖： 
<img src="45/20150608110310_3.png" alt=""> 
 
 
 
 我这里暂且对java开发(主要针对j2ee)做一个简单的划分，这样我们就比较好的分析那些需要我们自动代码生成，那些不需要代码生成： 
 先说实体，如果你用jdbc 那么实体和vo就没什么区别了 
 如果你用框架特别是hibernate jpa 现在大部分都是基于注解形式的，而mybatis有xml文件，所以这部分的模板还是要分开处理的，没有注解的普通javabean，基于注解的，还有基于xml文件的，这个地方如果做的通用一点该怎么做，先思考思考。 
 DAO：这部分也有所不同，有的项目可能就做一份通用的CRUD接口和实现供service调用即可，有的项目可能是每一个实体对应一个dao的接口与实现，这也是要根据项目的大小和是否分布式处理来决定doa的设计。还有如果使用框架dao层设计起来就相对简单多了，模板也很好实现。 
 Service：这一层跟dao层差不多也还要封装实现CRUD，提供接口与实现，除非需要特殊的业务处理这一层也非常容易实现。 
 Action：控制层应该是变化最多了一层了，可能要对数据做处理，不管是交给service层处理还是在action层处理，但是相对还是有规律就是可循的，有些业务也就是说CRUD的操作。 
 Web层：这一层更多的是数据交互，与html，js打交道，对于一个规范的前端框架其格式也是基本固定的，相对也是有规律可循的。 
 
 上面分析的各个层面都是针对一个实体(对数据库来说就是数据库的一张表)，我们要对其填写各个字段和每个字段的属性(格式，大小，是否为空等等)，这些东西可以事先在数据库里面设计好也可以在程序里面在设计出来再有框架直接生成数据库表，现在框架的发展已经可以正向和反向操作数据库(这里在世不考虑nosql数据库，其实也可以做到的)。如果一切都按照模板来，我们只需要知道给每个表定义出来字段的含义和属性，我们就可以一路的生成增删改查以及分页的东西来，如果页面也有模板那连页面也可以一起生成，这对于开发工作来说可谓是大大的缩短开发周期，让开发只关注复杂的业务处理上来，这个时候我们就会发现这个代码生成器就像一个工厂一样再给我们提供代码而不需要我们自己去写了，这对于开发人员的要求就更高了，因为你已经脱离了写代码而是在设计代码和设计整个系统架构(当然这里我们不讨论页面布局和优化)，让开发人员更好的关注核心而复杂的业务处理上来。 
 <a class="ke-insertfile" href="http://www.loveweir.com/posts/view/42" target="_blank">设计模式案例分析图</a>