技术架构:服务层还是不服务层？

Question

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

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

我们的应用程序是在一个经典的体系结构中开发的: dao -服务层-表示层。

DAO层将被移动到API中。在这一点上没问题。在许多应用程序中，服务层只是表示层和道层之间的一个网关，没有特定的业务代码。

所以我的问题是：

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

需要帮助！：我迷路了.

FYI，我们在Java1.6中使用了Spring3.1.1。暂时在DAO中使用JDBC模板。我们正在寻找关于spring数据jdbc的信息，以取代JDBC模板。有关这方面的任何建议都值得赞赏^^不存在Hibernate - JPA解决方案。

谢谢。

编辑1

换句话说，在应用程序中保留一个服务层&在API中有一个抽象层。如果我们必须修改数据库结构，如果我们也可以直接修改API的服务层，那么我们就不必编辑所有的应用程序了。

设想三种可能性：

1. API中的服务层与工厂选择使用哪一种方式(xml/数据库)
2. 只是API中的道
3. 用于数据库的API中的服务层& API中的XML专用层

你选择什么解决方案？

编辑2

创建一个调用API的惟一类有趣吗？就像立面设计模式一样。

Answer 1

将服务层用于所要做的事情:提供真实世界的服务，方法是在所提供的每个服务中使用一个或多个DAO(以及其他诸如管理事务、净化String和其他类似的事情)。

如果您(以及更有经验的同事)认为您不需要这个服务层，那么就不要将它放入您的体系结构中。但是，请确保创建体系结构概念的证明(这可能包含系统或其部分的某种复杂功能的实现)，以便稍后对其进行评估，以演示您是否真的不需要这样的层(或者如果确实需要)。

Answer 2

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

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

1. 对于任何处理演示文稿的客户端应用程序，您都不需要重复服务实现。
2. 您可以轻松地将数据库模型设计与业务分离。设计模式(DTO，外观)和横切关注点可以很容易地引入。
3. 与包含DB实现细节的DAOs相比，设计良好的服务层将需要最少的修改量。

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

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

Spring为这种设计提供了优秀的工具(RMI、HTTP调用等)

我不认为为DAOs验证API有任何附加价值。