关于JAVA框架的思考

目前的JAVA 企业级开发框架，我们常用的大致包括IOC AOP MVC ORM框架
1、 IOC spring是一个非常棒的ico容器，其思想非常简单，用一个集合对象如MAP 来缓存对象（对象都是单例的），这也就是spring 所说容器内单例，它和java中的单例模式的区别在于单例模式是在当前java进程中保持单例，因为它有三个必要条件:private static 自身对象、private 构造方法、public static getInstance()方法，以保持在进程中单例，而spring只能保证在容器中单例，用户是可以手动再new出其他对象的。所以这部分如果为了简单可以不使用spring的ioc框架以单例模式替代，减少spring的jar包，缺点是可维护性和扩展性较差。或自己写一个ico容器以实现spring的ico功能。
2、aop aop的实质是动态代理模型，框架包括spring、AspectJ等，当然最行的是spring, spring有两种实现形式，一种是jdk的动态代理，一种是cglib字节码框架（比jdk的反射要快，其asm框架实现），典型的场景是数据库事务，个人感觉aop的应用其实可以去掉。可维护性并没有提高，反而变更复杂。aop事务是在threadlocal是以threadlocal为基础的。关于aop去或留希望各位讨论。
3、mvc框架 spring mvc struts2 这两个框架相比:spring mvc的思想还是比较先进的，因为struts2的action bean不是单例的，每次通过反射new出一个对象，性能会相对较低。而spring mvc controller是单例的，继承至servlet类（单例多纯种）。它的实现思想的是方法参数的注入。两个都支持模型驱动。spring mvc有一个缺点，注解的配置模型全部用的java反射。性能也会有影响。两者都支持注解，个人认为xml要好于注解，开发阶段注解要优于xml,因为方便，而维护起来可能会比较麻烦，尤其是对刚接手项目的新人。最好的方案是取两者之长，去其缺点，保留spring的单例通过方法注入，注入时将jdk反射去掉，换成asm的注入思想，以提高性能。
4、ORM框架 hibernate mybatis。hiberate是全自动的orm框架，优点是简单使用方便，但jar包很多，大数据SQL调优问题比较大。mybatis 由ibatis升级，半自动orm框架，需要手动写sql,优点是方便sql调试，缺点是对于简单的单表增删改也需要手动写SQL,比较麻烦。所以最好是结合两个框架的优点开发一个单表的增删改orm（不依赖SQL），复杂SQL可以直接通过JDBC这样可以提高性能。

评论

46 楼 alexlx 2013-07-22  

框架始终都只是工具，开发出来是帮人解决问题的。
首先要明确了解框架能解决什么问题，然后再在实际工作中权衡采用或者不采用某种框架。

45 楼 windshome 2013-07-22  

其实说白了，最重要的是，负责人要有责任心、要不怕困难，要有长远的考虑，本着这样的精神来做设计和开发。

44 楼 zh_harry 2013-07-22  

windshome 写道

我觉得扯得太远了，没有那么大的目标，也不一定说全部都自己做，不用别人的框架，我的主张只是在你用别人的东西之前，把方方面面的事情想清楚了。

不仅仅是当前实现功能，还包括后期的改进完善、bug的修改，维护的成本和代价，框架出现问题你能否修改。


那句原则“没有免费的午餐”是非常睿智的，吃了免费的午餐，就别嫌不合乎自己的口味，营养单一；如果想吃丰盛的大餐，美味佳肴，需要耐心，需要代价。做一个产品或一个项目，根据需求和场景去衡量，到底怎么取舍，是拿现成的开源组件拼凑，还是自己从头做起，还是怎么样来搞，是需要平衡和妥协的。

再有，使用了开源的框架和组件，开始没有付代价，但是到后期维护、改进、bug修改时再付代价，挤牙膏的方式付代价，俗话“背着扛着一样沉”。不要有图便宜的思想，不要指望别人努力工作，解决你的问题，而你不需要付出任何代价！！！这是一个关键问题。

