论坛首页 Java企业应用论坛

给做快速开发框架的人泼泼凉水

浏览 40350 次
该帖已经被评为良好帖
作者 正文
   发表时间:2008-10-30  
快速开发 <> 代码生成
0 请登录后投票
   发表时间:2008-10-30  
,用它来做配置文件的工作是绝对不妥当的。还不如直接在代码里面硬编码呢。

quote]
你用过jpa吗,用过Annotation吗
0 请登录后投票
   发表时间:2008-10-30  
其实,大家看上去都美.
0 请登录后投票
   发表时间:2008-10-30  
yanwt 写道
现在这个问题没有谁对谁错,支持代码生成的人是想在现有架构上面生成一些需要ctrl+c,ctrl+v操作的代码,由机器生成了,好处是生成一些配置文件不会出错,不需要大量的改动,增加工作效率。另一部分人是,想从根本上改变架构,尽量减少代码量,就目前的情况来看感觉不太现实。我做过的项目都是基于数据库的,持久化操作每个表都要写,每个表是不一样的,这部分代码是可以自动生成的。如果有人愿意自己写,我不反对,反正我是不喜欢重复的劳动。


Hibernate、iBatis、Spring JdbcTemplate都是动态生成sql的框架,何必事先生成?

当然是第一种方法好,也是大方向。

反过来说Hibernate的作者为什么不写个事先的sql生成工具呢,他完全有这个能力的。
0 请登录后投票
   发表时间:2008-10-30  
raymond2006k 写道
很同意大家回复的观点。

我的感觉, 美国人(或者外国人)做的东西, EJB,Hibernate,Spring,.... 中国人都会虚心学习;即便有缺点,也不太会有大的反对,而会探究是否是误用。

而同样的东西,中国人做出来,首先自己都觉得怀疑;还没详细了解清楚,就挑三挑四。中国人缺的就是自信,对自己自信,对他人自信。其实,我呆过的几个公司,都有技术牛人,能做二次封装,改良,或者框架等,而且做的都很棒;如几个牛人集中起来,也能做很多框架出来。现在 javaeye上的牛人也很多啊 。

只是希望国人对他人的创新多多互相评估,试用,以建设性的态度提意见,提缺点,提改进意见。


你认为的“中国人都会虚心学习;即便有缺点,也不太会有大的反对,而会探究是否是误用。”本身就是有问题的,老外每年也产出无数的框架,中国人难道每个都虚心学习;即便有缺点,也不太会有大的反对么?

都是在这些框架成熟(其他老外的认可)以后,这些框架的作者才会被称为牛人,先有鸡还是先有蛋不要搞混了。
0 请登录后投票
   发表时间:2008-10-30  
快熟开发和智能开发还有很大的距离,虽然大家谈的是是快速开发,
不如说是想达到智能开发.
在本人开来,一门成熟的语言+上成熟的构架在有个好的ide环境就算快速开发了.
比在dos上快多了.但要智能化的完成逻辑部分代码.才是下一步要解决的问题.
0 请登录后投票
   发表时间:2008-10-30  
fireflyc 写道
综合我见到过的所谓快速开发框架大多还都停留在第二种这个范围之内。也有一些试图去使用第一种本质上减少代码量的方法,但是结果不理想。比如那些对注解玩命追求的朋友,他们就是试图减少代码量可是,却并没有减少。想一下,你只是把以前的配置变成了注解而已谈何简化啊?更何况作为注解来说,它本身应该是代码的一部分,用它来做配置文件的工作是绝对不妥当的。还不如直接在代码里面硬编码呢。

首先你把普通的配置文件和专用配置文件搞混了,专用配置文件,比如Hibernate或dwr的配置文件,这些配置文件就是为代码服务的,不客气地说,这些配置文件就是代码,所以采用注解的方式,代码量上一定是减少的,因为xml作配置文件本身就不太合适,多余的字符特别多。同时IDE对注解的支持要远胜xml配置文件,在做重构、自动补全、编译期检查、单元测试和部署、代码维护(可读性和易读性方面)的环节上都能节省下大量的时间。
16 请登录后投票
   发表时间:2008-10-30  
