技术架构：服务层与否？

Question

我们有一个由几个应用程序组成的平台。

我们必须开发一个 API，它必须分解与数据库的所有交互。 在这个 API 中，我们也将拥有一个 XML 格式的数据库版本。 XML 格式仅供一个应用程序使用。

我们的应用程序是在经典架构中开发的：dao - 服务层 - 表示层。

DAO 层将移至 API。在这一点上没有问题。 在很多应用中，服务层只是表示层和dao层之间的一个网关，没有具体的业务代码。

所以我的问题是：

• 我们应该为每个 dao 创建一个带有服务层的 API 吗？
• 如果是，那么在应用程序中保留一个从 API 调用服务层的服务层？
• 我们是否应该在 API 中创建一个服务层来管理工厂（数据库/XML），但这意味着每个应用程序都必须提供信息来选择要选择的 dao（当只有一个应用程序有此需求时）？
• 或者只是在API中为数据库和xml创建不同包中的所有dao，将工厂保留在有需要的应用程序中，并在所有其他应用程序中调用dao（数据库）？

需要帮助！ :p 我迷路了……

仅供参考，我们使用的是 Java 1.6 和 Spring 3.1.1。暂时在 DAO 中使用 JDBC 模板。 我们正在寻找有关 spring data jdbc 以替换 JDBC 模板的信息。 对此有任何建议可以不胜感激^^ [无休眠-JPA解决方案]

谢谢。

---

[编辑 1]

换句话说，在应用程序和 API 中保留服务层是我拥有抽象层的一种方式。如果我们必须修改数据库结构，如果我们也可以直接在API的服务层进行一些更改，那么我们可能不需要编辑所有应用程序。

想象 3 种可能性：

1. API 中的服务层与工厂选择使用哪个 dao（xml/数据库）
2. API 中的 dao
3. 数据库 API 中的服务层和 XML API 中的特定层

你选择什么解决方案？

[编辑 2]

创建一个独特的类来调用 API 是否有趣？就像在外观设计模式中一样。

Answer 1

将服务层用于本应做的事情：提供真实世界的服务，通过为每个提供的服务使用一个或多个 DAO（以及其他诸如管理事务、清理 Strings 和其他类似的东西）。

如果您（与更有经验的同事一起）认为不需要此服务层，请不要将其放入您的架构中。但是请确保创建您的架构的概念证明（这可能包含系统或部分系统的某些复杂功能的实现），以便您可以稍后对其进行评估以证明您是否真的不需要这样的层（或如果你这样做）。

Answer 2

我的理解是，您需要将业务层与表示层分离并重用，让多个客户端应用程序使用相同的业务实现。

在这种情况下，您需要在 API 中实现服务层。一些优点：

1. 您无需为处理演示的任何客户端应用程序重复服务实现。
2. 您可以轻松地将数据库模型设计与业务分离。设计模式（DTO、Facade）和横切关注点很容易被引入。
3. 与拥有 DB 实现细节的 DAO 相比，设计良好的服务层需要进行最少的修改。

在这个 API 中，我们也会有一个 XML 格式的数据库版本。 XML 格式仅供一个应用程序使用。

如果需要，通过 API 提供此实现，更多客户端应用程序将能够在未来使用它。

Spring 远程处理为此类设计提供了出色的工具（RMI、HTTP 调用程序等）

我认为证明 DAO 的 API 没有任何附加价值。