是否有一种可接受的方法来保持这些层/依赖项的分离?

我目前正在努力,无论我是否取得了很好的分离水平,或者如果我错过了某个地方的点,因为我是一个相对新的学习纪律方面的发展…

我开始时的目标是创建一个不可知任何持久性机制的层——我称之为这个数据API。然后,我使用JDO实现了这些接口,并将其称为项目数据JDO。理想情况下,逻辑层只知道数据API。

这就是我不确定什么有意义的地方。必须以某种方式调用业务逻辑层,对吗?那么,是否期望提供数据API(数据JDO或其他依赖于实验的东西)的实现(适合于说/做注入?)通过调用程序?

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

我是否应该使用一些像Spring这样的框架,以允许我通过XML选择使用哪个数据API实现?

对不起,如果有点含糊…我想根本的问题是,API的使用者在什么时候依赖、提供或与该API的实现配对?如果答案是或应该是“从不”,那么什么是用来确保所有东西在运行时都可用的,以及消费者如何获得“api”只使用接口描述的任何东西的实例?