若向“关联级CRUD”发展，无疑这个项目会走向失败。

> 我现在的项目也是这样做的，基本思想和你类似，只需要用工
> 吒菔菘馍Bean就可以了，bean和数据库表及表的字段?> 一对应。
> 在增删改查时用反射取得bean对应的表，字段等拼成sql语句?> 对简单的增删改提供了统一方法，程序员直接调用即可基本不
> 迷傩sql语句，复杂的查询语句还是要自己写。
> 查询语句的结果封装成POJO,或者动态bean.
>
> 优点是上手快，开发速度快，缺点是现在还没有处理对象之间
> 墓叵怠?

是么，你也有相同的框架么？开源么？能否大家一齐交流交流经验。

你说的是表、视图对象逻辑设计模式，表对象和视图对象是javabean，逻辑是bo。

处理对象间关系我们已经有一套已经实现了的内部框架，不过需要重构才能开源。

> 若向“关联级CRUD”发展，无疑这个项目会走向失败。

请教为何“关联级CRUD”发展会走向失败？我比较愚昧，能否告诉我。

这个框架是因为项目需要才开发的，本来打算用hibernate，但是由于开发人员的能力问题，所以才作了这么个不需要任何配置，提供大部分基础查询的框架，把开发的门槛降到最低限度。毕竟对于项目来说只要实用就好。

table和view是javabean, 业务逻辑是BO.曾经打算增加处理对象关系的功能，但是实现功能的时间太多，带来的效果可能不会太大，所以就没做。

这个框架由于是在现在这个公司做的，而且项目中参与开发的还有其他公司，所以不可能开源了。其实我个人感觉这个框架没什么难度，是个技术与习惯妥协的产物。

楼主的这个框架，简单是简单了，但是建立在牺牲灵活性的基础上。假如某些系统对表名、字段名有命名规则，则这个框架恐怕难以应用吧。

> 这个框架是因为项目需要才开发的，本来打算用hibernate，?> 是由于开发人员的能力问题，所以才作了这么个不需要任何配
> 茫峁┐蟛糠只〔檠目蚣埽芽⒌拿偶鹘档阶畹拖薅取
> 毕竟对于项目来说只要实用就好。
>
> table和view是javabean,
> 业务逻辑是BO.曾经打算增加处理对象关系的功能，但是实现?> 能的时间太多，带来的效果可能不会太大，所以就没做。
>
> 这个框架由于是在现在这个公司做的，而且项目中参与开发的
> 褂衅渌，所以不可能开源了。其实我个人感觉这个框架?> 什么难度，是个技术与习惯妥协的产物。

同意，开发一个框架是没有难道的，难就难于把常用的代码抽离于业务，形成一个可以通用的框架。还有是使用框架的标准制订。hibernate光看源码其实就是按照xml配置映射级别去安排结构，只要标准有了一切都是比较容易实现。

楼主的这个框架，简单是简单了，但是建立在牺牲灵活性的基础上。假如某些系统对表名、字段名有命名规则，则这个框架恐怕难以应用吧。

这样把请把您遇到的问题说出来大家讨论讨论。

我们可以使用实际的例子说明问题及解决问题。

我现在参与的一个大型项目，表的数目已经突破600张，如何管理这些表呢？我们制定了一个严格的命名规范，对表进行类别、模块划分。举例说，对于Contact这样一个实体，它对应的表也许是R_CRM_CONTACT，如果应用你们的框架，那么我的PO是不是要命名成R_CRM_CONTACT呢？因为你们是根据反射机制来的。

> 我现在参与的一个大型项目，表的数目已经突破600张，如何?> 理这些表呢？我们制定了一个严格的命名规范，对表进行类别
> ⒛？榛帧＞倮担杂Contact这样一个实体，它对应的表
> 残硎R_CRM_CONTACT，如果应用你们的框架，那么我的PO是不
> 且R_CRM_CONTACT呢？因为你们是根据反射机制来的。

对啊，这会出现什么问题？

在以前的公司,我也弄了这样类似的东西.不过我有一个table表,一个column表,把所有的表和字段都存起来,这样不仅实现了基本的增删查改,还可以实现针对单表的所有字段的and,or拼条件查询,以及单表的excel导入导出.
table表中保存了javabean的名字,这样就可以不按照表名来取bean的名字了.
不过这个东西不是很通用,只能实现简单的增删查改,复杂点的查询,表之间的关联就不好处理了.

> 对啊，这会出现什么问题？

这将违反Coding Standard，在项目中，Coding Standard对代码控制和维护都非常重要。0配置的代价就是灵活性，灵活性差的代价，我认为就是导致这个框架难以推广。当然，0配置是这个框架的优势所在，在一些小型应用中应该比较适合。

> 在以前的公司,我也弄了这样类似的东西.不过我有一个table?> ,一个column表,把所有的表和字段都存起来,这样不仅实现了?> 本的增删查改,还可以实现针对单表的所有字段的and,or拼条?> 查询,以及单表的excel导入导出.
> table表中保存了javabean的名字,这样就可以不按照表名来取
> ean的名字了.
> 不过这个东西不是很通用,只能实现简单的增删查改,复杂点的
> 檠?表之间的关联就不好处理了.

不太明白。所有数据库都已经有这些元数据，为何还要自己来维护呢？

请解释什么叫小型应用，听你说的，一个项目600张表，哇，真的很吓人，但是你实际操做的有多少张表，我是做电信项目的，基本还不止这个数，谈到编码规范，使用这个框架javabean 和 表明对应难道不是编码规范，规范也是人定的，只是让大家有一个统一的口径去理解和查找，而且大项目更应该以灵活的，简单，快速的框架去开发，这样才能做到方便维护和扩展，另外这类型项目时间间隔是比较长，需求变动也很大，业务逻辑也比一般应用复杂，项目进行期间人员流动性也会比较大，这样的框架不但可以降低开发门槛，节约开发时间，解放程序员开发难度，而将精力集中在业务逻辑上，我不知道简单有什么不好，难道每天对者一大对文档参照和配置文件开发是好事？

你还没用speed框架做项目，因为speed1.01目前的规范就是表名＝po名，具体根据表、视图对象逻辑设计模式进行快速开发。

这样开发出来的代码基本很简单交给其他人的接手，例如表增加字段，就在相应po加属性，bo内部出来查询sql外，其他都增、删、改都不必修改代码。

这样规范出来，可以说就连小学生都知道是怎么一回事。我们开发系统就是要有人维护继续扩展，如果你设计的代码规范还需要太多文档跟进和人员太多的沟通表述的话，万一表述不清楚或者理解不清楚就是一个致命伤。至少目前使用speed开发的系统都不需要太多的了解前人开发的思维，光看sql就可以知道它究竟是干什么，如何干。

所谓的高手就是写一些做一些令人无法理解的代码。如果简单的就不属于高手，不知道大家是否都这样理解？是否荒诞。

> >
> 在以前的公司,我也弄了这样类似的东西.不过我有一个table?
> ,一个column表,把所有的表和字段都存起来,这样不仅实现了
> >
> 本的增删查改,还可以实现针对单表的所有字段的and,or拼条?
> 查询,以及单表的excel导入导出.
> >
> table表中保存了javabean的名字,这样就可以不按照表名来取
>
> > ean的名字了.
> >
> 不过这个东西不是很通用,只能实现简单的增删查改,复杂点的
>
> > 檠?表之间的关联就不好处理了.
>
> 不太明白。所有数据库都已经有这些元数据，为何还要自己来
> つ兀?

因为有一些需要的字段没有,比如每张表对应的javabean,某个字段是否在列表中显示,是否在查询中显示