我最近一直在设计很多 Windows 窗体应用程序(数据输入应用程序、办公室集成等)，虽然我一直在设计逻辑层，但“中间层”业务逻辑层始终托管在桌面 PC 上(即物理客户端-服务器)。
当我处理更复杂的应用程序时，我发现自己渴望物理中间层，桌面客户端将请求传递回应用程序服务器以处理业务逻辑(可能会定期更改)和接口(interface)。感觉我错过了 Web 应用程序更原生的可扩展性和可维护性等因素。
我很想知道其他 WinForms 开发人员的中间层分离有多远:
- 您在中间层服务器上执行多少处理(如果有)？
- 您使用什么通信方法 - WCF、远程处理、网络服务等？
- 性能在多大程度上是一个因素，您多久往返一次服务器？
将业务逻辑移动到单独的层是否有好处，或者在 PC 上本地托管组件是否更实用(并且只需确保您有一个良好的部署模型，以便在业务规则发生变化时推出定期版本) ？
或者，如果涉及这些因素，我是否应该引导客户完全远离 WinForms？有了 Silverlight 甚至带有 AJAX 的 ASP.NET 等替代方案，选择 WinForms 客户端的理由似乎在减少。
最佳答案
要牢记的重要一点是，在使用单独的中间层开发的便利性与所有可扩展性优势等之间存在权衡。我的意思是你必须刷新接口(interface)映射等在你的代码中，你必须在某个地方部署一个中间层供你的测试人员使用，它需要刷新等。此外，如果你像我一样懒惰并直接传递你的 Entity Framework 对象，你不能将它们序列化到中间层，因此您需要为所有操作等创建 DTO。
其中一些开销可以由一个体面的构建系统来处理，但这也需要付出努力来设置和维护。
我的首选策略是在程序集方面保持物理分离(即我有一个单独的业务逻辑/数据访问程序集)并通过接口(interface)层将所有调用路由到业务层，这是一堆 Facade类。所以所有这些程序集都驻留在我的 Windows 应用程序中。我还为所有这些外观创建接口(interface)，并通过工厂访问它们。
那样的话，如果我需要中间层的分离，并且在生产力方面的权衡是值得的，我可以分离我的业务层，把它放在 WCF 服务后面(因为这是我的首选服务平台)并根据我的外观分发的内容以及它们对接受的内容执行的操作进行一些重构。
关于winforms - Windows 窗体应用程序的物理中间层分离，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1243041/