代码之家  ›  专栏  ›  技术社区  ›  Berlin Brown

一般在大型j2eeweb应用程序上,应用程序明显地按模块分开。业务委托模式的可能使用

  •  4
  • Berlin Brown  · 技术社区  · 16 年前

    在我提出“一般”问题之前,我想引用一些话来帮助我对业务代理模式的高级一般理解:

    您想从表示层组件和客户端(如设备、web服务和富客户端)访问业务层组件

    假设您拥有大型j2eeweb应用程序。当我指的是大型应用程序时,我指的是应用程序已经由许多不同的人和部门开发了几年。这个系统设计得不适合发展。现在,假设应用程序配置了一个web应用程序。

    如果应用程序更加模块化,那就太好了。但事实并非如此。一段代码或一个库可能会破坏整个系统。使用测试和其他方法来防止这种情况,但理想情况下,这只是一个单一的web应用程序。

    这是我的问题;您通常如何避免使用J2EE应用程序进行这种类型的设计,在这种情况下,应用程序会不断增长,一个单独的应用程序可能会破坏一切。


    4 回复  |  直到 10 年前
        1
  •  1
  •   razenha    16 年前

    在一个健康的软件开发环境中,应用程序“不断增长”,因为业务人员要求更改和新特性,通常没有什么问题。

    您需要做的是将您的应用程序划分为对业务人员(和用户)有意义的模块。系统的每个模块都应该有一个清晰的业务含义,反映应用程序域。

        2
  •  1
  •   Steve B.    16 年前

    所有这些想法都很好,如果你是从零开始的话,那就完全合理了。不幸的是,你不是从零开始,而是处理一个原型 Big Ball of Mud . 相信我,当我说我感觉到你的痛苦。

    比具体的模式更重要的是,对这一团糟强加某种秩序,任何秩序。比你具体的设计选择更重要的是——你能把你的设计选择合理地强加给整个系统,这样就有一个统一的范例贯穿整个应用程序吗?

    如果您的设计满足设计要求并从概念上简化了应用程序,那么它就是有效的。

        3
  •  1
  •   NamshubWriter    16 年前

    改进这样一个系统的最好方法就是慢慢地改进它。如果你的系统和我工作过的系统一样,那么修改代码常常会导致bug。自动化测试是一种减少引入新bug的方法,但通常编写代码时没有考虑到测试,更改代码以使编写测试更容易会导致bug。

    为系统编写新代码时,请在编写代码的同时尝试编写单元测试。这比为遗留代码编写测试要容易得多(因此也不那么令人沮丧),并且让您有机会了解在重构遗留代码时您可能会去哪里。

    我知道在这个问题上有两个很好的错误: Working Effectively with Legacy Code Refactoring to Patterns 作者:约书亚·克里耶夫斯基。

    Dependency Inversion Principle 以及 Interface Segregation Principle .

        4
  •  1
  •   Steven Devijver    16 年前

    当你有机会重新开始时,避免这种混乱的最好方法是:

    • 注意高内聚、低耦合:确保包之间没有循环依赖(com.myapp.packageA依赖于com.myapp.packageB,而com.myapp.packageA依赖于com.myapp.packageA)。有一些伟大的免费工具,如架构规则,可以为您自动验证。

    有了这两条规则,你将不得不遵循良好的设计原则。否则,设计需要不断的关注。任何设计工作的目的都是为了减少不确定性,所以你基本上必须知道你为什么要在第一时间进行设计。

    推荐文章