春季错失示例

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

既然这个团队对企业的东西感到厌倦，他们听说过IoC和Spring（“看起来很酷，你呢？”），他们认为在这个应用中使用它是个好主意。因此，我有大约170个通过Spring配置的对象（几乎每个应用都可以看到）。每个简单的对象都通过标签连接。当然，一切都是单身，所以添加诸如多文件处理之类的功能几乎是不可能的。

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

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

所以有可能需要文件标签（配置两个compoennts）。但这意味着两个书签窗口（这没有任何意义 - 在VS中，每个文件都有一个）。

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

来源

2009-06-23 Michal Sznajder

一些代码示例，为什么你不可能实现多个文件处理，将是伟大的。 – IAdapter 2009-06-23 09:29:28

根据你的描述（正如其他人所说），不可能判断最终设计是好还是坏。

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格式可能是用户喜欢的东西，比底层语言的“原始”编程更容易学习。

来源

2009-06-23 06:47:07

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

我不能真正猜到实现“多文件支持”的最佳方式，您的问题在没有看到代码的情况下谈论 - 但它肯定不应该太难。有多种方式可以处理它，或者为适当的组件注入一个工厂，或者让应用程序让Spring在需要时创建组件。（后者对Spring的依赖关系更具侵入性，但可能意味着更少的锅炉代码。）

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

来源

2009-06-23 06:23:09

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

另外在春天，singleton concept与设计模式singleton不同。我会说使用IoC适用于中等或大尺寸的每种应用。也许开发人员对Spring并不是非常有经验，也没有使用一些更高级的技术，这些技术真的可以减少代码的大小并产生更优雅的结果。

来源

2009-06-23 06:28:54 kgiannakakis

-3

在此，我对春天的经历，我会倾向于去一个架构，只有你知道豆类单身应该是春季管理。其他豆类应该由那些春豆中的代码管理。嗨，手动。

这样，弹簧的功能与应用程序的功能有很大的分离。使用spring会变得非常棘手，如果您将它用于上下文中的非单例对象，那么这很有用，正如您现在所遇到的那样。

我确实承认这不适用于任何情况，但听起来它可能适用于您的情况。

来源

2009-06-23 15:50:11

春天是有帮助不妨碍或限制你，但是清理所有的锅炉板代码，没有人愿意看到或写入以及测试/ DB支持等等等等

这是真的，那从技术上来说，可能会换出一个持久性实现，但实际上这很少发生，并且无论你认为它们多么不可知，它都会对你的接口产生影响。

使用Spring的一个更好的理由是我已经提到过;测试...

我不关注你的评论关于一切都是单身，如果这种情况确实是你的架构师做出的决定，因为你可以在Spring中拥有非单例或原型，并且被鼓励去做所以需要避免看起来程序化或脚本化的贫血域模型和类。

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

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

来源

2009-06-26 13:01:27 JamesC

春季错失示例

回答

相关问题