这就是五年和两年的区别！前期的规划，权衡和思考会对后期的开发和维护产生生很大影想，所以用一个框架的出发点不止是会用，能实现功能。要考虑的事情真的很多。回复越来越有质量了！

43 楼 windshome 2013-07-22  

我觉得扯得太远了，没有那么大的目标，也不一定说全部都自己做，不用别人的框架，我的主张只是在你用别人的东西之前，把方方面面的事情想清楚了。

不仅仅是当前实现功能，还包括后期的改进完善、bug的修改，维护的成本和代价，框架出现问题你能否修改。


那句原则“没有免费的午餐”是非常睿智的，吃了免费的午餐，就别嫌不合乎自己的口味，营养单一；如果想吃丰盛的大餐，美味佳肴，需要耐心，需要代价。做一个产品或一个项目，根据需求和场景去衡量，到底怎么取舍，是拿现成的开源组件拼凑，还是自己从头做起，还是怎么样来搞，是需要平衡和妥协的。

再有，使用了开源的框架和组件，开始没有付代价，但是到后期维护、改进、bug修改时再付代价，挤牙膏的方式付代价，俗话“背着扛着一样沉”。不要有图便宜的思想，不要指望别人努力工作，解决你的问题，而你不需要付出任何代价！！！这是一个关键问题。

42 楼 zh_harry 2013-07-21  

alvin198761 写道

别人的语言也没意思，咱自己写一个吧，来，扶清灭洋，走起

Leon.Wood 写道

zh_harry 写道

zh_harry 写道

alvin198761 写道

一群用框架的人早就了中国IT行业的技术现状，一批用windows的人，早就了中国对windows的依赖的现状，

我不用框架，不用第三方jar，java开发照样继续，看到讨论框架还争来争去，想问一句，咱能自己写个框架，然后讨论自己的好不好行不，你说的好不好，都是别人的东西，有意思吗？

已经写了呀，看我的博客，并且已经开源了http://lizhizhang.iteye.com/blog/1896545
大家拍砖
上面说得这些思想全包括了，还在升级中，希望大家关注...
也希望小编小这编文件也推荐到首页，绝对原创，没有一个jar,0框架开发，我很喜欢你所说的。
这个框架的名字我给他叫sparrow
麻省虽小，五脏俱全，其实中国就应该用自己的框架

再加一句，这么多人看过只有你提出这个问题，很棒！！

用别人的语言也没意思，咱自己写一个吧，来，扶清灭洋，走起

产生一个新的语言不是为了扶清灭洋，而是一个公司自己的业务需要，加上自己的技术积累，有这个能力了，在当前语言没法满足自己的要求下，开始做的，java也是因此产生的。国内技术能力不说低于美国，至少是低于 日本，韩国，印度，这些国家的，其主要原因不是人的问题，是制度早就的，上面层层转包，给下面一个很少的费用，老板想在很少的费用上面赚钱，就不得不加快时间，加快时间的最好办法就是用框架，用框架就导致了现在的现状，我的老板不一样，他常常说能自己实现，就不用别人的，不然我们的产品就别别人绑架了，出了问题我们搞不定，所以，我们不用别人的框架，少用第三方jar

这个说到点子上了

41 楼 alvin198761 2013-07-21  

别人的语言也没意思，咱自己写一个吧，来，扶清灭洋，走起

Leon.Wood 写道

zh_harry 写道

zh_harry 写道

alvin198761 写道

一群用框架的人早就了中国IT行业的技术现状，一批用windows的人，早就了中国对windows的依赖的现状，

我不用框架，不用第三方jar，java开发照样继续，看到讨论框架还争来争去，想问一句，咱能自己写个框架，然后讨论自己的好不好行不，你说的好不好，都是别人的东西，有意思吗？

已经写了呀，看我的博客，并且已经开源了http://lizhizhang.iteye.com/blog/1896545
大家拍砖
上面说得这些思想全包括了，还在升级中，希望大家关注...
也希望小编小这编文件也推荐到首页，绝对原创，没有一个jar,0框架开发，我很喜欢你所说的。
这个框架的名字我给他叫sparrow
麻省虽小，五脏俱全，其实中国就应该用自己的框架

