我正在构建一个传统的.NET MVC网站，因此我有一个自然的三层软件架构设置（以视图形式呈现的表示层，控制器中的业务层，以及模型和数据访问层中的数据层）。
当我部署这样的网站时，通常要么在一个服务器上（Web站点和数据库位于同一台服务器上），要么在两个服务器上（一个Web服务器和一个单独的数据库服务器）。
如何实现3服务器架构（WEB、APP和DB）？Web服务器只需要拥有表示层（例如物理View/aspx页面），应用服务器将持有配置文件和bin文件夹，而数据库服务器则保持不变。
我的问题本质上是，是否可以将/bin和所有应用程序逻辑从表示层视图移动到单独的服务器上？如果可以，如何配置服务器以知道在哪里查找？如果有好的介绍或者有人能给我简要介绍一下，我会非常感激。
MVC不是3层架构。并不是每个解决方案都需要3层或n层，但了解区别仍然很重要。MVC恰好有三个主要元素，但这些元素不以“分层”的方式工作，它们是相互依存的：
Model <----- Controller
\ |
\ v
---- View
视图依赖于模型。控制器依赖于视图和模型。因此，这些多个依赖路径不起到层次结构的作用。
通常，三层解决方案如下：
Data Access <--- [Mapper] ---> Domain Model <--- [Presenter/Controller] ---> UI
Presenter/Controller是可选的 - 例如，在Windows Forms开发中，您通常看不到它，而是有一个“智能客户端”UI，这也可以。
这是一个3层架构，因为每个主要的3层（Data、Domain、UI）只有一个依赖。经典地，UI依赖于域模型（或“业务”模型），而域模型依赖于DAL。在更现代的实现中，域模型不依赖于DAL；相反，关系被反转，并且使用IoC容器稍后注入了一个抽象映射层。在任一情况下，每个层仅取决于前一个层。
在MVC架构中，C是控制器，V是UI（视图），M是域模型。因此，MVC是一种表现架构，而不是系统架构。它不封装数据访问。它可能不完全封装域模型，它可以被视为外部依赖项。它不是分层的。
如果要将层物理分离，则通常通过将域模型公开为Web服务（即WCF）来实现。这为您提供了改进的可伸缩性和分离关注点的更清晰的方法-域模型真正地可以在任何地方重复使用，并且可以部署在许多计算机上-但同时带有显着的开发成本以及持续的维护成本。
服务器体系结构反映了上述3层图表：
Database Server <----- Web Services <----- Application
ASP.NET MVC并不能帮助您建立一个三层系统。这只是一个前端模式。
实现多层系统时，您需要解决的主要问题是如何将对象从一个服务器传输到另一个服务器。您必须找到一种方法来序列化所有依赖于传输通道的对象。这会变得缓慢，并且开发会变得更加复杂。
有理由拥有一个单独的应用程序服务器：您可能在其中具有其他应用程序需要的逻辑，或者应用程序服务器可能具有与Web服务器不同的权限。但很难想象一个高流量的网站，其中所有请求都导致对远程应用程序服务器的调用。
下一个逻辑升级将是两个Web服务器和一个数据库服务器。
最终，在添加许多Web服务器之后，值得添加服务层。
随着规模的扩大，您可能还想添加分布式缓存、会话状态服务器、电子邮件服务器和其他专业服务器。
所以你的问题似乎是...
"你是否可以将/bin和所有应用逻辑从演示视图移动到单独的服务器上?"
如果我理解正确，我认为bin文件夹中的文件将是asp.net页面的编译代码。如果是这样，那么不，我认为它们需要与asp页面在同一台机器上。
如果您想将业务逻辑放在演示层的另一台机器上，则需要将该代码封装到单独的dll中，并通过soap或其他协议公开它..然后从演示层中的代码调用另一台服务器上的那些SOAP公开的dlls。