MVC架构的一些想法

      从开始接触j2ee开发到现在在很多的架构上开发过，架构基本上是分为web、service、dao、entity，并且一层层依赖，每写一个功能模块都至少要新建这四个层次的类，感觉很是繁琐。
      最近有开始自己整理一些架构，从一个同事那得到一些启发，他希望的是快速开发，尽量通用。于是我也将这种思想整入架构中，大致如下：
      对于数据操作，可以分为两种情况，一种绑定实体，一种不绑定实体，即方法对不同的实体都是通用的。
      绑定实体：
      与以前用过的架构原理相似，在dao基类中将entity抽象出来，使dao的每个子类都要并且只对应一个entity，这里可以通过泛型、注解或者抽象方法等方式让dao基类来获取到对应的entity，然而通过entity实现一些常用的增删改查等操作，dao子类只须指定对应的entity则可以通用基类的这些方法；service和web层类似，service绑定dao，web绑定service，每一层的基类中实现通用的增删改查等常用操作，对于一般的模块只须建立这四个层次的类继承分别的基类即可，一般情况下都不用去覆盖基类的方法了，这样下来一个模块除了entity类中有相应的代码外，其余几个类代码基本上都会很少。
      不绑定实体：
      写dao基类，与上一种不同，在这个dao的子类中不需指定对应的entity，基类同样写通用常用的方法，然后每个方法可以通过参数将entity类对象或者entity类直接传入即可知道当前是操作哪个entity了，在方法实现中通过传入的参数来获得entity的信息，这些信息可以包括entity的主键、对应的表、判断该entity在数据库中是否存在的SQL语句等等；
      编写service基类，这个基类依赖一个通用的dao类，实现通用并常用的一些方法，将entity从方法参数中传入；
      编写web层的基类，依赖一个通用的service类，写通用的一些方法，然而service的方法中需要传入entity类或者类对象，那么我将web层绑定entity，每个web层类需要绑定一个entity类，同样可以通过泛型、抽象方法或者注解等多种方法来实现这个绑定。
      这样一来一般的功能模块只须写单独的entity和web，web绑定entity，然后使用通用的service和dao，web层也已经有一些通用的方法了，一般的增删改查的功能基本上都可以通用了，一个模块也就只须写两个类了；然而如果有特殊的一些功能方法需要写，则可再写单独的service和dao来继承基类，再实现或者覆盖方法来实现这特殊的功能吧。
      
      大概就这样，我这里只是想到这么种架构的思想，具体框架、技术等可以挑选ssh等或者自己写都可以。当然想到的方面也很局限，想的这些应该也只适合一些小型的管理类项目吧。