你如何应对春豆增加的额外复杂性？

2019年8月4日 144次阅读

我现在正在编写软件很多年,并且总是试图创建富有表现力,清晰可读,可维护,健壮的代码.最近我加入了一个使用
Spring托管对象开发Web应用程序的团队.但我对这项技术感到非常不舒服.对我而言,感觉就像所有封装和信息隐藏原则,数十年软件工程的成就,都被抛弃了.我清楚地看到了使用Inversion of Control容器的优点,用于将系统依赖性从程序代码中移出到配置文件中.但是现在,我看到Spring的使用方式,我觉得,只是增加了一堆不必要的复杂性而没有产生任何好处.

使用Spring创建webapp支持bean,对象不再在模块中清晰地组织,并且不再具有尽可能小的可见性.相反,现在有一个全局的bean名称空间.因此,对象倾向于得到像’pendingOrderCustomerName’这样糟糕的名称,更糟糕的是,这些名称甚至不能清楚地标识定义明确的实体,因为bean定义可以来自各种定义源,从公开指定的位置收集： Spring bean不是简单地定义为包中的类,而是由xml文件组装而成,具有自由覆盖的可能性和松散定义的关系.

例如,当我在普通java中有一个类型“Account”时,在包“my.webstore”中,我通常可以在一个地方知道该类型的属性,关系和能力,“my / webstore / Account. java“文件. “帐户”实例作为使用帐户的对象中的引用存在,任何实例的状态都由类精确定义.然而,使用Spring bean,事情变得更加复杂：“帐户”的实例现在存在于全局名称下,在容器管理的范围内,具有从xml文件组装的状态,基于命名模式在文件搜索路径中找到…

在了解对象的作用及其行为方式的过程中,您只需阅读其程序源.今天,您需要对象的java源代码(可能很难理解),而且您必须找到可能会更改该对象的任何配置文件,这并不容易,因为您必须找到配置可能来自的所有方式你必须找出他们互相覆盖的顺序

也许这只是一个品味问题,但我也想知道为什么人们更喜欢冗长,笨拙的xml语法,如：

  <bean id="p1" class="Point" scope="prototype">
    <property name="x">
      <value>20</value>
    </property>
    <property name="y">
      <value>80</value>
    </property>
  </bean>

对此：

  p1 = new Point(20,80);

这个例子可能看起来有点夸张,但我告诉你我看到的更糟！

我不打算单独批评Spring框架,它在很多情况下非常强大并且是一个很好的组成部分.我关心的是如何防止滥用,如何保持可维护性,如何保证质量和稳定性,如何找到依赖关系,如何记录代码……您的经历是什么？

最佳答案 如您所见,如果您不能正确理解面向对象设计的原则,那么很容易滥用Spring. Spring IoC容器(让我们暂时忘记其余部分,因为在Spring保护伞下有一个庞大的库组合)当你使用它时真的很棒：

>定义组件模型(例如控制器,服务,存储库及其依赖项)
>集中组件依赖项查找(例如,替换服务定位器,JNDI查找或其他无状态组件检索策略)
>用技术方面装饰组件(例如事务管理,缓存,访问控制等)

Spring或任何IoC容器将允许您拥有统一的组件模型,删除大量样板代码,并将横切关注点集中到集中方面.它还应该促使您实现由松散耦合的组件构成的系统,该系统侧重于实现业务逻辑,从长远来看,这将提高可读性,可测试性和可维护性.

当然,如果你开始将Accounts和Points定义为Spring组件,你将不会获得任何东西(并且实际上会损失很多).这些仍应设计为实体或值对象.它们应该仍然是正确包装的一部分,并且应该应用适当的可见性修改器.如果您的应用程序没有利用IoC容器,它们仍应使用您将使用的策略进行实例化,操作和管理.

看起来你已经知道了合理的设计原则,所以我鼓励你相信你的直觉.如果一个类是一个可重用(通常是无状态的)组件,那么将它声明为一个Spring组件并将其注入适当的位置.如果您不确定,请将其保留为正常的非托管类并正常使用.您将会看到声明组件的位置以及不组件的位置.

我还鼓励您研究如何利用@Component和< context：component-scan>声明以减少XML占用空间.

祝好运.

点赞