锁定老帖子 主题:关于Java开发不明白的一些问题
该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2011-03-09
nianien 写道 以前代码的整体感没有了,现在就是把一个完整的躯体给直接给肢解了,把关注的部分留下来,其他的都送给框架了, 没错,是把关注的部分留下来,其它送给框架。 nianien 写道 解个屁耦,难道Struts不是一个Web框架么?哪里能少得了Servlet API?没有Servlet,Struts屁都不是, 这里解耦的不是Web和Struts吧? nianien 写道 就算你解耦又如何?我还不是需要Request对象和Response对象?我使用了ContextUtil也能算解耦呢? 做Web开发又去和Web解耦,真是闲得蛋疼! 给你输入和输出就行了吧?为什么非要纠结Request和Response?确实有些功能Request和Response必须,不是大多数吧? nianien 写道 2)更容易测试,Web工程里面的逻辑有几个是脱离了Web环境来测试的? 我这里有好多。。。 nianien 写道 3)Struts2比Struts1更容易理解,完全是放屁 不看文档,鬼知道从哪里获取Request对象和Response对象! 而且一个action又做M又做C,干脆你连V也做了,不更省事?不过话说这样的话,我还用得着框架? 没太理解您的意思,可能用法上的问题吧。 关于接口和IOC楼上几位牛人讨论过了,不再费话。 最后,感谢楼主发起的讨论,祝工作顺利~ |
|
返回顶楼 | |
发表时间:2011-03-09
其实刚开始的框架还是很不错的.现在的java好像已经成了框架控~无论做什么东西解决办法就一个 框架!现在的程序员不再关系底层的关系.不在关心是如何实现..包括我在内都成了码字工
|
|
返回顶楼 | |
发表时间:2011-03-09
人们只所以要解耦,要接口,要框架。是基于在现实实践中,使问题得到更好更快的解决。
当然这里就有个选择的问题,要考虑实际情况,即不能杀鸡用牛刀,也不能全盘否定。 |
|
返回顶楼 | |
发表时间:2011-03-09
最后修改:2011-03-09
vtudiv 写道 nianien 写道 以前代码的整体感没有了,现在就是把一个完整的躯体给直接给肢解了,把关注的部分留下来,其他的都送给框架了, 没错,是把关注的部分留下来,其它送给框架。 送给框架然后就不明所以了,如果是流行的框架还好说,大家都懂,但是现在哪个公司不是自己整一套框架,就是把人家的框架改的面目全非,给你一个陌生的框架,你会看得云里雾里. 就像一张脸,如果你知道这张脸是一个活人的,你会觉得它很美,但是如果你知道它是被扯下来的一张脸,那么就很恐怖! 这里不是反对用框架,用框架那必须的,我反对的是那种削足适履的行为,请明白我的意思~ vtudiv 写道 nianien 写道 解个屁耦,难道Struts不是一个Web框架么?哪里能少得了Servlet API?没有Servlet,Struts屁都不是, 这里解耦的不是Web和Struts吧? nianien 写道 就算你解耦又如何?我还不是需要Request对象和Response对象?我使用了ContextUtil也能算解耦呢? 做Web开发又去和Web解耦,真是闲得蛋疼! 给你输入和输出就行了吧?为什么非要纠结Request和Response?确实有些功能Request和Response必须,不是大多数吧? 不是我纠结与Request和Response,有输入和输出的话,一个方法就可以了,和框架有什么关系呢?我不论用Struts1或者2,我都可以把实现某个功能的代码段抽象成方法,Struts2所谓的易于测试显然不是它的功劳 vtudiv 写道 nianien 写道 2)更容易测试,Web工程里面的逻辑有几个是脱离了Web环境来测试的? 我这里有好多。。。 大哥,你那么多,不能抽象成方法么?如果是方法的话,你直接测试方法不就可以了,与框架的解耦有啥关系呢? 我这里只想说,离开Request和Response的测试和Struts2没有啥关系,也和Struts1或者其他任何框架都没关系 太多的人膜拜框架了,框架不过也是代码,也是方法调用,即使面向对象最终还是通过面向过程来实现,本质上就是封装 vtudiv 写道 nianien 写道 3)Struts2比Struts1更容易理解,完全是放屁 不看文档,鬼知道从哪里获取Request对象和Response对象! 而且一个action又做M又做C,干脆你连V也做了,不更省事?不过话说这样的话,我还用得着框架? 没太理解您的意思,可能用法上的问题吧。 没有啥用法上的问题,用框架,要么按照说明使用,要么明白原理,打破规则 关于Struts2的action职责不清,不是我提起的,好多专家都有争论过, 当然,这是见仁见智的问题,如果你不明白,我也不好说啥了? |
|
返回顶楼 | |
发表时间:2011-03-09
之前有人发了一个贴,质问为啥写一个helloworld,就需要写7、8个东西
我觉得他的想法和楼主的想法是一样的, 我也一直在想。写一个不复杂的东西,弄那么多东西做什么用呢? 接口我觉得只有在给其他人使用的时候才有效果,否则是否都是扯淡呢。 静下心来,看看系统中有多少级接口就是只有一个,而且在可预见的将来也就只有这一个实现。 现在为将来(不可能出现的将来)买单是否有必要呢? |
|
返回顶楼 | |
发表时间:2011-03-09
vtudiv 写道 nianien 写道 一个包含了全部逻辑的方法,拿到哪里都能用,现在呢,解耦了,复用去吧,离开框架你屁都不是,还解耦呢! 都是用输入调用逻辑获得输出,想不明白这里为什么骂框架,就因为它自动为你注入了输入? 也可能我没理解你利用的粒度。。。 不是我骂框架,现在非常规的编程已经变成了常规,这是一种非常糟糕的事情,你能说注入参数是编程的常态么? 有了注入,有了拦截,你的方法执行结果可能完全不是按照你所设计逻辑来执行! Spring所提出的什么AOP,什么IOC,什么DI说白了就是反射和动态生成Java Code的东东, 本来JAVA就是个静态的语言,现在越来越搞的自己想动态似的! 来点动态的甜点是不错,可总不能当饭吃吧,看着那么多玩概念的人,腻歪死了! 现在的框架越来越喜欢大而全的东西,不知道所谓的full-stack是不是这样意思?EJB的臃肿让人们投向Sring,这是问什么?难道EJB的功能不比Spring强么?框架为你提供服务的前提就是你要遵守它的规则,它提供的功能越多,你要遵守的规则往往也越多,而且好多的封装就是简单的方法调用 |
|
返回顶楼 | |
发表时间:2011-03-09
soft_xiaohui 写道 人们只所以要解耦,要接口,要框架。是基于在现实实践中,使问题得到更好更快的解决。
当然这里就有个选择的问题,要考虑实际情况,即不能杀鸡用牛刀,也不能全盘否定。 你说的很对,我完全同意,但是现在的人却偏偏喜欢拿着牛刀杀鸡,还不停地向人炫耀~~~~~~~ |
|
返回顶楼 | |
发表时间:2011-03-09
感谢楼主的耐心解答,小弟愚钝,还是没太理解。。。
1.没看懂你那个比喻,虽然确实很恐怖; 2.什么叫抽象成方法; 3.为什么不纠结Request和Response,又说做Web开发与Web解耦是蛋疼? 4.写Struts2的Action时绝大多数情况不需要Request和Response,直接测试就行,而Struts1不行,所以和框架还是有一定关系的吧? 谢谢~ |
|
返回顶楼 | |
发表时间:2011-03-09
vtudiv 写道 感谢楼主的耐心解答,小弟愚钝,还是没太理解。。。
1.没看懂你那个比喻,虽然确实很恐怖; 2.什么叫抽象成方法; 3.为什么不纠结Request和Response,又说做Web开发与Web解耦是蛋疼? 4.写Struts2的Action时绝大多数情况不需要Request和Response,直接测试就行,而Struts1不行,所以和框架还是有一定关系的吧? 谢谢~ 1.哪个比喻是是说,框架会改变你的方法逻辑,比如拦截器你懂的,不就不多说了 2.一段代码逻辑,封装起来就是方法 3和4.不管什么项目都是由代码组成的,代码可以划分为函数,也可以划分为方法,总之需要一些输入和输出 当然对于方法而言,也可以不需要显示输入,因为方法的载体——对象可以提供 当你用Request和Response的时候,只有两种情况: 第一,如果你用的不是用这两个对象本身,而是需要它所载有的数据信息, 那么凡是它能够提供的数据你都可以抽象成参数, 于是,这里Struts2的解耦根本就是画蛇添足,完全不必要的 第二,如果你用的是Request和Response对象本身,那么你就必须有Web容器的支持, 这样,Struts2就根本不肯能解耦,即使你提供嵌入式的Web组件,这也不叫解耦,那是测试提供的非开发环境而已 |
|
返回顶楼 | |
发表时间:2011-03-09
我 相信能吧此人说得心服口服的人 定是大牛,坐等大牛出现
|
|
返回顶楼 | |