j10A
2006-07-06 19:49
若向“关联级CRUD”发展,无疑这个项目会走向失败。

santafeng
2006-07-06 20:59
> 我现在的项目也是这样做的,基本思想和你类似,只需要用工

> 吒菔菘馍Bean就可以了,bean和数据库表及表的字段?> 一对应。

> 在增删改查时用反射取得bean对应的表,字段等拼成sql语句?> 对简单的增删改提供了统一方法,程序员直接调用即可基本不

> 迷傩sql语句,复杂的查询语句还是要自己写。

> 查询语句的结果封装成POJO,或者动态bean.

>

> 优点是上手快,开发速度快,缺点是现在还没有处理对象之间

> 墓叵怠?

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

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

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

santafeng
2006-07-06 21:00
> 若向“关联级CRUD”发展,无疑这个项目会走向失败。

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

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

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

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

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

猜你喜欢
15Go 上一页 1 2 3 4 5 6 7 ... 15 下一页