SOA - 业务服务的数据访问是否作为单独的 Web 服务？
目前，在我的组织内部，我们正在尝试为 SOA 试点项目制定一些约定。 乍一看，我们认为最好强制服务用户使用业务服务，而不直接访问任何数据端点..但是是否存在这种情况不正确的特定场景，或者对于开发人员来说可能“有效”访问服务外部的特定数据端点？
我总是担心，如果我们开放它，实际上会损害重用，因为每个人都会使用可用的相同后端数据“重新发明”类似的业务服务，并且“理论上......更容易”编写一个新的业务服务，而不是问“使用我的数据库的其他服务做什么？”
因为即使服务几乎是直接传递到数据库，我们也能够应用规则来节省开发人员的时间并最终节省业务资金。
想法？
Currently inside my organization we are trying to come up w/ some conventions for a pilot SOA project. At first glance we thought it would be best to force users of the service to use the business service w/out direct access to any data endpoints .. but are there specific scenarios where this is not true or it might be "valid" for developers to have access to specific data endpoints outside of a service?
I always fear that if we open this up, it will actually hurt reuse because everyone will just "re-invent" similar business services using the same back-end data as it's available and would be "in theory .. easier" to just write a new business service rather than ask "what does this other service do that uses my database?"
Because even if the service is almost a direct pass through to the database we would have the ability to apply rules that would save developers time and ultimately the business money.
Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
无论如何，您的 Web 服务难道不会只是业务层的薄包装吗？ 除了一些简单的 DTO 之外，您的服务层可能不应该有比业务层更多的东西。 然后就没有人问“使用我的数据库的其他服务做什么？” 因为它没有使用你的数据库，而是使用你的 BL。
Wouldn't your webservice just be a thin wrapper for your business layer anyway? Your service layer probably shouldn't have anything more than your business layer besides some dumbed-down DTOs perhaps. Then noone is asking "what does this other service do that uses my database?" because it isn't using your db, it is using your BL.
当你描述“强迫”用户做任何事情时，你就是在挥舞危险信号。 也许您可以考虑您的问题，并用“启用”用户之类的术语重新表述，因为这应该是您决策的起点，并且 SOA 为不同的 UI 策略提供了优点和缺点。
You're waving a red flag when you describe "forcing" users to do anything. Maybe you can think about your question and rephrase it in terms something like "enable" users, because this should be the starting point for your decision, and SOA offers advantages and disadvantages for different UI strategies.