Question

我们的软件商店拥有一个大型企业系统，其中一个部分是复杂的监控和日志查看器工具。最近我们的一篇文章重写了它，因为以前的版本确实缺乏一些基本功能。这真的很难看。

由于这个团队厌倦了企业家，他们听说过IoC和Spring（“好像很酷，是吗？”），他们认为在这个应用程序中使用它是个好主意。因此，我通过Spring配置了大约170个对象（几乎每个在应用程序中都可以看到）。每个简单的对象都通过标签连接。当然一切都是单身，所以添加像多文件处理这样的功能几乎是不可能的。

我可以假设以这种方式使用Spring是非常“有争议的”吗？我认为IoC和Spring适合其他需求（比如更改数据库驱动程序或其他动态配置）。

编辑：这个应用程序的GUI有点类似于Visual Studio GUI。所以我有日志文件的选项卡（这是一个Spring组件）。我有书签标签（一个Spring组件）。所以一个：想象一下，对于Visual Studio中的每个选项卡，您都有一个Spring组件。并且每个组件都具有仅能够与其他单个组件连接的接口。

因此可以使用文件标签（配置两个组件）。但这意味着两个书签窗口（没有任何意义 - 在VS中，每个文件都有一个）。

@Earwicker：这个项目中几乎每个类都是通过Spring配置的（文件加载器，文件索引器，书签选项卡，文件选项卡，着色器选项卡）

Answer 1

根据您的描述（正如其他人所说），无法判断最终设计是好还是坏。

IOC的最终极端如下所示：每个有用的API都包含在组件类中。该API的参数由其他组件提供。例如，如果应用程序可能需要读取文件，那么您将拥有一个组件（伪代码）：

public class ReadFile : IStreamFactory
{
    IFilePath _path;

    public ReadFile(IFilePath path)
    {
        _path = path;
    }

    // implementing IStreamFactory
    Stream Get()
    {
        return new FileStream(_path.GetPathString());
    }
}

现在，要使该对象能够在文件上打开流，您需要编写另一个实现IFilePath的组件。您可以编写几个：一个存储常量文件路径的组件（当然是从配置中读取！），一个组合了两个文件路径的组件，一个从另一个组件获取纯文本的组件（实现另一个新接口，ITextSource？）并且只是检查这是一条有效的道路。

无论如何，你明白了。这几乎就像你采用普通应用程序的每一行并将该单行作为一个单独的组件。另一个例子：

class IfThenElse : IAction
{
    IBoolean _test;
    IAction _ifTrue;
    IAction _ifFalse;

    // omitting obvious constructor

    // implementing IAction
    void Do()
    {
        if (_test.GetBool())
            _ifTrue.Do();
        else
            _ifFalse.Do();
    }
}

您将需要表示“可以声明变量的范围”的其他组件，以及“命名变量声明”和“变量引用”，它们必须能够以某种方式处理任何类型的组件。

所以现在你需要将所有这些微小的片段组合在一个巨大的XML配置文件中，将它们全部组合成一个应用程序。

如果你真的在尽可能低的水平上做到这一点，那将是非常荒谬的，因为编写XML文件的任务将与以通常方式编写应用程序相媲美。除了语法是基于XML的，所有函数的名称都是完全非标准的，调试支持会很糟糕。

如果你能在这之上找到一个“最佳位置”，那么你的XML格式可能是用户更喜欢的东西，并且比基础语言中的“原始”编程更容易学习。

This is very similar to a point I made the other day about XAML.

Answer 2

当你说“一切都是单身”时，你的意思是在Spring中配置它是怎么回事？我不希望类型本身（在代码中）是单例 - 事实上，能够用IoC配置事物的一部分是避免使用真正的单例（例如，使测试变得更难）。

我无法真正猜出实现“多文件支持”的最佳方式，你的问题在没有看到代码的情况下进行讨论 - 但它当然不应该太难。有多种方法可以处理它，或者为适当的组件注入工厂，或者让应用程序让Spring在需要时创建组件。（后者在对Spring的依赖性方面更具侵入性，但可能意味着更少的样板代码。）

在没有看到代码的情况下判断代码非常困难，但是通过使用Spring配置的大量松耦合组件创建复杂的应用程序对我来说听起来并不是太糟糕。

Answer 3

动态配置（比如更改数据库驱动程序或用模拟替换图层进行测试）只是Spring和IoC的众多优点之一。也许主要优势是完全分离关注点。所有对象彼此独立，执行特定任务，容器负责将它们连接在一起。

同样在Spring中，singleton concept与设计模式singleton有所不同。我想说使用IoC适用于中型或大型的每个应用。也许开发人员对Spring不是很有经验，并且没有使用一些更高级的技术，这些技术真正减少了代码大小并产生了更优雅的结果。

Answer 4

Spring有助于不妨碍或限制你，但是要清理所有锅炉板代码，没有人想看或写，以及测试/ db支持等等。

例如，在技术上可以换掉持久性实现，但事实上这很少发生，无论你认为它们是多么不可知，它都会对你的界面产生影响。

使用Spring的一个更好的理由就像我已经提到的那样;测试...

我没有关注你关于一切都是单身的评论，如果这种情况肯定是你的建筑师决定的，因为你可以在春天有非单身人士或原型，并鼓励他们在需要避免的情况下这样做贫困领域的模型和类看起来是程序性的或脚本化的。

在Spring中使用原型对象肯定不难。

请记住，在所有有光泽的外观和IoC下，Spring只是一个工厂。

Answer 5

根据我在春天的经历，我倾向于选择仅豆类的架构，你知道这些豆子应该是春季管理的。其他bean应该由那些spring bean中的代码管理。哇，手动。

这样，弹簧与应用程序的作用之间存在着强烈的分离。使用spring变得棘手，如果你将它用于上下文中的非单例对象，就像你现在所经历的一样，这是有利的。

我确实承认这并不适用于所有情况，但听起来它可以适用于你的。

春天滥用的例子

5 个答案: