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

我最近一直在设计许多Windows窗体应用程序（数据输入应用程序、office集成等），尽管我一直在设计逻辑层，但“中间层”业务逻辑层始终托管在桌面PC上（即物理客户端服务器）

当我接近更复杂的应用程序时，我发现自己渴望一个物理中间层，桌面客户端将请求传递回应用服务器，以处理业务逻辑（可能会定期更改）和接口。感觉上我忽略了一些因素，比如Web应用程序固有的可伸缩性和可维护性

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

• 在中间层服务器上执行多少处理（如果有）
• 您使用的是什么通信方法—WCF、远程处理、web服务等
• 性能是一个多大的因素，您往返服务器的频率是多少

将业务逻辑移动到一个单独的层上是否有好处，或者在PC上本地托管组件是否更实际（并且只需确保您有一个良好的部署模型，以便在业务规则更改时推出常规版本）

---

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

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

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

---

如果您的客户端（私有数据）不同，那么在中间层进行处理不会有多大好处。

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

---

当然，客户端限制可能会改变您的最终路径，但如果有机会影响方向，我会转向基于web的解决方案。有一些部署技术可以为您提供比传统桌面软件包更简单的升级路径，但是，更新基于服务器的应用程序是不可替代的。

需要记住的是，在使用独立的中间层进行开发的易用性与所有可伸缩性优势等之间存在权衡。我的意思是，您必须在代码中刷新接口映射等，您必须在某个地方部署一个中间层，供测试人员使用，这需要刷新等。此外，如果您像我一样懒惰，直接传递实体框架对象，则无法将它们序列化到中间层，因此您需要为所有操作等创建DTO

这些开销中的一部分可以由一个合适的构建系统来处理，但这也需要努力进行设置和维护

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

---

这样，如果我需要分离中间层，并且在生产力方面的权衡是值得的，我可以分离我的业务层，将其放在WCF服务后面（这是我首选的服务平台），并根据facades提供的内容执行一些重构，我当然看到了web环境的好处，但我想我正在考虑，通过连接WinForms客户端，跨服务与基于服务器的逻辑进行对话，实现“两全其美”是否可行。这只适用于具有强大WinForms约束的情况，例如严重的office集成。显然，我可以理解您的观点。它当然可以在服务器上有一组web服务的情况下工作，这些服务可以执行实际工作、持久化数据等。请将WPF/WinForms想象为一个具有web服务连接的瘦客户机。这样，您将保留丰富UI的好处。然而，您并没有真正获得传统上在web应用程序中看到的任何维护好处。您可以在web服务级别更改功能和行为，但添加功能需要UI刷新。有一些新的客户端应用程序部署工具，它们可能会有所帮助。