论坛首页 Java企业应用论坛

如何更高效的在层与层之间调用

浏览 14758 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2008-12-02   最后修改:2008-12-02
在不了解一家公司需求背景和规模的前提下,在不了解AO/BO所充当的真正角色的前提下,妄下结论,说是过渡设计。这是不负责任的。
在了解业务规模以及了解AO/BO/DAO的真正含义之后,我不觉得这是过渡设计的问题。

现在最大的问题是,
1)新人不了解AO/BO充当的角色,内部培训没有做好,反倒要在外网上讨论这个问题。这是不应该的--当然,我们对AO/BO也确实没有一个明确的定义;
2)对于AO的管理,也有待明确;
3)web层调用AO的方式,有待改进,太麻烦了--当然不是说command模式不好--它确实灵活,可以使web层和service层分离部署。
0 请登录后投票
   发表时间:2008-12-02  
这还用说,Spring的依赖注入就是最好的。使用Annotation注入更好。
0 请登录后投票
   发表时间:2008-12-02  
----------一个架构而已, 老子改不就行了, 天天思考这个问题, 我快疯了。 用现在的眼光看5-6年前的设计是否足够优秀是不妥当的。
0 请登录后投票
   发表时间:2008-12-02  
呵呵,偶一眼就看出来是淘宝的兄弟了,哈哈。看到那分层结构就猜到一二了,再看到WEBX。。。,那不用说了,100%是,呵呵
0 请登录后投票
   发表时间:2008-12-02  
spyker 写道

fnet 写道这还用说,Spring的依赖注入就是最好的。使用Annotation注入更好。


我不喜欢annotation注入
还是觉得xml配置set注入好点

annotation虽然使用方便,但是维护起来并不是很舒服。问题有点像该帖。既然能在一个配置文件内看到所有和维护所有的依赖关系是我最习惯的。
0 请登录后投票
   发表时间:2008-12-02  
我觉得抛开框架不说,JavaEE一直充斥着 command模式
表示层来说,请求的url就是命令而对应的就是解释器action
数据访问,sql就是命令,数据库就是解释器
我们分层,我们不把sql直接写在jsp上,不把业务逻辑都封装在pl-sql中,
我觉得就是因为解释器是脆弱的,随着业务的改变而变动的,但使用命令的角色无法预知。正如楼主提出的,你修改了AO这个业务解释器但无法知道他都解释了action里的
哪些命令。

btw ,taobao这种解决问题的氛围是非常好的!
0 请登录后投票
   发表时间:2008-12-02  
这个框架出来的时候  好像spring还没有怎么兴起
在国内也不怎么出名
所以没有采用spring的
0 请登录后投票
   发表时间:2008-12-02  
只有足够复杂了,才需要command模式,如果目前有其他很简单的方法就能解决的,没必要用啊。
0 请登录后投票
   发表时间:2008-12-02  
这个Command其实不是Command:不是Command模式中,因为本身无非只是一个map而已。
AO的问题我理解成初期打算做成web层连接一个集群的app层,类似史前时代的ejb1,2....但没想后来web和app整体做了一个集群,这个本来看起来很美丽的东西就变成了鸡肋
8 请登录后投票
   发表时间:2008-12-02  
eyeieye 写道
这个Command其实不是Command:不是Command模式中,因为本身无非只是一个map而已。
AO的问题我理解成初期打算做成web层连接一个集群的app层,类似史前时代的ejb1,2....但没想后来web和app整体做了一个集群,这个本来看起来很美丽的东西就变成了鸡肋

没有明白,请详细的说一下。
0 请登录后投票
论坛首页 Java企业应用版

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