Windows 窗体应用程序的物理中间层分离

Question

我最近一直在设计很多 Windows 窗体应用程序（数据输入应用程序、办公集成等），虽然我一直在设计时考虑到逻辑层，但“中间层”业务逻辑层一直托管在台式电脑上（即物理客户端-服务器）。

当我处理更复杂的应用程序时，我发现自己渴望使用物理中间层，桌面客户端将请求传递回应用程序服务器以处理业务逻辑（可能会定期更改）和接口。感觉就像我错过了 Web 应用程序更原生的可扩展性和可维护性等因素。

我很想知道其他 WinForms 开发人员在他们的中间层分离方面走了多远：

• 您在中间层服务器上执行多少处理（如果有）？
• 您使用什么通信方式 - WCF、远程处理、Web 服务等？
• 性能在多大程度上是一个因素，您多久往返一次服务器？

将业务逻辑移到单独的层是否有好处，或者将组件本地托管在 PC 上是否更实用（只要确保您有一个良好的部署模型，以便随着业务规则的变化推出定期版本） ?

或者，如果涉及这些因素，我是否应该完全引导客户远离 WinForms？有了 Silverlight 甚至 ASP.NET w/AJAX 等替代方案，选择 WinForms 客户端的理由似乎越来越少。

Answer 1

需要牢记的重要一点是，在使用单独的中间层的开发便利性与所有可扩展性优势等之间需要权衡取舍。我的意思是您必须刷新接口映射等在您的代码中，您必须在某个地方部署一个中间层供您的测试人员使用，这需要刷新等。此外，如果您像我一样懒惰并直接传递您的实体框架对象，您不能将它们序列化到中间层，因此您需要为所有操作等创建 DTO。

其中一些开销可以由一个体面的构建系统处理，但这也需要努力设置和维护。

我的首选策略是在程序集方面保持物理分离（即我有一个单独的业务逻辑/数据访问程序集）并通过接口层将所有调用路由到业务层，这是一堆外观类。所以所有这些程序集都驻留在我的 Windows 应用程序中。我还为所有这些外观创建接口，并通过工厂访问它们。

这样，如果我需要分离中间层，并且在生产力方面的权衡是值得的，我可以将我的业务层分离出来，将它放在 WCF 服务后面（因为这是我的首选服务平台）并根据我的门面分发的内容以及他们接受的内容执行一些重构。

Answer 2

这就是为什么我总是倾向于在网络环境中工作的一个例子。如果您的客户端应用程序可以使用网络进行服务调用，那么它肯定可以用于从 Web 服务器发送和检索数据。

当然，客户限制可能会改变您的最终路径，但是当有机会影响方向时，我会转向基于 Web 的解决方案。与传统的桌面软件包相比，有一些部署技术可以为您提供更轻松的升级路径，但没有真正替代更新基于服务器的应用程序的方法。

Answer 3

根据您的应用程序，有几个性能问题需要牢记。

如果您的工作在各个客户端（共享数据）之间非常相似，那么在中间层进行处理会更好，因为您可以利用缓存来减少整体处理。

如果您在客户端（私有数据）之间有所不同，那么通过在中间层进行处理您将不会获得太多收益。