用于业务逻辑或数据访问层的 Web 服务
这篇文章 http://www.theserverside.net/tt/articles/showarticle .tss?id=Top5WSMistakes 鼓励我为业务逻辑层创建 Web 服务，但很多人在数据访问层中使用它。
我想创建一个项目，我想从桌面应用程序、网站和手机访问相同的数据存储库。你会推荐我什么？
在任何情况下，在两个层上实现 Web 服务可能是一个好主意吗？
This post http://www.theserverside.net/tt/articles/showarticle.tss?id=Top5WSMistakes
encourages me to create the web service for business logic layer but many people use it in the data access layer.
I want to create a project where i want to access the same data repository from a desktop application, website and a cell phone. What would you recommend me?
Is there any case it may be a good idea to implement web services to both layers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个问题太开放式，所以答案是：这取决于。
您的应用程序对数据有什么需求？仅仅是数据访问还是涉及一些业务逻辑？如果只是访问数据，您真的希望客户端能够直接控制它吗？这三个应用程序有多相似？他们共享功能还是仅共享数据？
在我看来，您可以选择两条主要路径：
1 - 为业务公开 Web 服务，并将数据隐藏在 Web 服务后面。如果三个客户端（我将桌面应用程序、网络应用程序和手机称为“客户端”，因为它们就是这样）共享功能（即它们是同一业务模型的不同视图），那么这是一个很好的设置。这避免了在所有客户端中重复类似的业务逻辑；
2 - 直接通过网络服务公开数据。如果三个客户端没有任何共同点，只是将相同的数据用于不同的目的，那么这是一个很好的设置。但是这样的话，有了三套业务逻辑，你要把逻辑放在哪里呢？在客户中？这对于桌面应用程序有何作用（考虑到您安装此桌面应用程序 300 次左右）？您再次需要一些服务，并且客户端是瘦客户端而不是厚。
如果您考虑 1) 和 2)，您会发现通常最好有一个 服务层位于数据前面。
回到“视情况而定”，首先分析您的特殊需求，然后再选择最适合您情况的解决方案。
点3怎么样？ 将您的数据访问层放入库（.jar、.dll 或您正在使用的任何技术）并将其提供给为您的客户提供服务的（1？2？3？）业务 Web 服务？
The question is too open ended so the answer is: it depends.
What needs do your applications have for the data? Is it just data access or some business logic involved? If it is just accessing of data, do you really want the client to have direct control over it? How similar are the three applications? Do they share functionality or just data?
As I see it there are two main paths you can chose:
1 - expose a web service for the business, with the data hidden behind the web service. This is a good setup if the three clients (I'll call the desktop app, web app and cell phone "clients" since that is what they are) share functionality (i.e. they are different views for the same business model). This avoids duplicating similar business logic in all the clients;
2 - expose the data directly with a web service. This is a good setup if the three clients have nothing in common but just use the same data for different purposes. But in this case, with the three sets of business logic, where are you going to put the logic? In the clients? How will that work for the desktop application (considering you install this desktop app 300 times or so)? You again need some service and the clients to be thin clients not thick ones.
If you take 1) and 2) into consideration you will see that usually it is better to have a service layer in front of your data.
Going back to the "it depends", analyze your special needs first and only then choose the solution that is best suited for your situation.
How about a point 3? make your data access layer into a library (.jar, .dll or whatever technology you are using) and make that available to the (1? 2? 3?) business web services that serve your clients?