服务直接推或业务逻辑来处理

Question

更新：

本质而不是有服务器A的服务直接写入到数据库或数据表。让业务逻辑中的服务将值分配给一系列Properties。这样所有的计算和数据访问将直接在服务器B上完成。

某些事情可能并不清楚，服务器A是使用该服务的客户端。

---

所以我有一个独特的窘境，那就是处理这个特定问题的标准方法。我目前面临使用服务或内部逻辑的选项。场景：

• 两个服务器
• 服务器A：推请求到服务器B.
• 服务器B：注意到这些请求和变量，并实现业务逻辑。
• 服务器B：无论如何将要创建关系数据访问，所以它的工作量增加一倍。

的困境是，我不确定要处理这个标准或最佳方式。我的意思是，将服务器A数据图直接连接到数据库会更好吗？或者更可行的是让服务器A存储到属性然后让内部逻辑处理它？

我问的原因很明显，解决方案之一就是快速开发，但会遇到未来的问题或者性能不佳。

如：

• 服务器B：将坚定地填充数据表
• 服务器B：所有在这一点上的持续性将是它自己的从数据库中检索数据。
• 随着项目的发展，可能会很难重构。

这些是我最初的担忧，所以我倾向于选择二。但正如我所说，我不确定我的心态是否遵循标准或标准。

为了避免这被认为是一场辩论;

做选项1的缺点是否会随着复杂性的增长而影响任何项目的流动性？方案2的实施是否更加可行，因为我可以更好地实现直接访问数据访问层的通用性？

谢谢你的帮助，希望我明确地表达了我自己的意见，这是有道理的。如果不是，请发表评论，以便我可以相应编辑。

Answer 1

在一定程度上“取决于”。从特定的功能角度来看，任何作品都是正确的。

许多人有许多非功能或设计要求可能会限制或指导特定的实施。例如，如果您的设计应该是面向服务（SOA），那么每个服务器都应该是自治的。这意味着他们不应该共享数据库（他们甚至不应该共享一个模式）。在这种以消息为导向的情况下，通常是一种很好的模式。您可能想要看像消费者/生产者模式和面向消息的中间件，如队列或服务总线。在这种情况下，服务器A会将消息（命令）推送给将处理它的服务器B.您可以使用请求/答复模式来获得“答复”回到服务器A.或者，服务器B可以简单地发送另一个消息（事件）回A以告诉它已完成工作。

更新：

“数据”服务器B使用将完全被在消息中从B发送给它。