- 浏览: 199823 次
- 性别:
- 来自: 苏州
文章分类
最新评论
-
gdpglc:
2222222222222222222222222222222 ...
JAVA日期格式输出月份前面不想被自动补0 -
hesai_vip:
JPA SPRING 泛型DAO -
gdpglc:
public static String getTime_ ...
JAVA日期格式输出月份前面不想被自动补0 -
junzilan0929cn:
学习了.
EJB 3 初次学习小结 -
xiaowur:
写的很详细...
对我很有帮助
EJB 3 初次学习小结
首先,我不是应届生。我目前就读于苏州的一个大学。大三年级。专业为软件工程。
论坛里最近发了很多关于应届生的问题,比如:SSH?DWR?什么简历写的太水等等,这种全盘否定的帖子,我到要出来说说话。
1,关于SSH,SSH2,等等的问题。
请问,一些在位牛人(经常批评学生的),你们工作中难道不是使用的这种框架?你们也许用过许多框架,但是你们常用的请问是不是这几种?也许你会抱怨,公司的要求,部门的决定,但是归根到底你在使用这些框架,那么别人学这些框架不是很正常吗?(会的人多,技术成熟,学习曲线低,项目成本低)你们为什么要说三倒四呢?一提到SSH的问题,我想现在许多牛人已经想说一些攻击我的话了吧?您先听我说完。JSP,SERVLET,JDBC,是的,它们很好,而且它们是规范,是标准(SPRING您喜欢吗?它是标准吗?)。JDBC的速度快,什么JSP,SERVLET一样可以搭建出可不断升级的软件。对,这些没错,很对。但是请问,您在工作有有多少实际项目用到这些东西?全部使用了吗?
谈到这,许多人说在读学生只知道SSH,那么可以,我来谈谈我的SSH。(我不多提代码,免得被大牛们说,我是代码工人)
在项目中,我一般使用的分层结构:
Dao(Hibernate/Ibatis)--- service (Spring) -- action (Struts2/Webwork) 。我不会使用JSP/SERVLET技术去实现我的展现层。在论坛上许多人提出这种分层的问题(首先我先抛开贫血模型/充血模型的问题),许多人建议把action 层与service 合并的。包括在SPRINGSIDE中,我看见SPRINGSIDE中封装了泛型DAO层,之后直接在service 中继承Dao。并非直接使用Dao继承action 。当然,直接抛开service 层有它的好处,但是我认为坏处远远大于好处。首先一个辣手的问题就是耦合的问题。
比如,这里一个USER Action的usersByPage方法:
这个方法还好,但是很明显,这种做法很幼稚。Action到最后极度膨胀。下面是各幼稚的。
这里的Action直接调用Dao.当然,这里的DAO传入的数据完全符合ACTION的需求,而且由于让SPRING去IOC了,所以这个usersByPage看起来也并非很幼稚,问题是,ACTION过度膨胀,导致这些ACTION很难重构,重构的目的在于程序清晰可见,更容易做测试,但是过于膨胀的类是很难重构的,这里不是技术问题,而是人的问题,你看见一大堆东西,你看上去就不舒服,心就烦,而且这些东西搬来搬去,如果最后还是放在同一个ACTION里,还是很不爽的一件事情。而且,这里很明显,这2个方法都不OO。或者说,上面的那个ACTION虽然调用了Services,但是ACTION还是膨胀,根本没有解决实际问题,Services只是起个空架子。类似于做了这种事情:
但是,加个空架子,也许有它的好处吧。首先,把事务处理放在Services中也未必是坏事。而且,哪一天,ACTION里实在过度膨胀,把一些方法放在Services中操作,也能减轻点ACTION的负担,而且,也方便于重构,更重要的是,如果方法独立,单独的放在Services中也方便于TDD。更重要的是,STRUTS2属于展现层框架,把业务逻辑放在展现层中实在有点违背展现层这个名词,所以,我不建议把ACTION当做 ACTION+Services来用。当然,如果完全的CURD,为了速度,小项目,这样做也是不错的选择,可以提高开发速度,而且,小项目也没什么维护。把一堆东西放在ACTION里,也并非完全不可取。但是,如果你 的系统从设计的开始就使用的OO,那么很明显,这种ACTION+Services的分层,我觉得会很不适合。
以上谈到的是TS的开发模式。关于对模型充血,按MF说的,按《DDD》的那一套,我感觉都不怎么合适,原因我想大家都知道。SPRING+HIBERNATE的问题,这里论坛的讨论很多,我就不多说了。自己有兴趣可 以看看讨论。我的做法是把Service在分开,把一些通用的模块尽量做成组件,之后在每个Service里调,比较爽,有点OO的感觉。这里许多人应该会想到AOP,我认为AOP适合于那些“过度”调用的功能,而不 适合非平凡调用。我认为,AOP本身就比较复杂,如果为了AOP就去AOP显然提高学习成本和项目难度。我认为,使用最简单,最大众化的技术去解决实际的问题才是最好的选择。所以,我晚上会翻阅JSP,SERVLET,JDBC的书籍或者资料,但是我从不会在实际中去使用它们去搭建系统。当然,上面那个是我最“正式”的分层结构,我还使用了别的变形,这里就不多说了,我的目的很简单,我只想告诉一些激进的牛人,我们学生并非只知道你们所认为的SSH。我也说了一些我为什么要去使用SSH的问题。
关于EJB3.0的问题.
我在读书的时候,EJB2.0那会我应该还在初中或者高中,我根本没有时间接触,所以对它们不太了解。但是EJB3.0,我这里有本《EJB3.0 IN ACTION》的书,偶尔翻阅,做做DEMO,也算了解,SPRING几乎都可以做,所以我没怎么去下太大的工夫,让我不爽的就是它的部署。不过由于它回归POJO,而且数据持久层使用了HIBERNATE,所以还是比较爽的,不会在像(资料了解):写那么多无聊的配置,DTO,接口寻址,等这些问题。
关于DWR,等问题。
我用DWR的机会不多,只用过2次。所以也没什么特别的心得。
应用服务器的问题:
我最爱TOMCAT,可以集群,性能不差,简单方便,没有别的理由让我不用它。
SPRING,EJB的问题:
我喜欢SPRING,没别的想说了,如果问我理由,太多。特别喜欢WITHOUT EJB那本书。当然了,还有SPRING IN ACTION。
框架这东西也没什么好谈的了,我用的就是这些平常的,能给我做足够的事情,就OK了。我更大众化。或者,我太菜,就像某些人说的:学生,只会吹。就会SSH。没了。
本来一开始打算写更多的东西,想想还是算了,也没那个必要。要写的太多,管理,设计,需求模型,包括产品的问题。技术与市场的问题。不写了,我想我写那么多就够了,学生并非你所想的一无是处,而且,有些东西我感觉我写不出来,写1年吧,也许可以,但是,有些东西,只有自己体会了才知道。好了,就此搁笔。PS:让暴风雨来的更猛烈些吧,请牛人们尽情的拍砖吧。
最后,我们是学生,不容易,学校不教,我们只能自己摸索,老师在干什么?我们能会一点已经很不错了,您的批评,有想过我们吗?我们也是人,我们是菜鸟,您是牛人,您可以给我们建议,学什么,怎么学,但是请不要在无聊的批判了,您没上过学吗?我要学的东西还有很多,有许多东西并不是技术上的.我每天都在学习,每天进步一点,学生,不是你所想的,只会上网玩游戏,泡MM,无聊等等。如果你因为我帖子发错了地方而投了隐藏帖,那么我无话可说!
我更喜欢用SPRING这种框架去处理interceptor。如果用展现层框架去处理interceptor,总感觉心里有点不太塌实。
只为了action来搞一搞也是可以的么。。。
不过spring这个东西,说实话,很难用。。。嗯。。。指用户友好方面的。。。
我现在比较倾向于Guice
SPRING还好吧。。。还是比较容易上手的。
休息了。晚安。
我更喜欢用SPRING这种框架去处理interceptor。如果用展现层框架去处理interceptor,总感觉心里有点不太塌实。
只为了action来搞一搞也是可以的么。。。
不过spring这个东西,说实话,很难用。。。嗯。。。指用户友好方面的。。。
我现在比较倾向于Guice
不会吧?这么惨。。。。
惨惨惨。。。。
其实有很多东西还是aop一下很好的。。。
比如
我可以
@user_login_required(level=User.Admin)
def delete_account_view(req):
#......
而不用
def delete_account_view(req):
if 'logined_user' in req.session:
if req.session['logined_user'].is_admin:
#....
return Http404()
但是struts2里面有个interceptor,这个就方便了很多。。。主要aop看上去麻烦是spring惹的祸。。。
对了,说到struts2的interceptor,我还真郁闷了,比如:权限的问题,本身权限验证我认为是业务层里要干的事情,可是interceptor到是提供了这个功能,我真是很难选择啊。呵呵。
为什么认为interceptor不是业务层
于是我还是觉得django/pylons感觉好一些。。。
或者说,是语法上的aop支持比较对胃口。。。
我更喜欢用SPRING这种框架去处理interceptor。如果用展现层框架去处理interceptor,总感觉心里有点不太塌实。
DomainModel的持久化就那么十恶不赦 以至于大家都敬而远之 宁可肯紫肯紫的生成一陀只有get/set的贫血怪胎 我不可理解
请先去统计金融/银行/电信业务中使用hibernate/spring的比例,再减去ejb的比例 看看剩下多少用原始的jdbc,jsp
其实我已经开始讨厌java了,虽然说重剑无锋,但是至少对毕业生来说,要大巧不工 暂时还没看到,连可能看到趋势都没
的确,金融/银行/电信业务这些行业软件用原始的jdbc,jsp确实很多,需求的要求,非需求的需求。这3个行业不在本文章的讨论范围之内。说到JAVA,我还是很喜欢它。
其实有很多东西还是aop一下很好的。。。
比如
我可以
@user_login_required(level=User.Admin)
def delete_account_view(req):
#......
而不用
def delete_account_view(req):
if 'logined_user' in req.session:
if req.session['logined_user'].is_admin:
#....
return Http404()
但是struts2里面有个interceptor,这个就方便了很多。。。主要aop看上去麻烦是spring惹的祸。。。
对了,说到struts2的interceptor,我还真郁闷了,比如:权限的问题,本身权限验证我认为是业务层里要干的事情,可是interceptor到是提供了这个功能,我真是很难选择啊。呵呵。
为什么认为interceptor不是业务层
于是我还是觉得django/pylons感觉好一些。。。
或者说,是语法上的aop支持比较对胃口。。。
其实有很多东西还是aop一下很好的。。。
比如
我可以
@user_login_required(level=User.Admin)
def delete_account_view(req):
#......
而不用
def delete_account_view(req):
if 'logined_user' in req.session:
if req.session['logined_user'].is_admin:
#....
return Http404()
但是struts2里面有个interceptor,这个就方便了很多。。。主要aop看上去麻烦是spring惹的祸。。。
对了,说到struts2的interceptor,我还真郁闷了,比如:权限的问题,本身权限验证我认为是业务层里要干的事情,可是interceptor到是提供了这个功能,我真是很难选择啊。呵呵。
你是天津的?
其实有很多东西还是aop一下很好的。。。
比如
我可以
@user_login_required(level=User.Admin)
def delete_account_view(req):
#......
而不用
def delete_account_view(req):
if 'logined_user' in req.session:
if req.session['logined_user'].is_admin:
#....
return Http404()
但是struts2里面有个interceptor,这个就方便了很多。。。主要aop看上去麻烦是spring惹的祸。。。
只要自己感觉过的好,就行了。幸福感是自己感觉出来了。我想这个道理,大家应该都知道。我算做了回喇叭,呵呵。
遇到高手了,呵呵。
你的第一个问题是没有理解我的意思。也许是我表达上的问题吧。我用泛型Dao的目的也是为了避免Dao膨胀。第2个问题,这个比较辣手,各有优缺点,很难说,如果说真的难重构吗?其实不然,所以我说了,是人的问题,而不是技术问题。第3个,我总觉得不太适合,或者太过理想化。第4个,我说一些不是经常重复的东西,不必AOP,用简单的引用既可解决问题,我更注重实用性关注复杂度。第5个,我不想多说。
不知道aop 也可以说自己知道spring吗?
python的decorator爱好者表示不知道spring的aop。。。更不会动不动就在java里aop。。。。
哦 原来动态语言也要aop 嗯嗯 以后向您请教了
....我也不清楚什么是aop。。。我只知道python的那个decorator能在方法调用前,调用后干一些事情。。。
然后方法自己还不会察觉。。。
不过我第一次听说aop是听一个lisper讲lisp的OOP时候提到的。。。lisp内建了aop支持。。。。
不知道aop 也可以说自己知道spring吗?
python的decorator爱好者表示不知道spring的aop。。。更不会动不动就在java里aop。。。。
主要是你没头像。。 没头像呀没头像。。
我觉得向我这种不是计算机本专业的。 底层是要差些。 慢慢补。
...我底层也是一塌糊涂。。。。
谢谢您经常关注我,你的头像不错。
JAVA我只能算熟练,许多东西还掌握的不行。
关于书籍,都是自己买,一般实在太无聊了,怎么办?座车去买书,呵呵,之后看看。翻着翻着太累就睡着了。我就2个博客,一个XIAONEI,一个JE。 关于看书的秘诀,还真没有。就是感觉不看就不舒服,大概已经把看计算机书籍养成了习惯了吧。
都记住我了。 喔呵呵。 经常露脸就是有好处。
最近在恶补一些组成原理跟编译原理的书。
《深入理解计算机系统》这本书很不错。 正在肯。
ym啊。。。
我在这里露了快一年的脸了,也没人记住我。。。@_@
话说机组很不爽的。。。感觉就是背啊。。。
理解性的东西超级简单。。。细节性的东西根本记不住。。。。T_T
主要是你没头像。。 没头像呀没头像。。
我觉得向我这种不是计算机本专业的。 底层是要差些。 慢慢补。
一起努力吧,我也很菜。 用心点,就可以了。
谢谢您经常关注我,你的头像不错。
JAVA我只能算熟练,许多东西还掌握的不行。
关于书籍,都是自己买,一般实在太无聊了,怎么办?座车去买书,呵呵,之后看看。翻着翻着太累就睡着了。我就2个博客,一个XIAONEI,一个JE。 关于看书的秘诀,还真没有。就是感觉不看就不舒服,大概已经把看计算机书籍养成了习惯了吧。
都记住我了。 喔呵呵。 经常露脸就是有好处。
最近在恶补一些组成原理跟编译原理的书。
《深入理解计算机系统》这本书很不错。 正在肯。
ym啊。。。
我在这里露了快一年的脸了,也没人记住我。。。@_@
话说机组很不爽的。。。感觉就是背啊。。。
理解性的东西超级简单。。。细节性的东西根本记不住。。。。T_T
谢谢您经常关注我,你的头像不错。
JAVA我只能算熟练,许多东西还掌握的不行。
关于书籍,都是自己买,一般实在太无聊了,怎么办?座车去买书,呵呵,之后看看。翻着翻着太累就睡着了。我就2个博客,一个XIAONEI,一个JE。 关于看书的秘诀,还真没有。就是感觉不看就不舒服,大概已经把看计算机书籍养成了习惯了吧。
都记住我了。 喔呵呵。 经常露脸就是有好处。
最近在恶补一些组成原理跟编译原理的书。
《深入理解计算机系统》这本书很不错。 正在肯。
呵呵,最近一直在看关于JAVA EE设计方面的书籍。
论坛里最近发了很多关于应届生的问题,比如:SSH?DWR?什么简历写的太水等等,这种全盘否定的帖子,我到要出来说说话。
1,关于SSH,SSH2,等等的问题。
请问,一些在位牛人(经常批评学生的),你们工作中难道不是使用的这种框架?你们也许用过许多框架,但是你们常用的请问是不是这几种?也许你会抱怨,公司的要求,部门的决定,但是归根到底你在使用这些框架,那么别人学这些框架不是很正常吗?(会的人多,技术成熟,学习曲线低,项目成本低)你们为什么要说三倒四呢?一提到SSH的问题,我想现在许多牛人已经想说一些攻击我的话了吧?您先听我说完。JSP,SERVLET,JDBC,是的,它们很好,而且它们是规范,是标准(SPRING您喜欢吗?它是标准吗?)。JDBC的速度快,什么JSP,SERVLET一样可以搭建出可不断升级的软件。对,这些没错,很对。但是请问,您在工作有有多少实际项目用到这些东西?全部使用了吗?
谈到这,许多人说在读学生只知道SSH,那么可以,我来谈谈我的SSH。(我不多提代码,免得被大牛们说,我是代码工人)
在项目中,我一般使用的分层结构:
Dao(Hibernate/Ibatis)--- service (Spring) -- action (Struts2/Webwork) 。我不会使用JSP/SERVLET技术去实现我的展现层。在论坛上许多人提出这种分层的问题(首先我先抛开贫血模型/充血模型的问题),许多人建议把action 层与service 合并的。包括在SPRINGSIDE中,我看见SPRINGSIDE中封装了泛型DAO层,之后直接在service 中继承Dao。并非直接使用Dao继承action 。当然,直接抛开service 层有它的好处,但是我认为坏处远远大于好处。首先一个辣手的问题就是耦合的问题。
比如,这里一个USER Action的usersByPage方法:
public String usersByPage() throws Exception{ // 从Session中得到当前登录用户的loginName。这里的Session loginName从登陆时记录。 loginName=(String)(ActionContext.getContext().getSession().get("loginName")); //判断用户是否加入了球队 if(userServices.findUserByLoginName(loginName).getTeam()==null){ return ERROR; } Integer teamId=userServices.findUserByLoginName(loginName).getTeam().getId(); users=userServices.getAll(); ...... return SUCCESS; }
这个方法还好,但是很明显,这种做法很幼稚。Action到最后极度膨胀。下面是各幼稚的。
public String usersByPage() throws Exception{ // 从Session中得到当前登录用户的loginName。这里的Session loginName从登陆时记录。 loginName=(String)(ActionContext.getContext().getSession().get("loginName")); //判断用户是否加入了球队 if(Dao.findUserByLoginName(loginName).getTeam()==null){ return ERROR; } Integer teamId=userDao.findUserByLoginName(loginName).getTeam().getId(); users=userDao.getAll(); ...... return SUCCESS; }
这里的Action直接调用Dao.当然,这里的DAO传入的数据完全符合ACTION的需求,而且由于让SPRING去IOC了,所以这个usersByPage看起来也并非很幼稚,问题是,ACTION过度膨胀,导致这些ACTION很难重构,重构的目的在于程序清晰可见,更容易做测试,但是过于膨胀的类是很难重构的,这里不是技术问题,而是人的问题,你看见一大堆东西,你看上去就不舒服,心就烦,而且这些东西搬来搬去,如果最后还是放在同一个ACTION里,还是很不爽的一件事情。而且,这里很明显,这2个方法都不OO。或者说,上面的那个ACTION虽然调用了Services,但是ACTION还是膨胀,根本没有解决实际问题,Services只是起个空架子。类似于做了这种事情:
public List getAll() throws RuntimeException { return userDao.getAll(); }
但是,加个空架子,也许有它的好处吧。首先,把事务处理放在Services中也未必是坏事。而且,哪一天,ACTION里实在过度膨胀,把一些方法放在Services中操作,也能减轻点ACTION的负担,而且,也方便于重构,更重要的是,如果方法独立,单独的放在Services中也方便于TDD。更重要的是,STRUTS2属于展现层框架,把业务逻辑放在展现层中实在有点违背展现层这个名词,所以,我不建议把ACTION当做 ACTION+Services来用。当然,如果完全的CURD,为了速度,小项目,这样做也是不错的选择,可以提高开发速度,而且,小项目也没什么维护。把一堆东西放在ACTION里,也并非完全不可取。但是,如果你 的系统从设计的开始就使用的OO,那么很明显,这种ACTION+Services的分层,我觉得会很不适合。
以上谈到的是TS的开发模式。关于对模型充血,按MF说的,按《DDD》的那一套,我感觉都不怎么合适,原因我想大家都知道。SPRING+HIBERNATE的问题,这里论坛的讨论很多,我就不多说了。自己有兴趣可 以看看讨论。我的做法是把Service在分开,把一些通用的模块尽量做成组件,之后在每个Service里调,比较爽,有点OO的感觉。这里许多人应该会想到AOP,我认为AOP适合于那些“过度”调用的功能,而不 适合非平凡调用。我认为,AOP本身就比较复杂,如果为了AOP就去AOP显然提高学习成本和项目难度。我认为,使用最简单,最大众化的技术去解决实际的问题才是最好的选择。所以,我晚上会翻阅JSP,SERVLET,JDBC的书籍或者资料,但是我从不会在实际中去使用它们去搭建系统。当然,上面那个是我最“正式”的分层结构,我还使用了别的变形,这里就不多说了,我的目的很简单,我只想告诉一些激进的牛人,我们学生并非只知道你们所认为的SSH。我也说了一些我为什么要去使用SSH的问题。
关于EJB3.0的问题.
我在读书的时候,EJB2.0那会我应该还在初中或者高中,我根本没有时间接触,所以对它们不太了解。但是EJB3.0,我这里有本《EJB3.0 IN ACTION》的书,偶尔翻阅,做做DEMO,也算了解,SPRING几乎都可以做,所以我没怎么去下太大的工夫,让我不爽的就是它的部署。不过由于它回归POJO,而且数据持久层使用了HIBERNATE,所以还是比较爽的,不会在像(资料了解):写那么多无聊的配置,DTO,接口寻址,等这些问题。
关于DWR,等问题。
我用DWR的机会不多,只用过2次。所以也没什么特别的心得。
应用服务器的问题:
我最爱TOMCAT,可以集群,性能不差,简单方便,没有别的理由让我不用它。
SPRING,EJB的问题:
我喜欢SPRING,没别的想说了,如果问我理由,太多。特别喜欢WITHOUT EJB那本书。当然了,还有SPRING IN ACTION。
框架这东西也没什么好谈的了,我用的就是这些平常的,能给我做足够的事情,就OK了。我更大众化。或者,我太菜,就像某些人说的:学生,只会吹。就会SSH。没了。
本来一开始打算写更多的东西,想想还是算了,也没那个必要。要写的太多,管理,设计,需求模型,包括产品的问题。技术与市场的问题。不写了,我想我写那么多就够了,学生并非你所想的一无是处,而且,有些东西我感觉我写不出来,写1年吧,也许可以,但是,有些东西,只有自己体会了才知道。好了,就此搁笔。PS:让暴风雨来的更猛烈些吧,请牛人们尽情的拍砖吧。
最后,我们是学生,不容易,学校不教,我们只能自己摸索,老师在干什么?我们能会一点已经很不错了,您的批评,有想过我们吗?我们也是人,我们是菜鸟,您是牛人,您可以给我们建议,学什么,怎么学,但是请不要在无聊的批判了,您没上过学吗?我要学的东西还有很多,有许多东西并不是技术上的.我每天都在学习,每天进步一点,学生,不是你所想的,只会上网玩游戏,泡MM,无聊等等。如果你因为我帖子发错了地方而投了隐藏帖,那么我无话可说!
评论
35 楼
treblesoftware
2009-06-19
mikeandmore 写道
treblesoftware 写道
我更喜欢用SPRING这种框架去处理interceptor。如果用展现层框架去处理interceptor,总感觉心里有点不太塌实。
只为了action来搞一搞也是可以的么。。。
不过spring这个东西,说实话,很难用。。。嗯。。。指用户友好方面的。。。
我现在比较倾向于Guice
SPRING还好吧。。。还是比较容易上手的。
休息了。晚安。
34 楼
mikeandmore
2009-06-19
treblesoftware 写道
我更喜欢用SPRING这种框架去处理interceptor。如果用展现层框架去处理interceptor,总感觉心里有点不太塌实。
只为了action来搞一搞也是可以的么。。。
不过spring这个东西,说实话,很难用。。。嗯。。。指用户友好方面的。。。
我现在比较倾向于Guice
33 楼
treblesoftware
2009-06-19
whaosoft 写道
好么 成了 吵架贴了不值当的
不过我们公司就有人很抵触框架 什么人都有 不用着急 你说内lz
只要人品可以 态度可以就得了 为什么好多人都攻击呢
其实也不是攻击 想必都有点遭遇 我们公司以前就有什么都不会的 黑嘴的(应届生)
~ 人品还极差 现在还一个呢 本来有一个好同志的 不过现在也被辞了
留下的傻货我天天看见他都想踢死他 哎~
不过我们公司就有人很抵触框架 什么人都有 不用着急 你说内lz
只要人品可以 态度可以就得了 为什么好多人都攻击呢
其实也不是攻击 想必都有点遭遇 我们公司以前就有什么都不会的 黑嘴的(应届生)
~ 人品还极差 现在还一个呢 本来有一个好同志的 不过现在也被辞了
留下的傻货我天天看见他都想踢死他 哎~
不会吧?这么惨。。。。
惨惨惨。。。。
32 楼
treblesoftware
2009-06-19
mikeandmore 写道
treblesoftware 写道
mikeandmore 写道
treblesoftware 写道
第4个,我说一些不是经常重复的东西,不必AOP,用简单的引用既可解决问题,我更注重实用性关注复杂度。
其实有很多东西还是aop一下很好的。。。
比如
我可以
@user_login_required(level=User.Admin)
def delete_account_view(req):
#......
而不用
def delete_account_view(req):
if 'logined_user' in req.session:
if req.session['logined_user'].is_admin:
#....
return Http404()
但是struts2里面有个interceptor,这个就方便了很多。。。主要aop看上去麻烦是spring惹的祸。。。
对了,说到struts2的interceptor,我还真郁闷了,比如:权限的问题,本身权限验证我认为是业务层里要干的事情,可是interceptor到是提供了这个功能,我真是很难选择啊。呵呵。
为什么认为interceptor不是业务层
于是我还是觉得django/pylons感觉好一些。。。
或者说,是语法上的aop支持比较对胃口。。。
我更喜欢用SPRING这种框架去处理interceptor。如果用展现层框架去处理interceptor,总感觉心里有点不太塌实。
31 楼
treblesoftware
2009-06-19
treblesoftware 写道
火星叔叔马丁 写道
免扯淡 直接正题
DomainModel的持久化就那么十恶不赦 以至于大家都敬而远之 宁可肯紫肯紫的生成一陀只有get/set的贫血怪胎 我不可理解
请先去统计金融/银行/电信业务中使用hibernate/spring的比例,再减去ejb的比例 看看剩下多少用原始的jdbc,jsp
其实我已经开始讨厌java了,虽然说重剑无锋,但是至少对毕业生来说,要大巧不工 暂时还没看到,连可能看到趋势都没
的确,金融/银行/电信业务这些行业软件用原始的jdbc,jsp确实很多,需求的要求,非需求的需求。这3个行业不在本文章的讨论范围之内。说到JAVA,我还是很喜欢它。
30 楼
mikeandmore
2009-06-19
treblesoftware 写道
mikeandmore 写道
treblesoftware 写道
第4个,我说一些不是经常重复的东西,不必AOP,用简单的引用既可解决问题,我更注重实用性关注复杂度。
其实有很多东西还是aop一下很好的。。。
比如
我可以
@user_login_required(level=User.Admin)
def delete_account_view(req):
#......
而不用
def delete_account_view(req):
if 'logined_user' in req.session:
if req.session['logined_user'].is_admin:
#....
return Http404()
但是struts2里面有个interceptor,这个就方便了很多。。。主要aop看上去麻烦是spring惹的祸。。。
对了,说到struts2的interceptor,我还真郁闷了,比如:权限的问题,本身权限验证我认为是业务层里要干的事情,可是interceptor到是提供了这个功能,我真是很难选择啊。呵呵。
为什么认为interceptor不是业务层
于是我还是觉得django/pylons感觉好一些。。。
或者说,是语法上的aop支持比较对胃口。。。
29 楼
treblesoftware
2009-06-19
mikeandmore 写道
treblesoftware 写道
第4个,我说一些不是经常重复的东西,不必AOP,用简单的引用既可解决问题,我更注重实用性关注复杂度。
其实有很多东西还是aop一下很好的。。。
比如
我可以
@user_login_required(level=User.Admin)
def delete_account_view(req):
#......
而不用
def delete_account_view(req):
if 'logined_user' in req.session:
if req.session['logined_user'].is_admin:
#....
return Http404()
但是struts2里面有个interceptor,这个就方便了很多。。。主要aop看上去麻烦是spring惹的祸。。。
对了,说到struts2的interceptor,我还真郁闷了,比如:权限的问题,本身权限验证我认为是业务层里要干的事情,可是interceptor到是提供了这个功能,我真是很难选择啊。呵呵。
28 楼
mikeandmore
2009-06-19
whaosoft 写道
好么 成了 吵架贴了不值当的
不过我们公司就有人很抵触框架 什么人都有 不用着急 你说内lz
只要人品可以 态度可以就得了 为什么好多人都攻击呢
其实也不是攻击 想必都有点遭遇 我们公司以前就有什么都不会的 黑嘴的(应届生)
~ 人品还极差 现在还一个呢 本来有一个好同志的 不过现在也被辞了
留下的傻货我天天看见他都想踢死他 哎~
不过我们公司就有人很抵触框架 什么人都有 不用着急 你说内lz
只要人品可以 态度可以就得了 为什么好多人都攻击呢
其实也不是攻击 想必都有点遭遇 我们公司以前就有什么都不会的 黑嘴的(应届生)
~ 人品还极差 现在还一个呢 本来有一个好同志的 不过现在也被辞了
留下的傻货我天天看见他都想踢死他 哎~
你是天津的?
27 楼
mikeandmore
2009-06-19
treblesoftware 写道
第4个,我说一些不是经常重复的东西,不必AOP,用简单的引用既可解决问题,我更注重实用性关注复杂度。
其实有很多东西还是aop一下很好的。。。
比如
我可以
@user_login_required(level=User.Admin)
def delete_account_view(req):
#......
而不用
def delete_account_view(req):
if 'logined_user' in req.session:
if req.session['logined_user'].is_admin:
#....
return Http404()
但是struts2里面有个interceptor,这个就方便了很多。。。主要aop看上去麻烦是spring惹的祸。。。
26 楼
whaosoft
2009-06-19
好么 成了 吵架贴了不值当的
不过我们公司就有人很抵触框架 什么人都有 不用着急 你说内lz
只要人品可以 态度可以就得了 为什么好多人都攻击呢
其实也不是攻击 想必都有点遭遇 我们公司以前就有什么都不会的 黑嘴的(应届生)
~ 人品还极差 现在还一个呢 本来有一个好同志的 不过现在也被辞了
留下的傻货我天天看见他都想踢死他 哎~
不过我们公司就有人很抵触框架 什么人都有 不用着急 你说内lz
只要人品可以 态度可以就得了 为什么好多人都攻击呢
其实也不是攻击 想必都有点遭遇 我们公司以前就有什么都不会的 黑嘴的(应届生)
~ 人品还极差 现在还一个呢 本来有一个好同志的 不过现在也被辞了
留下的傻货我天天看见他都想踢死他 哎~
25 楼
treblesoftware
2009-06-19
Terence.Gao 写道
白天看看报纸 , 中午打打游戏,睡睡觉 , 晚上再打打游戏 , 和小女朋友扯扯~逛逛街~看看笑电影 , 一不小心4年过去了~~哈哈
只要自己感觉过的好,就行了。幸福感是自己感觉出来了。我想这个道理,大家应该都知道。我算做了回喇叭,呵呵。
24 楼
treblesoftware
2009-06-19
火星叔叔马丁 写道
免扯淡 直接正题
请先理解泛型Dao,泛型Dao的出现是避免了Dao膨胀 而不是action/service合并
dispatchaction 而不是责怪你的service
我不知道,请解释
不知道aop 也可以说自己知道spring吗?
哦 那是你 而且还好只是你
ssh挺好 不好怎么会成为java主流 只是若像祥林嫂一样,见面就是"我的阿毛",结果恐怕连最有佛心的老太都不会掉出一滴眼泪
引用
许多人建议把action 层与service 合并的。包括在SPRINGSIDE中,我看见SPRINGSIDE中封装了泛型DAO层,之后直接在service 中继承Dao。并非直接使用Dao继承action 。
请先理解泛型Dao,泛型Dao的出现是避免了Dao膨胀 而不是action/service合并
引用
问题是,ACTION过度膨胀,导致这些ACTION很难重构
dispatchaction 而不是责怪你的service
引用
关于对模型充血,按MF说的,按《DDD》的那一套,我感觉都不怎么合适,原因我想大家都知道。
我不知道,请解释
引用
这里许多人应该会想到AOP,我认为AOP适合于那些“过度”调用的功能,而不 适合非平凡调用。我认为,AOP本身就比较复杂,
不知道aop 也可以说自己知道spring吗?
引用
我晚上会翻阅JSP,SERVLET,JDBC的书籍或者资料,但是我从不会在实际中去使用它们去搭建系统。
哦 那是你 而且还好只是你
ssh挺好 不好怎么会成为java主流 只是若像祥林嫂一样,见面就是"我的阿毛",结果恐怕连最有佛心的老太都不会掉出一滴眼泪
遇到高手了,呵呵。
你的第一个问题是没有理解我的意思。也许是我表达上的问题吧。我用泛型Dao的目的也是为了避免Dao膨胀。第2个问题,这个比较辣手,各有优缺点,很难说,如果说真的难重构吗?其实不然,所以我说了,是人的问题,而不是技术问题。第3个,我总觉得不太适合,或者太过理想化。第4个,我说一些不是经常重复的东西,不必AOP,用简单的引用既可解决问题,我更注重实用性关注复杂度。第5个,我不想多说。
23 楼
mikeandmore
2009-06-19
火星叔叔马丁 写道
mikeandmore 写道
火星叔叔马丁 写道
不知道aop 也可以说自己知道spring吗?
python的decorator爱好者表示不知道spring的aop。。。更不会动不动就在java里aop。。。。
哦 原来动态语言也要aop 嗯嗯 以后向您请教了
....我也不清楚什么是aop。。。我只知道python的那个decorator能在方法调用前,调用后干一些事情。。。
然后方法自己还不会察觉。。。
不过我第一次听说aop是听一个lisper讲lisp的OOP时候提到的。。。lisp内建了aop支持。。。。
22 楼
mikeandmore
2009-06-19
火星叔叔马丁 写道
不知道aop 也可以说自己知道spring吗?
python的decorator爱好者表示不知道spring的aop。。。更不会动不动就在java里aop。。。。
21 楼
Terence.Gao
2009-06-19
白天看看报纸 , 中午打打游戏,睡睡觉 , 晚上再打打游戏 , 和小女朋友扯扯~逛逛街~看看笑电影 , 一不小心4年过去了~~哈哈
20 楼
mikeandmore
2009-06-19
Saito 写道
主要是你没头像。。 没头像呀没头像。。
我觉得向我这种不是计算机本专业的。 底层是要差些。 慢慢补。
...我底层也是一塌糊涂。。。。
19 楼
Saito
2009-06-19
mikeandmore 写道
Saito 写道
treblesoftware 写道
Saito 写道
SSH谁都没有说不好。 只是停留在培训学校或者教学视频的程度的话。 。。 这种人你跟他聊两句就知道他的水平。
所以广泛面试大牛们在接收到太多精通SSH的简历之后,聊过太多人之后。 渐渐对精通SSH形成了一种恐惧。 因为就一个Hibernate也得你不少时间吧。 你一应届生就敢说自己精通SSH 。 那么既然你精通SSH 。 那必然精通Java。 来讲讲 classloder 。 讲讲 mem收集算法。 讲讲bytecode。 在这个层面上就废掉了。就别提SSH了。
大家批的是简历要谦虚。 并不是说应届生一无是处。向楼主这种大牛也是广泛存在的。我始终认为。 一个人要是能长期浸淫在JE这种社区的氛围中。 那他一定不会差。(除过上来晒简历那种。。)据我长期观察。 能上JE的学生在学校里面不说拔尖。也都是上层。但是不排除有些人就自视清高。就敢把简历写的天花乱坠。学生里面敢写精通Java这种人。是该受到鄙视的。
最后求证一下。楼主的一百多本书是怎么看下来的。 我才20本左右。 最好让我follow 一下楼主的豆瓣。 or twitter 。 看看你最近再看哪些书。
所以广泛面试大牛们在接收到太多精通SSH的简历之后,聊过太多人之后。 渐渐对精通SSH形成了一种恐惧。 因为就一个Hibernate也得你不少时间吧。 你一应届生就敢说自己精通SSH 。 那么既然你精通SSH 。 那必然精通Java。 来讲讲 classloder 。 讲讲 mem收集算法。 讲讲bytecode。 在这个层面上就废掉了。就别提SSH了。
大家批的是简历要谦虚。 并不是说应届生一无是处。向楼主这种大牛也是广泛存在的。我始终认为。 一个人要是能长期浸淫在JE这种社区的氛围中。 那他一定不会差。(除过上来晒简历那种。。)据我长期观察。 能上JE的学生在学校里面不说拔尖。也都是上层。但是不排除有些人就自视清高。就敢把简历写的天花乱坠。学生里面敢写精通Java这种人。是该受到鄙视的。
最后求证一下。楼主的一百多本书是怎么看下来的。 我才20本左右。 最好让我follow 一下楼主的豆瓣。 or twitter 。 看看你最近再看哪些书。
谢谢您经常关注我,你的头像不错。
JAVA我只能算熟练,许多东西还掌握的不行。
关于书籍,都是自己买,一般实在太无聊了,怎么办?座车去买书,呵呵,之后看看。翻着翻着太累就睡着了。我就2个博客,一个XIAONEI,一个JE。 关于看书的秘诀,还真没有。就是感觉不看就不舒服,大概已经把看计算机书籍养成了习惯了吧。
都记住我了。 喔呵呵。 经常露脸就是有好处。
最近在恶补一些组成原理跟编译原理的书。
《深入理解计算机系统》这本书很不错。 正在肯。
ym啊。。。
我在这里露了快一年的脸了,也没人记住我。。。@_@
话说机组很不爽的。。。感觉就是背啊。。。
理解性的东西超级简单。。。细节性的东西根本记不住。。。。T_T
主要是你没头像。。 没头像呀没头像。。
我觉得向我这种不是计算机本专业的。 底层是要差些。 慢慢补。
18 楼
treblesoftware
2009-06-19
xjlnjut730 写道
好牛呀,看看我学的什么...哎,自叹不如,不过还有两年才出来,还有机会努力一把。其实我觉得应届生受点质疑也无不可~还是要历炼历炼的~~至少看了你的文章,让我知道了自己还是一个小小小小的菜鸟~~
一起努力吧,我也很菜。 用心点,就可以了。
17 楼
mikeandmore
2009-06-19
Saito 写道
treblesoftware 写道
Saito 写道
SSH谁都没有说不好。 只是停留在培训学校或者教学视频的程度的话。 。。 这种人你跟他聊两句就知道他的水平。
所以广泛面试大牛们在接收到太多精通SSH的简历之后,聊过太多人之后。 渐渐对精通SSH形成了一种恐惧。 因为就一个Hibernate也得你不少时间吧。 你一应届生就敢说自己精通SSH 。 那么既然你精通SSH 。 那必然精通Java。 来讲讲 classloder 。 讲讲 mem收集算法。 讲讲bytecode。 在这个层面上就废掉了。就别提SSH了。
大家批的是简历要谦虚。 并不是说应届生一无是处。向楼主这种大牛也是广泛存在的。我始终认为。 一个人要是能长期浸淫在JE这种社区的氛围中。 那他一定不会差。(除过上来晒简历那种。。)据我长期观察。 能上JE的学生在学校里面不说拔尖。也都是上层。但是不排除有些人就自视清高。就敢把简历写的天花乱坠。学生里面敢写精通Java这种人。是该受到鄙视的。
最后求证一下。楼主的一百多本书是怎么看下来的。 我才20本左右。 最好让我follow 一下楼主的豆瓣。 or twitter 。 看看你最近再看哪些书。
所以广泛面试大牛们在接收到太多精通SSH的简历之后,聊过太多人之后。 渐渐对精通SSH形成了一种恐惧。 因为就一个Hibernate也得你不少时间吧。 你一应届生就敢说自己精通SSH 。 那么既然你精通SSH 。 那必然精通Java。 来讲讲 classloder 。 讲讲 mem收集算法。 讲讲bytecode。 在这个层面上就废掉了。就别提SSH了。
大家批的是简历要谦虚。 并不是说应届生一无是处。向楼主这种大牛也是广泛存在的。我始终认为。 一个人要是能长期浸淫在JE这种社区的氛围中。 那他一定不会差。(除过上来晒简历那种。。)据我长期观察。 能上JE的学生在学校里面不说拔尖。也都是上层。但是不排除有些人就自视清高。就敢把简历写的天花乱坠。学生里面敢写精通Java这种人。是该受到鄙视的。
最后求证一下。楼主的一百多本书是怎么看下来的。 我才20本左右。 最好让我follow 一下楼主的豆瓣。 or twitter 。 看看你最近再看哪些书。
谢谢您经常关注我,你的头像不错。
JAVA我只能算熟练,许多东西还掌握的不行。
关于书籍,都是自己买,一般实在太无聊了,怎么办?座车去买书,呵呵,之后看看。翻着翻着太累就睡着了。我就2个博客,一个XIAONEI,一个JE。 关于看书的秘诀,还真没有。就是感觉不看就不舒服,大概已经把看计算机书籍养成了习惯了吧。
都记住我了。 喔呵呵。 经常露脸就是有好处。
最近在恶补一些组成原理跟编译原理的书。
《深入理解计算机系统》这本书很不错。 正在肯。
ym啊。。。
我在这里露了快一年的脸了,也没人记住我。。。@_@
话说机组很不爽的。。。感觉就是背啊。。。
理解性的东西超级简单。。。细节性的东西根本记不住。。。。T_T
16 楼
treblesoftware
2009-06-19
Saito 写道
treblesoftware 写道
Saito 写道
SSH谁都没有说不好。 只是停留在培训学校或者教学视频的程度的话。 。。 这种人你跟他聊两句就知道他的水平。
所以广泛面试大牛们在接收到太多精通SSH的简历之后,聊过太多人之后。 渐渐对精通SSH形成了一种恐惧。 因为就一个Hibernate也得你不少时间吧。 你一应届生就敢说自己精通SSH 。 那么既然你精通SSH 。 那必然精通Java。 来讲讲 classloder 。 讲讲 mem收集算法。 讲讲bytecode。 在这个层面上就废掉了。就别提SSH了。
大家批的是简历要谦虚。 并不是说应届生一无是处。向楼主这种大牛也是广泛存在的。我始终认为。 一个人要是能长期浸淫在JE这种社区的氛围中。 那他一定不会差。(除过上来晒简历那种。。)据我长期观察。 能上JE的学生在学校里面不说拔尖。也都是上层。但是不排除有些人就自视清高。就敢把简历写的天花乱坠。学生里面敢写精通Java这种人。是该受到鄙视的。
最后求证一下。楼主的一百多本书是怎么看下来的。 我才20本左右。 最好让我follow 一下楼主的豆瓣。 or twitter 。 看看你最近再看哪些书。
所以广泛面试大牛们在接收到太多精通SSH的简历之后,聊过太多人之后。 渐渐对精通SSH形成了一种恐惧。 因为就一个Hibernate也得你不少时间吧。 你一应届生就敢说自己精通SSH 。 那么既然你精通SSH 。 那必然精通Java。 来讲讲 classloder 。 讲讲 mem收集算法。 讲讲bytecode。 在这个层面上就废掉了。就别提SSH了。
大家批的是简历要谦虚。 并不是说应届生一无是处。向楼主这种大牛也是广泛存在的。我始终认为。 一个人要是能长期浸淫在JE这种社区的氛围中。 那他一定不会差。(除过上来晒简历那种。。)据我长期观察。 能上JE的学生在学校里面不说拔尖。也都是上层。但是不排除有些人就自视清高。就敢把简历写的天花乱坠。学生里面敢写精通Java这种人。是该受到鄙视的。
最后求证一下。楼主的一百多本书是怎么看下来的。 我才20本左右。 最好让我follow 一下楼主的豆瓣。 or twitter 。 看看你最近再看哪些书。
谢谢您经常关注我,你的头像不错。
JAVA我只能算熟练,许多东西还掌握的不行。
关于书籍,都是自己买,一般实在太无聊了,怎么办?座车去买书,呵呵,之后看看。翻着翻着太累就睡着了。我就2个博客,一个XIAONEI,一个JE。 关于看书的秘诀,还真没有。就是感觉不看就不舒服,大概已经把看计算机书籍养成了习惯了吧。
都记住我了。 喔呵呵。 经常露脸就是有好处。
最近在恶补一些组成原理跟编译原理的书。
《深入理解计算机系统》这本书很不错。 正在肯。
呵呵,最近一直在看关于JAVA EE设计方面的书籍。
相关推荐
对于“介绍一下你自己”这类问题,应届生应该提前准备好一个清晰、有条理的自我介绍,既要涵盖个人基本信息、教育背景,也要突出自己的优势、特长和对所申请职位的热情。 在回答“为什么选择这个专业”时,应届生...
其内容涵盖了职业规划、简历制作、笔试面试、企业招聘日程、招聘陷阱、签约违约、户口问题、公务员等求职过程中的每一个环节,得到了广大应届生朋友、老师、企业、媒体等社会各界的广泛关注和支持。 为了使《应届生...
本文档提供了一个Java应届生简历模板,针对Java开发岗位的应届生提供了一个基本的模板架构,可以帮助他们快速编写自己的简历。该模板包括基本信息、教育背景、工作经历、语言能力、职业技能、项目经验等多个方面的...
Java软件工程师是IT行业中一个非常重要的职位,尤其对于应届毕业生来说,找到一份合适的简历模板至关重要。这份名为"java软件工程师简历模板——应届生.rar"的压缩包文件,旨在为即将踏入职场的Java编程新手提供一份...
《应届生求职大礼包2010-2》是一个专为应届毕业生设计的求职资源集合,其中包含了针对AMD公司和LG公司的求职指南。这个压缩包文件提供了对应届生在求职过程中可能需要的重要信息和知识,帮助他们更好地理解和准备这...
目前来说,市场卜还没有一个比较全面、系统、针对应届生群体的求职指导书 籍。我们参考过不少同类的书籍,然而感觉到这类书籍要么仅仅提供“怎么做”,缺 少对于“为什么这样做”的分析;对于某些简历制作、笔试面试...
在IT行业中,对于应届生来说,找到一份满意的工作至关重要,尤其是一些知名的大公司,如中兴和华为。这两个公司在全球范围内都有着显著的影响力,它们的招聘过程往往具有较高的专业性和严谨性。本篇文章将深入探讨这...
本资源"高质量C++C编程指南"显然是一个面向应届生的备考资料,旨在帮助他们提升编程能力和通过笔试。下面将对C和C++编程的重要知识点进行详述: 1. **基本语法**:C和C++的基础包括变量、数据类型、运算符、控制...
总体来说,2021应届生就业趋势报告为了解当前高校毕业生的就业形势提供了一个全面的视角,并对未来的人才市场趋势给出了一定的预测和建议。通过报告中的数据和分析,能够更好地理解高校毕业生的就业动态,为高校教育...
根据上述文件内容,我们可以从《2021年应届生求职就业与薪酬调研报告》中提炼出一系列详细的知识点。以下为报告中涉及的知识点: 1. 报告发起单位及目的: 报告由中智管理咨询有限公司与中智预才网校园招聘平台联合...
应届生求职简历模版,希望能给广大的应届生朋友们最大的帮助!
8. **强烈的责任心和专业热情**:护理应届生表示自己热爱护理事业,愿意为病人付出,有强烈的责任心,能够认真对待每一个护理任务。 9. **党员身份和党课培训**:对于一些应届生来说,他们的党员身份和高级党课培训...
应届生简历模板
应届生培养项目.pdf
《应届生求职全程指南》是一份专门为即将踏入职场的应届毕业生量身打造的实用资料。这份指南旨在帮助应届毕业生了解求职过程中的各个环节,提供全方位的求职策略和技巧,以提高求职成功率。以下是对这份指南内容的...
在IT行业中,简历是求职者向潜在雇主展示自身技能、经验及成就的重要工具,尤其对于应届生来说,一份精心设计的简历可以帮助他们在竞争激烈的就业市场中脱颖而出。本压缩包文件名为“应届生简历模板zip文件”,包含...
Java 应届生面试题知识点总结 一、Java 基本数据类型和引用数据类型 * 基本数据类型:byte、int、char、long、float、double、boolean 和 short,具有固定的数据位,不随运行平台的变化而变化。 * 引用数据类型:...
综上所述,"JAVA简历模板.doc"是一个很好的起点,它能帮助应届生构建一份专业的Java程序员简历,有效展示自身能力,提高求职成功率。通过合理填充和个性化定制,这份模板将为你开启理想的Java职业生涯铺平道路。
《2023年应届生招聘和薪酬管理及实习生调研报告》揭示了今年应届毕业生在就业市场上的态势,以及企业在招聘、薪酬管理和实习生管理方面的最新动态。以下是对报告核心内容的详细解读。 1. 应届生招聘趋势: - 2023...