yanwt 写道
icewubin 写道
yanwt 写道
现在这个问题没有谁对谁错,支持代码生成的人是想在现有架构上面生成一些需要ctrl+c,ctrl+v操作的代码,由机器生成了,好处是生成一些配置文件不会出错,不需要大量的改动,增加工作效率。另一部分人是,想从根本上改变架构,尽量减少代码量,就目前的情况来看感觉不太现实。我做过的项目都是基于数据库的,持久化操作每个表都要写,每个表是不一样的,这部分代码是可以自动生成的。如果有人愿意自己写,我不反对,反正我是不喜欢重复的劳动。


Hibernate、iBatis、Spring JdbcTemplate都是动态生成sql的框架,何必事先生成?

当然是第一种方法好,也是大方向。

反过来说Hibernate的作者为什么不写个事先的sql生成工具呢,他完全有这个能力的。

难道你不需要写数据库和对象之间的映射吗?不需要工具帮你生成?自己手写吗?我很佩服


基本不需要写,你可以参考ror的方式,SpringSide3也可以参考一下,或者看一下这个类org.hibernate.cfg.ImprovedNamingStrategy,代码生成本身就是一种笨拙的技巧,不失灵活性的动态生成加约定不是很好么。
0 请登录后投票
   发表时间:2008-10-30  

以上有不少同学是支持代码生成的,看来有必要继承一下rod joshon大叔的优良传统,对这种“封建的官僚主义”作风给予批判了。:-)~~以下是个人观点:(哈哈~)

代码生成本质上没有减少代码量的

 

代码生成技术只是把以前手工书写的代码变成了计算机自动生成的技术(只是手工ctrl+c ctrl+v的自动化版本),这种层面上说这些生成的代码其实是一种重复的东西,它们必然是类似的。有重复维护的时候就必然是一场噩梦。代码生成依然有很多代码,这些代码你依然要维护。更要命的是这是一种重复的行为,重复必然会引起以后修改的麻烦。

 

另外再次讨论一下我对注解的观点:

注解不能代替配置文件,配置文件的产生是为了方便修改配置文件而不是代码。比如数据库连接之类的,我们要以注解的形式放到代码中吗?再比如一个web层的action,它的返回模板需要以注解的形式放到代码中吗?有一天你把这些模板的路径修改了怎么办?(比如让模板的目录的结构更加清晰)你需要修改所有的action。这和直接写在action中有什么区别吗?你写到方法的上面和用后面return返回有什么区别吗?没有丝毫的区别,而且你写在注解上更让人看不懂,更费解了。

 

上面有朋友提到EJB3的注解,这种注解是合理的使用。我们没有可能在运行着系统的时候突然有一天说,把我们的EJB的remote接口变成local的吧,或者突然有一天说把我们的session bean由无状态变成有状态的吧。这种情况几乎没有的,即使有那么不修改代码也是不可能的。所以这些标志ejb接口remote、local标志session bean的特征应该是和代码在一起的,它们修改一定会引起代码的修改。

 

综上总结一下:注解是代码,它本身就是一种硬编码的形式。配置是外部的,配置的本意就是为了配置

8 请登录后投票
   发表时间:2008-10-30  
jindw 写道
呵呵,首先我得申明一下,我并没有任何恶意,看到你们做得东西确实也很不错。
大家都是过来人了,其中滋味我想大家自己也很清楚。当能,承认这里的个体差异。

有一天,我要去敲一个钉子,那么我有下面三个选择:
1。接合自身特点,自己铸一把锤子,把这个钉子丁下去。
2。市场上买把或者邻居家借把普通得锤子,把这个钉子钉下去。
3。随便找一快能用得石头,吧这个钉子钉下去。

没有任何一个选择是任何时候都正确。不同的人,不同的职业阶段,不同的环境我们会有不同的选择。

从成本的角度考虑,选择不同的方案取决于我有多少钉子去钉。
从个人成就感考虑,我们可能毫无疑问的选择方案一。[b][/b]


方案一这个是石器时代的做法啊。不过,话说回来了,软件开发本来就处于石器时代。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics