与框架依赖有关的一些问题

Question

我有一些与框架依赖有关的问题。一般来说，最佳编码实践认为，不要使用特定于框架的代码来混淆名称空间。对于例如在Spring的情况下，所有的依赖项都应该保存在配置文件中，并且在应用程序代码中没有特定于Spring的代码（并且这是在Spring注释中偏好spring config xml文件的原因之一）。在puremvc的情况下，它总是最好不要在mxml中混合使用puremvc代码，所以您的视图可以与任何框架一起使用。但我的问题是

1. 如果我们从代码中移除弹簧或PureMVC的 无需更换任何 其他的框架，那么你最终在几豆 （春季的情况下）或 一些真正的可重复使用的意见（以puremvc的情况 ）。但是粘合豆或 视图需要大量的编码 努力，根据我的间接 框架依赖关系没有 使用框架特定的API。

2. 如果我们更换弹簧，像微微容器等DI 0​​框架然后 还它需要大量的 或返工。这又导致 对框架的间接依赖。

那么，为什么它不好使我们的应用程序名称空间与框架特定的api混乱？只要我们可以编写特定于框架的api（如果它真的可以大大减轻我们的编码工作）。

据我说，只是不应用混合应用程序名称空间与框架特定的api不会使您的应用程序可移植为其他框架。想想如果你想用spring mvc移动你现有的精心设计的struts应用程序，以及它需要做多少努力。

期待其他读者的看法。

Answer 1

与软件开发中的所有抽象一样，当你使用框架时，你只是简单地移动'问题'。框架负责处理某些事情，因此应用程序的其他部分不需要知道如何执行该操作。例如。如果使用依赖注入，那么注入的类不需要知道如何创建它们的依赖关系，而是由依赖注入框架处理。

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

E.g.我在我的代码中介绍了一个IIocContainer接口，只有解决方法。实现此接口的对象拥有的知识如何来调用特定的Ioc/DI框架。但是这个知识只是在这一个对象中。我的应用程序的其余部分（在需要的地方）只知道接口的IP地址，因此不依赖于特定的框架。如果我改变了框架，我只需要改变引用和配置（可能是XML而不影响代码），并使用一个不同的对象来实现此容器的IIocContainer。当你谈论直接影响你的代码结构/架构（例如，通过基类，命名约定等）的框架时，这意味着抽象出特定的框架变得更加困难。你可能，但你基本上正在做的是围绕另一个框架编写你自己的框架。这不值得一提，因为最终如果你要切换结构框架，它总是总是会很多工作，要么直接重写该框架，要么将框架抽象出来。我认为你可以把它简单地理解为：如果你正在使用一个框架来将“很多结构化管道工作”的问题转移到该框架中（让框架为你处理管道），并且你切换框架，你会得到'很多结构性管道'问题。 :-)

Answer 2

我认为它是一个软件设计的基本原理，以保持您的关注点分离。就像你不想在MVC的模型层中查看代码一样，你不需要在你的应用程序代码中使用容器特定的代码。

你是对的，在很多情况下需要为他们的工具编写代码。例如，如果您需要自定义类型，或者需要定制应用程序上下文，则可以编写一些特定于Spring的代码。没有什么不妥。关键是要将它与应用程序的其他功能片分开。

这并不保证“即时”便携性。它所促进的是能够“轻松”地将代码移植到别处。在这种情况下“轻松”并不意味着没有工作。相反，这意味着你不必开始删除特定于Spring的东西，因为你已经决定迁移到Pico。换句话说，您的核心业务功能保持不变，您只需在决定移动时移植配置或容器特定的依赖关系。