业务逻辑或数据访问层的Web服务

这个问题太开放了所以答案是：它取决于。 您的应用程序对数据有什么需求？是仅涉及数据访问还是涉及某些业务逻辑？如果它只是访问数据，您真的希望客户端直接控制它吗？三个应用程序有多相似？他们共享功能还是数据？ 在我看来，你可以选择两条主要路径： 1 - 为业务公开Web服务，数据隐藏在Web服务后面。如果三个客户端（我称之为桌面应用程序，Web应用程序和手机“客户端”，因为它们就是这样）共享功能（即它们是同一商业模型的不同视图），这是一个很好的设置。这避免了在所有客户端中复制类似的业务逻辑; 2 - 直接使用Web服务公开数据。如果三个客户端没有任何共同点，只是为了不同的目的使用相同的数据，这是一个很好的设置。但在这种情况下，使用三组业务逻辑，您将把逻辑放在哪里？在客户？如何为桌面应用程序工作（考虑到你安装这个桌面应用程序300次左右）？您再次需要一些服务，客户端是瘦客户端而不是厚客户端。 如果考虑1）和2），您会发现通常最好在数据前面加上服务层。 回到“它取决于”，首先分析您的特殊需求，然后选择最适合您情况的解决方案。 第3点怎么样？将您的数据访问层放入库（.jar，.dll或您正在使用的任何技术）中，并将其提供给为您的客户提供服务的（1？2？3？）业务Web服务？