Web应用程序与Web服务与经典应用程序

Question

我需要帮助。

我有一个项目，我需要与本地数据库服务器通信的应用程序，并与中央远程数据库服务器同时完成一些任务（从本地服务器创建订单读取库存配额，然后将订单写入中央订单数据库，......） 。 所以，我不知道哪种架构和技术可以做到这一点。 Web应用程序，每台计算机上的.NET WinForms客户端应用程序，或基于Web服务的客户端应用程序中央应用程序？ 这些方法之间的一般差异是什么？

由于

Answer 1

如果您不想直接向客户端公开数据库，我建议在其间使用Web服务层。根据数据的敏感性和网络的安全级别，我建议使用Web服务方法（您可以自己管理数据加密，无需昂贵的ssl证书）或Web界面（可能更容易构建，但安全性有限制。）

Answer 2

我同意Tomas的观点，即Web服务层可能很好。但是，当涉及在webforms或winforms之间进行选择时，我认为您的问题不包含足够的信息来做出选择。

我想说如果你想要一个功能强大且功能丰富的用户界面，并希望简化开发，那么Winforms可能就是这样。但是，如果您需要从各种各样的客户端使用它并希望更容易维护和部署，那么Web应用程序可能是最好的。

Answer 3

首先，关注这些数据库之间的确切关系。 “本地”是什么意思。就在用户的桌面上？在他们办公室的所有用户之间共享？据推测，相对于中央订单服务器的世界观，本地报价（你的意思是股票报价而非配额？）可能会有点过时。那有关系吗？我订购价格为78.34的100 X订单，实际价格可能会有所不同。什么是预期的行为。

我的猜测是至少有一些业务逻辑，因此我们需要决定运行的位置。一种（胖客户端）方法是将该逻辑放在桌面上，然后桌面应用程序可以直接写入中央数据库。我不倾向于这样做有几个原因：

1. 每个客户端桌面都会获得数据库连接。扩展性不好，当用户数量变得非常大时，数据库最终会变得不快。
2. 如果我们需要稍微不同的应用程序，可能通过Web或其他任何方式暴露给不同的用户，我们最终会重现该业务逻辑。

另一种方法（基于瘦或基于浏览器）将UI保留在桌面上，但将逻辑放在服务器上。然后客户端可以调用某种服务。现在有很多可能的方法，一个简单的Web服务或休息服务将完成这项工作。我希望很明显，这个基于服务的appraoch解决了我的两点。

通过对称，我会以相同的方式处理本地数据库，将它们包装在服务中。但是，数据库之间可能存在一些更复杂的关系，在这种情况下，您可能需要本地服务层与中央服务层进行交互。

我正在吹嘘“不要重复自己”的一般原则，实施每一项业务逻辑。