再加一句，这么多人看过只有你提出这个问题，很棒！！

用别人的语言也没意思，咱自己写一个吧，来，扶清灭洋，走起

产生一个新的语言不是为了扶清灭洋，而是一个公司自己的业务需要，加上自己的技术积累，有这个能力了，在当前语言没法满足自己的要求下，开始做的，java也是因此产生的。国内技术能力不说低于美国，至少是低于 日本，韩国，印度，这些国家的，其主要原因不是人的问题，是制度早就的，上面层层转包，给下面一个很少的费用，老板想在很少的费用上面赚钱，就不得不加快时间，加快时间的最好办法就是用框架，用框架就导致了现在的现状，我的老板不一样，他常常说能自己实现，就不用别人的，不然我们的产品就别别人绑架了，出了问题我们搞不定，所以，我们不用别人的框架，少用第三方jar

40 楼 zh_harry 2013-07-21  

zhaomengbin 写道

struts2 的bean 也可以在spring配置为单例，性能你是怎么测出来的？

是可以，所有的都可以是单例，但我们不能那么做，单例的成员变量是共享的，是线程不安全的。servlet是单例多线程，因为他没有成员变量线程安全的。这是基础吧！

39 楼 zhaomengbin 2013-07-21  

struts2 的bean 也可以在spring配置为单例，性能你是怎么测出来的？

38 楼 zh_harry 2013-07-21  

疯子在思考系之IOC
http://lizhizhang.iteye.com/blog/1910976
疯子在思考系列会讲解sparrow框架的每一个点，各位关注

37 楼 wuchsh2013 2013-07-20  

你真是一个大牛

36 楼 zh_harry 2013-07-20  

windshome 写道

kentkwan 写道

感觉作者处于入门的级别。文中不难找出误导成分并缺乏佐证的观点。
例如：
1. 创建一个对象的时间开销其实可以忽略不算
2. spring对于bean管理的默认策略是singleton，但是也可以是prototype，并非作者所说的纯单例。
3. 反射的过程中开销最大的是获取method或者是获取field，如果进行反射的时候能把method和field进行缓存处理，反射的开销也是可以忽略不算。

我的看法：

（1）是使用单实例模式还是new，是由需求决定的，一个数据库连接池，从技术需求层面上看，是必须单实例的，能够再次被创建是违反业务约束和要求的；普通的对象，企图做成单实例，有什么价值？
（2）是使用new还是factory，差别不是多大，你要是有多态，打算把细节封装起来，就工厂模式吧
（3）缓存：大多数对象，缓存价值不大，除非第一你想避免多次查询数据库，第二数据库里的数据不会频繁变化，缓存中的和数据库里的有点差别也不大要紧；第三效率是非常关键的，这个时候可以考虑缓存
（3）现在版本的java，反射开销已经很小，即便你不会反射或者缓存反射的method和field，java里边API的东西很多也是在用反射。

这些都是对的，不错！

35 楼 windshome 2013-07-20  

kentkwan 写道

感觉作者处于入门的级别。文中不难找出误导成分并缺乏佐证的观点。
例如：
1. 创建一个对象的时间开销其实可以忽略不算
2. spring对于bean管理的默认策略是singleton，但是也可以是prototype，并非作者所说的纯单例。
3. 反射的过程中开销最大的是获取method或者是获取field，如果进行反射的时候能把method和field进行缓存处理，反射的开销也是可以忽略不算。

我的看法：

（1）是使用单实例模式还是new，是由需求决定的，一个数据库连接池，从技术需求层面上看，是必须单实例的，能够再次被创建是违反业务约束和要求的；普通的对象，企图做成单实例，有什么价值？
（2）是使用new还是factory，差别不是多大，你要是有多态，打算把细节封装起来，就工厂模式吧
（3）缓存：大多数对象，缓存价值不大，除非第一你想避免多次查询数据库，第二数据库里的数据不会频繁变化，缓存中的和数据库里的有点差别也不大要紧；第三效率是非常关键的，这个时候可以考虑缓存
（3）现在版本的java，反射开销已经很小，即便你不会反射或者缓存反射的method和field，java里边API的东西很多也是在用反射。

