我最近一直在设计相当多的 Windows 窗体应用程序（数据输入应用程序、办公集成等），虽然我一直在设计时考虑到逻辑层，但“中间层”业务逻辑层一直托管在台式PC（即物理客户端-服务器）。
当我处理更复杂的应用程序时，我发现自己渴望使用物理中间层，桌面客户端将请求传递回应用程序服务器以处理业务逻辑（可能会定期更改）和接口。感觉就像我错过了 Web 应用程序更原生的可伸缩性和可维护性等因素。
我很想知道其他 WinForms 开发人员在他们的中间层分离方面走了多远：
将业务逻辑移到单独的层是否有好处，或者将组件本地托管在 PC 上是否更实用（并且只需确保您有一个良好的部署模型来随着业务规则的变化推出定期发布）？
或者，如果涉及这些因素，我是否应该完全引导客户远离 WinForms？有了 Silverlight 甚至 ASP.NET w/AJAX 等替代方案，选择 WinForms 客户端的理由似乎越来越少。
需要记住的重要一点是，在使用单独的中间层进行开发的便利性与所有可扩展性优势等之间需要权衡取舍。我的意思是您必须在代码中刷新接口映射等，您必须在某个地方部署一个中间层供您的测试人员使用，这需要刷新等。此外，如果您像我一样懒惰并直接传递您的实体框架对象，您无法将它们序列化到中间层，所以您然后需要为您的所有操作等创建 DTO。
其中一些开销可以由一个体面的构建系统处理，但这也需要努力设置和维护。
我首选的策略是在程序集方面保持物理分离（即我有一个单独的业务逻辑/数据访问程序集），并通过接口层将所有调用路由到业务层，接口层是一堆外观类。所以所有这些程序集都驻留在我的 Windows 应用程序中。我还为所有这些外观创建接口，并通过工厂访问它们。
这样，如果我需要分离中间层，并且在生产力方面的权衡是值得的，我可以将我的业务层分离出来，把它放在 WCF 服务后面（因为那是我首选的服务平台）并根据我的外观分发的内容以及他们接受的内容执行一些重构。
这就是为什么我总是倾向于在 Web 环境中工作的一个例子。如果您的客户端应用程序可以使用网络进行服务调用，那么它肯定可以用于从 Web 服务器发送和检索数据。
当然，客户限制可能会改变您的最终路径，但当有机会影响方向时，我会转向基于 Web 的解决方案。有一些可用的部署技术可以为您提供比传统桌面软件包更容易的升级路径，但没有真正替代更新基于服务器的应用程序的方法。
根据您的应用程序，有几个性能问题需要牢记。
如果您的工作在各个客户端（共享数据）之间非常相似，那么在中间层进行处理会更好，因为您可以利用缓存来减少整体处理。
如果您在客户端（私人数据）之间有所不同，那么通过在中间层进行处理您将不会获得太多收益。