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

      遇到一个新的框架，分为Action，AO，BO，DAO，Service这几层。Action层基于CoC。AO，BO，DAO又使用的是Spring管理的。Action与AO间使用的名称调用，如：

private String AOName = "cpsMyAuctionAO";

。。。。。

Result result = executeCommand(AOName, "createCpsMyAuction", param);

cpsMyAuctionAO就是action要调用的AO，param是入参，createCpsMyAuction是需要调用的方法。

result就是执行的结果了。

看了底层的代码，是通过一个CommandDispatcherSelector来读取上下文，并通过参数调用AO。但是对于调用的管理难度加大了，当类多起来的，查找之间的关系很困难。请问各位高手有什么更好的解决办法？

评论

16 楼 gloomyd 2008-12-02  

这个框架出来的时候  好像spring还没有怎么兴起
在国内也不怎么出名
所以没有采用spring的

15 楼 bnulz 2008-12-02  

我觉得抛开框架不说，JavaEE一直充斥着 command模式
表示层来说，请求的url就是命令而对应的就是解释器action
数据访问，sql就是命令，数据库就是解释器
我们分层，我们不把sql直接写在jsp上，不把业务逻辑都封装在pl-sql中，
我觉得就是因为解释器是脆弱的，随着业务的改变而变动的，但使用命令的角色无法预知。正如楼主提出的，你修改了AO这个业务解释器但无法知道他都解释了action里的
哪些命令。

btw ,taobao这种解决问题的氛围是非常好的！

14 楼 sagah 2008-12-02  

spyker 写道

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


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

annotation虽然使用方便，但是维护起来并不是很舒服。问题有点像该帖。既然能在一个配置文件内看到所有和维护所有的依赖关系是我最习惯的。

13 楼 lovingprince 2008-12-02  

呵呵，偶一眼就看出来是淘宝的兄弟了，哈哈。看到那分层结构就猜到一二了，再看到WEBX。。。，那不用说了，100%是，呵呵

12 楼 sdh5724 2008-12-02  

－－－－－－－－－－一个架构而已， 老子改不就行了， 天天思考这个问题， 我快疯了。 用现在的眼光看5－6年前的设计是否足够优秀是不妥当的。

11 楼 fnet 2008-12-02  

这还用说，Spring的依赖注入就是最好的。使用Annotation注入更好。

10 楼 stone2083 2008-12-02  

在不了解一家公司需求背景和规模的前提下，在不了解AO／BO所充当的真正角色的前提下，妄下结论，说是过渡设计。这是不负责任的。
在了解业务规模以及了解AO／BO／DAO的真正含义之后，我不觉得这是过渡设计的问题。

现在最大的问题是，
1）新人不了解AO／BO充当的角色，内部培训没有做好，反倒要在外网上讨论这个问题。这是不应该的－－当然，我们对AO／BO也确实没有一个明确的定义；
2）对于AO的管理，也有待明确；
3）web层调用AO的方式，有待改进，太麻烦了－－当然不是说command模式不好－－它确实灵活，可以使web层和service层分离部署。

9 楼 yunsong 2008-12-02  

这个框架作的项目，如果项目有大量的维护工作，而且人员不是很稳定的话，维护人员会比价累

8 楼 icewubin 2008-12-02  

sagah 写道

    我觉得并不是什么过度设计，框架已经实现了CoC。实际使用效果也不错，能较方便的快速开发，只是代码累积到今天，对维护带来了不便。因为现在还没有很好的CoC的解决框架。考虑该框架是在n年前的作品，有问题是正常的。我们还是着眼于如何解决该问题。
    我重新说一下问题，如果我修改了cpsMyAuctionAO，我无法能很快知道有哪些action使用了cpsMyAuctionAO。

简直就是为了CoC而CoC，既然Java不够动态语言那么简洁，适当使用一些通用配置没什么不好的，有时候在追求最后1%的完美的时候，付出的各方面的代价都很大的。

7 楼 sdh5724 2008-12-02  

AO(业务对象)的管理是个问题.WEBX能在多年前做出来的东西,主要关注的是WEB框架,并没有考虑到业务框架, 这个是我们最大的失败. WEBX做出来开始, 是超越当时很多框架对WEB的处理能力, 最根本的原因是当初框架的实践是来自一线开发的意见, webx的代码质量非常可靠, . 这么多年过去了, 落伍了在所难免, 很多局限, 不熟悉的人很难架设新的应用, 陷井也不少.

6 楼 sagah 2008-12-01  

    我觉得并不是什么过度设计，框架已经实现了CoC。实际使用效果也不错，能较方便的快速开发，只是代码累积到今天，对维护带来了不便。因为现在还没有很好的CoC的解决框架。考虑该框架是在n年前的作品，有问题是正常的。我们还是着眼于如何解决该问题。
    我重新说一下问题，如果我修改了cpsMyAuctionAO，我无法能很快知道有哪些action使用了cpsMyAuctionAO。

5 楼 daquan198163 2008-12-01  

见过过度设计，没见过这么过度的，或者该叫过分设计，哈哈哈

4 楼 sagah 2008-12-01  

sdh5724 写道

内部讨论这个问题吧, 实际上, 如果你在B2B, 这是我造成的问题. 惭愧.
我们在明年开始解决着个COMMAND设计模式造成的问题.

好几年了，这个问题是该框架一直无法解决的问题。虽然有许多的问题，但是这个框架仍然值得称道。作者宝宝果然是大牛。我也期待你们能尽早解决这个问题。同时也希望网上的各位大侠提出宝贵的意见。

3 楼 sdh5724 2008-12-01  

内部讨论这个问题吧, 实际上, 如果你在B2B, 这是我造成的问题. 惭愧.
我们在明年开始解决着个COMMAND设计模式造成的问题.

2 楼 sagah 2008-12-01  

是web框架，问题在于action调service。因为除action都是在spring的上下文可以管理。但是action是基于0配置的。没有办法直接引入上下文。所以原有的设计者才使CommandDispatcher建立起action和下层的桥梁。但是CommandDispatcher是使用名称调用的。这个才是问题所在。

1 楼 sagah 2008-12-01  

AO是业务逻辑组装，BO负责单一的业务逻辑，AO+BO相当月ssh中的service层。都是在spring框架内管理的。