我目前正在努力解决是否达到了良好的分离水平，或者我是否在某处错过了这一点，因为我对学习发展的纪律方面相对较新......
我开始时的目标是创建一个与任何持久性机制无关的层 - 我称之为data-api。然后我使用JDO实现了这些接口，并将此项目称为data-jdo。理想情况下，逻辑层只能识别data-api。
这是我不确定什么是有道理的。必须以某种方式调用业务逻辑层，对吧？因此期望调用者提供data-api（data-jdo或其他取决于实验的东西）的实现（适合说/做注入？）？
因此，目标可能是（主要是为了经验而非生产力），实现一个可以替代data-jdo的data-jpa包。因此，最顶层（Web服务，作为工具一部分的通用主方法，单元测试，无论如何）是选择使用哪种实现的方法。
我是否应该使用像Spring这样的框架来允许我通过XML选择使用我的data-api的哪个实现？
很抱歉，如果这有点模糊......我想根本问题是，API的消费者在什么时候依赖，提供或与该API的实现配对？如果答案是或者应该是“从不”，那么用什么来确保一切都在运行时可用，以及消费者如何获得“API”仅用接口描述的实例？
答案 0 :(得分：1)
我来自.net背景 - 而不是Java背景，所以我担心我无法用Java细节来帮助你。
必须以某种方式调用业务逻辑层，对吧？因此期望调用者提供data-api（data-jdo或其他取决于实验的东西）的实现（适合说/做注入？）？
是。在.Net世界中，我使用Factory（在Factory Pattern的实例中）动态返回数据提供程序实现（其中一个使用的是由config设置）。工厂将数据提供程序作为“对象”返回，并由调用业务逻辑代码将其转换为正确的类型 - 由业务逻辑正在处理的接口所指定。
我在Dependency Injection上发表关于.Net的文章（另一篇！）可能有助于解释一些问题，但我确信在某些地方有很好的基于Java的文章。
我是否应该使用像Spring这样的框架来允许我通过XML选择使用我的data-api的哪个实现？
可能。我会说花时间先掌握这些概念，然后再担心“最佳实践”。仅供参考，我通过编写所有代码来学习AJAX。这些天我直接进入一个好的框架，但我只是觉得我有信心在通过在煤面上做一些硬嫁接来真正了解基础之后：）
......如果答案是或者应该是“永远”那么......
是的 - 它从不。使用工厂。
答案 1 :(得分：1)
您的data-api是一个DAO接口层，您的所有业务（也称为服务）层都应该了解持久性。并且业务层上方的表示层或任何其他层不应具有下面DAO层的任何“知识”。
要实现这一点，依靠像Spring这样的框架是一个好主意。顶级层加载应用程序上下文，该上下文包含框架的所有信息以加载适当的实现。
例如，您可以从前端加载applicationContext.xml以使用data-jdo，并从单元测试中加载testApplicationContext.xml以使用data-jpa。