|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-12-02
看看白衣的springside吧，基本不用配置，几乎什么都弄好了，ssh的best practice。
其实不是框架本身的问题，而是用的人的开发思想和技术结合的能力的问题。 fhjxp 写道 181054867 写道 深有同感，我跟你一样，只要可以不写的代码，坚决不写！
感觉Spring，Hibernate，Struct这些框架用起来都特别麻烦，一个简单的业务都要写不少的代码，又要改xml，又要在Java文件里改，改改改改，改死人才做好，烦死人！ Java程序的设计，简洁就是美，这些框架的确解决了一些问题，但带来更多的问题，真的没有提高效率，建议慎用！ ssh这些框架功能强大，同时它们要适应多种开发习惯，考虑各种扩展性、低耦合什么的，因此几乎对于任何具体的项目来说都存在不同程度的过度设计，我理解这也就是我们用这些框架感觉麻烦的根本原因。Spring，Hibernate,Struts的设计者都是大牛，不可能不懂得如何设计一个简单框架。 要解决框架使用麻烦的问题，就是需要定义我们自己的编码习惯，自己可以在这些框架基础上再做些工作，裁剪它们的用法，减少灵活性（灵活性和麻烦总是一对矛盾）。我自己也尝试做了一些这样的工作，搞自己的快速框架，做到了不再使用xml做配置文件了（有一部分是用注解代替了，但大部分配置是直接省去了），跟一年前比起来省事了很多，有时间自己在好好总结一下。 |
| 返回顶楼 | |
|
发表时间：2010-12-02
你学ror吧，ssh你看来一时半会儿习惯不了了，你需要的是快速开发
|
| 返回顶楼 | |
|
发表时间：2010-12-02
flashing 写道 看看白衣的springside吧，基本不用配置，几乎什么都弄好了，ssh的best practice。
其实不是框架本身的问题，而是用的人的开发思想和技术结合的能力的问题。 fhjxp 写道 181054867 写道 深有同感，我跟你一样，只要可以不写的代码，坚决不写！
感觉Spring，Hibernate，Struct这些框架用起来都特别麻烦，一个简单的业务都要写不少的代码，又要改xml，又要在Java文件里改，改改改改，改死人才做好，烦死人！ Java程序的设计，简洁就是美，这些框架的确解决了一些问题，但带来更多的问题，真的没有提高效率，建议慎用！ ssh这些框架功能强大，同时它们要适应多种开发习惯，考虑各种扩展性、低耦合什么的，因此几乎对于任何具体的项目来说都存在不同程度的过度设计，我理解这也就是我们用这些框架感觉麻烦的根本原因。Spring，Hibernate,Struts的设计者都是大牛，不可能不懂得如何设计一个简单框架。 要解决框架使用麻烦的问题，就是需要定义我们自己的编码习惯，自己可以在这些框架基础上再做些工作，裁剪它们的用法，减少灵活性（灵活性和麻烦总是一对矛盾）。我自己也尝试做了一些这样的工作，搞自己的快速框架，做到了不再使用xml做配置文件了（有一部分是用注解代替了，但大部分配置是直接省去了），跟一年前比起来省事了很多，有时间自己在好好总结一下。 这个说的才是正解~ 我们现在用Spring MVC在淘宝也进行了大规模的应用；而且几乎不需要配置文件~ 性能也非常好；扩展也非常好~ |
| 返回顶楼 | |
|
发表时间：2010-12-02
dragonsoar 写道 flashing 写道 看看白衣的springside吧，基本不用配置，几乎什么都弄好了，ssh的best practice。
其实不是框架本身的问题，而是用的人的开发思想和技术结合的能力的问题。 fhjxp 写道 181054867 写道 深有同感，我跟你一样，只要可以不写的代码，坚决不写！
感觉Spring，Hibernate，Struct这些框架用起来都特别麻烦，一个简单的业务都要写不少的代码，又要改xml，又要在Java文件里改，改改改改，改死人才做好，烦死人！ Java程序的设计，简洁就是美，这些框架的确解决了一些问题，但带来更多的问题，真的没有提高效率，建议慎用！ ssh这些框架功能强大，同时它们要适应多种开发习惯，考虑各种扩展性、低耦合什么的，因此几乎对于任何具体的项目来说都存在不同程度的过度设计，我理解这也就是我们用这些框架感觉麻烦的根本原因。Spring，Hibernate,Struts的设计者都是大牛，不可能不懂得如何设计一个简单框架。 要解决框架使用麻烦的问题，就是需要定义我们自己的编码习惯，自己可以在这些框架基础上再做些工作，裁剪它们的用法，减少灵活性（灵活性和麻烦总是一对矛盾）。我自己也尝试做了一些这样的工作，搞自己的快速框架，做到了不再使用xml做配置文件了（有一部分是用注解代替了，但大部分配置是直接省去了），跟一年前比起来省事了很多，有时间自己在好好总结一下。 这个说的才是正解~ 我们现在用Spring MVC在淘宝也进行了大规模的应用；而且几乎不需要配置文件~ 性能也非常好；扩展也非常好~ 其实springmvc和struts2都可以进行大规模应用的，没有问题，以前都实际用过。 说springmvc性能比struts2（可能是能好点，如果不调整struts2的拦截器栈的话），主要是没想明白，struts2的action虽然是prototype的（其实还做了cache），springmvc的controller是singleton的就像servlet，但是参数的对象每次都要组装啊，一个道理。 |
| 返回顶楼 | |
|
发表时间：2010-12-03
xieyongwei 写道 简单的应用用框架当然觉得繁琐
等你的项目越大，就觉得框架的方便之处了 框架也是越用越熟悉的，努力去用，光看没什么切身体会的 你好，能讲一下项目大后，框架的方便之处体现在哪里吗？ 麻烦你举一些例子，说明一下，谢谢！ |
| 返回顶楼 | |
|
发表时间：2010-12-03
fhjxp 写道 181054867 写道 深有同感，我跟你一样，只要可以不写的代码，坚决不写！
感觉Spring，Hibernate，Struct这些框架用起来都特别麻烦，一个简单的业务都要写不少的代码，又要改xml，又要在Java文件里改，改改改改，改死人才做好，烦死人！ Java程序的设计，简洁就是美，这些框架的确解决了一些问题，但带来更多的问题，真的没有提高效率，建议慎用！ ssh这些框架功能强大，同时它们要适应多种开发习惯，考虑各种扩展性、低耦合什么的，因此几乎对于任何具体的项目来说都存在不同程度的过度设计，我理解这也就是我们用这些框架感觉麻烦的根本原因。Spring，Hibernate,Struts的设计者都是大牛，不可能不懂得如何设计一个简单框架。 要解决框架使用麻烦的问题，就是需要定义我们自己的编码习惯，自己可以在这些框架基础上再做些工作，裁剪它们的用法，减少灵活性（灵活性和麻烦总是一对矛盾）。我自己也尝试做了一些这样的工作，搞自己的快速框架，做到了不再使用xml做配置文件了（有一部分是用注解代替了，但大部分配置是直接省去了），跟一年前比起来省事了很多，有时间自己在好好总结一下。 您能讲一下，你在适应框架上对自己的编码习惯做了什么调整吗，比如你以前一起是这样做的，为了适应框架的设计，又变成那样做了？ 希望你能举一些使用框架在实际开发中遇到的问题及你的解决方法，我非常想向这方面学习，谢谢你！ |
| 返回顶楼 | |
|
发表时间：2010-12-03
181054867 写道 fhjxp 写道 181054867 写道 深有同感，我跟你一样，只要可以不写的代码，坚决不写！
感觉Spring，Hibernate，Struct这些框架用起来都特别麻烦，一个简单的业务都要写不少的代码，又要改xml，又要在Java文件里改，改改改改，改死人才做好，烦死人！ Java程序的设计，简洁就是美，这些框架的确解决了一些问题，但带来更多的问题，真的没有提高效率，建议慎用！ ssh这些框架功能强大，同时它们要适应多种开发习惯，考虑各种扩展性、低耦合什么的，因此几乎对于任何具体的项目来说都存在不同程度的过度设计，我理解这也就是我们用这些框架感觉麻烦的根本原因。Spring，Hibernate,Struts的设计者都是大牛，不可能不懂得如何设计一个简单框架。 要解决框架使用麻烦的问题，就是需要定义我们自己的编码习惯，自己可以在这些框架基础上再做些工作，裁剪它们的用法，减少灵活性（灵活性和麻烦总是一对矛盾）。我自己也尝试做了一些这样的工作，搞自己的快速框架，做到了不再使用xml做配置文件了（有一部分是用注解代替了，但大部分配置是直接省去了），跟一年前比起来省事了很多，有时间自己在好好总结一下。 您能讲一下，你在适应框架上对自己的编码习惯做了什么调整吗，比如你以前一起是这样做的，为了适应框架的设计，又变成那样做了？ 希望你能举一些使用框架在实际开发中遇到的问题及你的解决方法，我非常想向这方面学习，谢谢你！ 对。。如果有这类文章。。我觉得对我们这些学习者是挺好的。可以从一种更为彻底的角度来理解，真正达到这是一种工具。可以玩的境界 |
| 返回顶楼 | |
|
发表时间：2010-12-03
dragonsoar 写道 flashing 写道 看看白衣的springside吧，基本不用配置，几乎什么都弄好了，ssh的best practice。
其实不是框架本身的问题，而是用的人的开发思想和技术结合的能力的问题。 fhjxp 写道 181054867 写道 深有同感，我跟你一样，只要可以不写的代码，坚决不写！
感觉Spring，Hibernate，Struct这些框架用起来都特别麻烦，一个简单的业务都要写不少的代码，又要改xml，又要在Java文件里改，改改改改，改死人才做好，烦死人！ Java程序的设计，简洁就是美，这些框架的确解决了一些问题，但带来更多的问题，真的没有提高效率，建议慎用！ ssh这些框架功能强大，同时它们要适应多种开发习惯，考虑各种扩展性、低耦合什么的，因此几乎对于任何具体的项目来说都存在不同程度的过度设计，我理解这也就是我们用这些框架感觉麻烦的根本原因。Spring，Hibernate,Struts的设计者都是大牛，不可能不懂得如何设计一个简单框架。 要解决框架使用麻烦的问题，就是需要定义我们自己的编码习惯，自己可以在这些框架基础上再做些工作，裁剪它们的用法，减少灵活性（灵活性和麻烦总是一对矛盾）。我自己也尝试做了一些这样的工作，搞自己的快速框架，做到了不再使用xml做配置文件了（有一部分是用注解代替了，但大部分配置是直接省去了），跟一年前比起来省事了很多，有时间自己在好好总结一下。 这个说的才是正解~ 我们现在用Spring MVC在淘宝也进行了大规模的应用；而且几乎不需要配置文件~ 性能也非常好；扩展也非常好~ 淘宝是用sping MVC的？？？ |
| 返回顶楼 | |
|
发表时间：2010-12-03
181054867 写道 xieyongwei 写道 简单的应用用框架当然觉得繁琐
等你的项目越大，就觉得框架的方便之处了 框架也是越用越熟悉的，努力去用，光看没什么切身体会的 你好，能讲一下项目大后，框架的方便之处体现在哪里吗？ 麻烦你举一些例子，说明一下，谢谢！ 还是拿Spring举例吧。用Spring这种东西，项目做的小是看不到明显好处的，当项目扩展后，Spring这种粘合剂式的框架就能发挥作用，比如无缝的结合Hibernate、iBatis、Struts1、Struts2等流行框架；使用AOP功能在不改动现有代码的情况下增加功能，比如权限过滤、缓存；直接使用Spring内置的hessian、burlap、rmi、http invoke等远程调用功能，经过简单配置后与其他项目交互数据而不需要修改现有代码；使用Spring内置的Security框架进行安全管理；直接使用Spring封装好的jdbc模板进行数据存取；数据源使用配置文件进行配置，可以快速加入多数据源支持；本身自带有大量工具类，例如apache common，JodaTime等。 这应该都算是Spring优势的地方吧。至于免费、可用于商业开发、稳定可靠、使用广泛、社区支持好那些说烂的方面就不讲了——虽然很重要。 |
| 返回顶楼 | |
|
发表时间：2010-12-03
imacback 写道 dragonsoar 写道 flashing 写道 看看白衣的springside吧，基本不用配置，几乎什么都弄好了，ssh的best practice。
其实不是框架本身的问题，而是用的人的开发思想和技术结合的能力的问题。 fhjxp 写道 181054867 写道 深有同感，我跟你一样，只要可以不写的代码，坚决不写！
感觉Spring，Hibernate，Struct这些框架用起来都特别麻烦，一个简单的业务都要写不少的代码，又要改xml，又要在Java文件里改，改改改改，改死人才做好，烦死人！ Java程序的设计，简洁就是美，这些框架的确解决了一些问题，但带来更多的问题，真的没有提高效率，建议慎用！ ssh这些框架功能强大，同时它们要适应多种开发习惯，考虑各种扩展性、低耦合什么的，因此几乎对于任何具体的项目来说都存在不同程度的过度设计，我理解这也就是我们用这些框架感觉麻烦的根本原因。Spring，Hibernate,Struts的设计者都是大牛，不可能不懂得如何设计一个简单框架。 要解决框架使用麻烦的问题，就是需要定义我们自己的编码习惯，自己可以在这些框架基础上再做些工作，裁剪它们的用法，减少灵活性（灵活性和麻烦总是一对矛盾）。我自己也尝试做了一些这样的工作，搞自己的快速框架，做到了不再使用xml做配置文件了（有一部分是用注解代替了，但大部分配置是直接省去了），跟一年前比起来省事了很多，有时间自己在好好总结一下。 这个说的才是正解~ 我们现在用Spring MVC在淘宝也进行了大规模的应用；而且几乎不需要配置文件~ 性能也非常好；扩展也非常好~ 淘宝是用sping MVC的？？？ 淘宝网买家系统大部分是用WebX框架的，只有：japan.taobao.com这个子域名下面的应用都是用Spring MVC的。 |
| 返回顶楼 | |
