关于框架依赖的一些问题

Question

我有一些与框架依赖相关的问题。一般来说，最佳编码实践表明不要用特定于框架的代码来混淆你的命名空间。例如在 spring 的情况下，所有依赖项都应该在配置文件中维护，并且在您的应用程序代码中没有 spring 特定的代码（这是更喜欢 spring config xml 文件而不是 spring 注释的原因之一）。同样，对于 puremvc，最好不要在 mxml 中混合 puremvc 代码，因此您的视图可以与任何框架一起使用。但我的问题是

1. 如果我们删除 spring 或 puremvc 从您的代码中无需替换任何 其他框架然后你就结束了 在几个豆子中（如果是春天）或 一些真正可重用的视图（以防万一 纯MVC）。但是粘豆或 视图需要大量编码 努力，据我说是间接的 没有框架的依赖 使用特定于框架的 api。

2. 如果我们用其他 DI 替换 spring 然后像 pico 容器这样的框架 它也需要大量的 或返工。这再次导致 对框架的间接依赖。

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

据我说，只是不将应用程序命名空间与特定于框架的 api 混合并不能使您的应用程序可移植到其他框架。想想你是否想用 spring mvc 移动你现有的精心设计的 struts 应用程序，以及这样做需要付出多少努力。

期待其他读者的看法。

Answer 1

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

您说得对，在许多情况下需要为他们的工具编写代码。例如，如果您需要自定义类型，您可能会编写一些特定于休眠的代码，或者如果您需要自定义应用程序上下文，则可能会编写一些特定于 spring 的代码。没有什么不妥。关键是将其与应用程序的其他功能部分分开。

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

Answer 2

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

但这仅仅意味着知识/责任被转移了。它永远不会被重新感动。所以是的，当然你的代码隐含地依赖于那个框架。但是，如果您将框架相关的代码移动到一个位置，甚至可能引入一些接口来包装它，您有时可以使其余代码依赖于 a 接口、类或框架，而不是具体的框架。

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

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

我认为您可以简单地说：如果您使用一个框架将“需要做很多结构性管道”的问题转移到该框架中（让框架为您处理管道）并且您切换框架您将立即解决“需要做很多结构性管道”的问题。 :-)