Spring 与框架依赖相关的一些问题

我有一些关于框架依赖性的问题。一般来说，最好的编码实践是不要用特定于框架的代码来混乱您的名称空间。例如，对于spring，所有依赖项都应该在配置文件中维护，并且应用程序代码中没有spring特定的代码（这也是首选spring配置xml文件而不是spring注释的原因之一）。在puremvc的情况下，最好不要在mxml中混合使用puremvc代码，这样您的视图就可以与任何框架一起工作。但我的问题是

如果我们删除spring或puremvc 从您的代码中删除，而不替换任何 其他的框架，那么你就结束了 在少量的豆子中（在春天的情况下）或 一些真正可重用的视图（例如 puremvc的）。但是粘豆子或者 视图需要大量的编码 据我说，努力是间接的 无约束框架的依赖性 使用特定于框架的api

如果我们用其他DI替换弹簧 像pico容器这样的框架 它还需要大量的资金 或返工。这又导致了 对框架的间接依赖

那么，为什么用特定于框架的api来混乱您的应用程序名称空间是不好的呢？只是我们可以为特定于框架的api编码（如果它真的大大减轻了我们的编码工作的话）

据我所知，只是不将应用程序名称空间与特定于框架的api混合不会使您的应用程序可移植到其他框架。如果您想用SpringMVC移动您现有的设计良好的struts应用程序，您需要做多少努力

---

期待其他读者的意见。

我认为软件设计的一个基本原则是将您的关注点分开。正如您不希望在MVC的模型层中查看代码一样，您也不希望在应用程序代码中包含特定于容器的代码

您是正确的，在许多情况下，需要为他们的工具编写代码。例如，如果需要自定义类型，可以编写一些特定于hibernate的代码；如果需要自定义应用程序上下文，可以编写一些特定于spring的代码。这没什么错。关键是将它与应用程序的其他功能部分分开

---

这并不保证“即时”可移植性。它所促进的是将代码“轻松”移植到其他地方的能力。在这种情况下，“容易”并不意味着没有工作。相反，这意味着你不必因为决定搬到Pico就开始翻录Spring特有的东西。换句话说，您的核心业务功能保持不变，当您决定移动时，您所要做的就是移植配置或特定于容器的依赖项。

与软件开发中的所有抽象一样，您只是在使用框架时移动“问题”。框架负责某些事情，因此应用程序的其他部分不需要知道如何做到这一点。例如，如果您使用依赖项注入，则被注入的类不需要知道如何创建它们的依赖项，它由依赖项注入框架处理

但这只意味着知识/责任被转移了。它永远不会被移动。因此，是的，当然，您的代码隐式地依赖于该框架。但是，如果您将与框架相关的代码移动到一个位置，甚至可能引入一些接口来包装它，那么有时您可以使代码的其余部分依赖于接口、类或框架，而不是特定的框架

例如，我在代码中引入了一个IIocContainer接口，只使用解析方法。实现此接口的对象拥有如何调用特定Ioc/DI框架的知识。但这种知识只存在于这一个物体中。我的应用程序的其余部分（如果需要）只知道IIocContainer接口，因此不依赖于特定的框架。如果我改变了框架，我只需要改变引用和配置（可能是XML格式的，根本不影响代码），并使用一个不同的对象来实现这个容器的IIocContainer

当您谈论直接影响代码结构/体系结构的框架时（例如，通过基类、命名约定等），这意味着抽象出特定的框架变得更加困难。可以，但基本上你要做的是围绕另一个框架编写自己的框架。这不值得wile，因为最终如果你要切换结构框架，总是需要大量的工作，要么直接重写该框架，要么将框架抽象出来

我想你可以简单地说：如果你正在使用一个框架将“要做的大量结构管道”的问题转移到该框架中（让框架为你处理管道），然后你切换框架，你会马上得到“要做的大量结构管道”的问题。：-）