在不同的服务器上托管表示层和应用程序层

您的第一个挑战将是连接您的表示层和服务层。使用Web API或SOAP公开服务层应该非常轻松。您甚至可以使用WindowsRPC或DCOM，尽管我怀疑这可能是侵入性的，并强制更改您的服务层代码。

当你这样做的时候，你将引入一个额外的网络跃点和数据的编组/解编组（因为对象被转换为字符串表示，然后在网络上传输后被转换回对象）。根据你的应用程序，这可能没有任何区别，但需要记住。

您还需要解决如何扩展的问题。这里最常见的方法是引入两个负载平衡器，一个用于前端，另一个用于后端。缩放并添加另一层复杂性。

一种更现代（更简单、更高效）的方法可能是将您的应用程序组织为一组微服务。你可以部署一个应用程序功能库（比如用户管理或用户偏好），并将用户服务、DTO和演示控制器打包和部署在一起。然后，您可以单独部署并扩展应用程序的每个部分（并在每个部分中获得本机性能）。

当您将控制器逻辑移动到客户端（web浏览器）时，这种方法真的开始大放异彩。单个客户端通过REST.与多种后端通信

如果你不这样做，如果你以经典的mvc.net方式在服务器上模板化，那么微服务的方法就会变得不那么优雅。至少，您必须解决在多个可部署程序之间分发通用模板资产（css、js、image）的问题。这不是一个大问题，但您可能需要将这部分内容纳入构建过程。此外，您还必须考虑当您更改这些资产时会发生什么。您是否需要重新部署所有的全栈微服务？

您可以使用WCF。。。

WCF背后的思想是允许您实现通过网络连接公开的服务器端类的效果。

您使用接口的属性和方法定义接口，构建它们的服务器端实现，并在实现的客户端让Visual Studio自动为您生成API。

您可以通过TCP/IP或HTTP连接使用WCF（不确定TCP/IP是否适合负载平衡/扩展）。TCP/IP显然是为了在同一局域网上的机器之间进行连接，我相信它的开销比HTTP小。WCF也在命名管道上工作，但这是为了在同一台机器上进行进程间通信，与此无关。无论如何，无论使用哪种协议，仍然有一个序列化过程；对于HTTP，它将是SOAP（有些重）；不确定TCP/IP。

我已经通过TCP/IP、HTTP和命名管道成功地实现了使用WCF的解决方案，但其中任何一个都从未考虑过扩展。

出于大多数目的，我现在不再使用WCF，而是使用RESTful.NETWEB API 2服务，使用JSON作为序列化格式。使用它们可能比使用WCF需要更多的工作，但在服务器端设置要容易得多。

附录：

我应该为RESTful WEB API方法增加一个好处：灵活性。现在，您不希望客户端浏览器处理javascript，但如果这种情况发生了变化，则不必对应用程序服务器进行任何更改。更改将仅限于您的演示服务器将处理从自身卸载到浏览器。如果您选择RPC方法（如WCF），您将对该体系结构有更大的承诺，并失去轻松摆脱它的灵活性。