java - 是否有一种可接受的方法来保持这些层/依赖关系分离？

Question

我目前正在努力思考我是否已经达到了良好的分离水平，或者我是否在某个地方错过了要点，因为我对学习开发的纪律方面相对较新......

我开始时的目标是创建一个与任何持久性机制无关的层 - 我称之为 data-api。然后我使用JDO实现了这些接口(interface)，并将这个项目命名为data-jdo。逻辑层理想情况下只与数据 API 相关。

这就是我不确定什么有意义的地方。必须以某种方式调用业务逻辑层，对吧？那么，是否期望调用者提供 data-api(data-jdo 或其他取决于实验的东西)的实现(适合说/做注入(inject)？)？

因此，目标可能是(主要是为了经验而不是生产力)实现一个可以替代 data-jdo 的 data-jpa 包。因此，最顶层(Web 服务、作为工具一部分的通用主方法、单元测试等)是选择使用哪个实现的层。

我应该使用像 Spring 这样的框架来允许我通过 XML 选择使用我的 data-api 的哪个实现吗？

抱歉，如果这有点模糊...我想根本问题是，API 的使用者在什么时候依赖、提供或与该 API 的实现配对？如果答案是或应该是“从不”，那么用什么来确保一切在运行时可用，以及消费者如何获得仅使用接口(interface)描述的“API”的实例？

Answer 1

我有 .net 背景，而不是 Java 背景，所以恐怕我无法帮助您了解 Java 细节。

The business logic layer has to be invoked somehow, right? So is the expectation that the implementation of the data-api (data-jdo, or something else depending on experimentation) is provided (appropriate to say/do injected?) by the invoker?

是的。在 .Net 世界中，我使用一个工厂(如 Factory Pattern 的实例)，它动态返回数据提供程序实现(要使用的其中一个由配置设置)。数据提供程序由工厂作为“对象”返回，并由调用业务逻辑代码将其转换为正确的类型 - 由业务逻辑所针对的接口(interface)指定。

我有(另一篇!)关于 Dependency Injection 的文章对于.Net，这可能有助于解释一些问题，但我确信在某个地方有很好的基于java的问题。

Should I be using some framework like Spring to allow me to choose which implementation of my data-api is used, via XML?

也许吧。我想说先花时间掌握这些概念，然后再担心“最佳实践”。仅供引用，我通过自己编写所有代码来艰难地学习 AJAX。这些天我会直接运行一个好的框架，但我认为只有在通过在煤炭工作面进行一些硬移植来真正掌握了基础知识之后，我才有信心做到这一点:)

... If the answer is or should be "never" then what...

是的 - 永远不会。使用工厂。