34 楼 zh_harry 2013-07-20  

关于框架的事情，我会抽时间一一在博客中讲解，希望喜欢学习框架设计和喜欢思考的同学一起拍砖

33 楼 zh_harry 2013-07-20  

witcheryne 写道

so ???
楼主的框架打算什么时候面世?
或者有什么实战指导型项目即将面世？

感谢您的关注
你说的这两件事都正在做
框架已经开源了。在googlecode里，博客也有介绍，但还没有demo
demo我会抽时间加，实践性项目也正在做，很快就要上线。欢迎常来！

32 楼 witcheryne 2013-07-20  

so ???
楼主的框架打算什么时候面世?
或者有什么实战指导型项目即将面世？

31 楼 zh_harry 2013-07-20  

kentkwan 写道

感觉作者处于入门的级别。文中不难找出误导成分并缺乏佐证的观点。
例如：
1. 创建一个对象的时间开销其实可以忽略不算
2. spring对于bean管理的默认策略是singleton，但是也可以是prototype，并非作者所说的纯单例。
3. 反射的过程中开销最大的是获取method或者是获取field，如果进行反射的时候能把method和field进行缓存处理，反射的开销也是可以忽略不算。

创建对象的开销与直接new会差很多的
spring有单例和非单例我想看这篇文章的人都知道，我只是举了单例的例子而已。
方法缓存可以缓存，但
invoke方法的执行仍和直接方法的执行差很多，这个可以用字节码处理，有兴趣看一下refectasm基于非常简单只有四个类。
我入了五年门了，还在入门，感谢多批评。

30 楼 kentkwan 2013-07-20  

感觉作者处于入门的级别。文中不难找出误导成分并缺乏佐证的观点。
例如：
1. 创建一个对象的时间开销其实可以忽略不算
2. spring对于bean管理的默认策略是singleton，但是也可以是prototype，并非作者所说的纯单例。
3. 反射的过程中开销最大的是获取method或者是获取field，如果进行反射的时候能把method和field进行缓存处理，反射的开销也是可以忽略不算。

29 楼 zh_harry 2013-07-20  

windshome 写道

如果开发团队，或者公司，缺乏下列这些人员或人才，只好使用这些框架，以图加快开发进程：

（1）概念的分析和设计人员

     从需求中分析中产品的核心本质，设计产品的概念体系，理顺各个概念的关系。

（2）核心架构人员

    根据概念，建立稳固的架构，清晰划分各个部分的关联关系和职责定义；能够根据这些特点，权衡利弊，采取最适合的技术选型。

（3）资深的实现者

    框架实现起来当然不容易，但是要想做出对一个产品适用的一个服务器框架、或者数据库连接池，还是没有那么困难的，而且，自己实现也是随着项目、产品的进展而不断成长完善的。

当然，即便有这样的人，使用开源框架也无可厚非---只要不依赖它们，离开他们就活不成就行。

中国很多都是拿来主意，你说的在项目中不断完善，我很赞同！

28 楼 windshome 2013-07-20  

如果开发团队，或者公司，缺乏下列这些人员或人才，只好使用这些框架，以图加快开发进程：

（1）概念的分析和设计人员

     从需求中分析中产品的核心本质，设计产品的概念体系，理顺各个概念的关系。

（2）核心架构人员

    根据概念，建立稳固的架构，清晰划分各个部分的关联关系和职责定义；能够根据这些特点，权衡利弊，采取最适合的技术选型。

（3）资深的实现者

    框架实现起来当然不容易，但是要想做出对一个产品适用的一个服务器框架、或者数据库连接池，还是没有那么困难的，而且，自己实现也是随着项目、产品的进展而不断成长完善的。

当然，即便有这样的人，使用开源框架也无可厚非---只要不依赖它们，离开他们就活不成就行。

27 楼 zhongmin2012 2013-07-20  

我觉得还是看公司文化，