这个帖子 http://www.theserverside.net/tt/articles/showarticle.tss?id=Top5WSMistakes
鼓励我为业务逻辑层创建 Web 服务，但很多人在数据访问层中使用它。
我想创建一个项目，我想在其中从桌面应用程序、网站和手机访问相同的数据存储库。你会推荐我什么？
在任何情况下，将 Web 服务实现到两个层可能是一个好主意吗？
最佳答案
这个问题太开放了，所以答案是: 取决于 。
您的应用程序对数据有什么需求？它只是数据访问还是涉及一些业务逻辑？如果只是访问数据，您真的希望客户端直接控制它吗？这三个应用程序有多相似？他们共享功能还是仅共享数据？
在我看来，您可以选择两条主要路径:
1 - 公开业务的 Web 服务，数据隐藏在 Web 服务 后面。如果三个客户端(我将桌面应用程序、Web 应用程序和手机称为“客户端”，因为它们就是如此)共享功能(即它们对于同一业务模型具有不同的 View )，那么这是一个很好的设置。这避免了在所有客户端中复制类似的业务逻辑；
2 - 直接使用网络服务 公开数据。如果三个客户端没有任何共同点，只是将相同的数据用于不同的目的，那么这是一个很好的设置。但是在这种情况下，有了三套业务逻辑，你要把逻辑放在哪里？在客户？这将如何适用于桌面应用程序(考虑到您安装此桌面应用程序 300 次左右)？您再次需要一些服务和客户端是 thin clients 而不是 thick 的。
如果您将 1) 和 2) 考虑在内，您会发现通常在数据前放置 service layer 会更好。
回到“视情况而定”， 首先分析您的特殊需求，然后选择最适合您情况的解决方案 。
点 3 怎么样？ 使您的数据访问层成为一个库 (.jar、.dll 或您使用的任何技术)，并将其提供给为您的客户服务的(1？2？3？)业务 Web 服务？
关于web-services - 用于业务逻辑或数据访问层的 Web 服务，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4531074/