1

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

  1. 如果我们在不替换任何其他框架的情况下从您的代码中删除 spring 或 puremvc，那么您最终会遇到几个 bean（在 spring 的情况下）或一些真正可重用的视图（在 puremvc 的情况下）。但是粘合bean或视图需要大量的编码工作，据我说它间接依赖于框架而不使用框架特定的api。

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

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

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

期待其他读者的观点。

4

2 回答 2

2

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

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

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

于 2010-12-09T20:34:55.423 回答
1

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

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

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

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

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

于 2010-12-13T03:28:21.667 回答