我正在构建一个传统的.NET MVC网站，因此我有一个自然的三层软件体系结构设置（呈现形式为Views，业务层在控制器中，以及模型和数据访问层中的数据层）。三层体系结构与三层服务器体系结构
当我部署了这些站点时，它通常会在一台服务器（网站和数据库所在的位置）或两台服务器（一台Web服务器和一台单独的数据库服务器）上运行。
人们如何去了解3服务器体系结构（WEB，APP和DB）？ Web服务器是否只有演示文稿（例如物理View/aspx页面），应用服务器将保存配置文件和bin文件夹，并且数据库服务器将保持原样？
我的问题基本上是，你可以简单地将/ bin和所有应用程序逻辑从演示文稿视图移到单独的服务器上吗？如果是这样，你如何配置服务器知道去哪里看？如果在某个地方有好的入门书，或者有人可以给我低调，我会永远感激不尽。
在一些圈子中，我已经看到这个讨论表达为n层和n层之间的区别，其中这个上下文中的“层”可能代表另一台机器。为了有一个使用这个定义的中间层，它必须被托管。例如，如果您有表示层调用以获取其数据的服务层，则服务层可能与演示文稿或数据库位于不同的计算机上。但是，该服务层可以作为Windows服务或Web服务托管。也就是说，有一个进程监听该机器上的请求。因此，您不能简单地将bin文件夹移动到不同的机器上，并希望进行这项工作。我会看WCF（Windows Communication Foundation）来创建这些类型的服务。
下一个逻辑扩展将是两个Web服务器和一个数据库服务器。
最终在添加许多Web服务器之后，可能值得添加服务层。
您可能还想在扩展时添加分布式缓存，会话状态服务器，电子邮件服务器和其他专用服务器。
ASP.NET MVC不帮你建立一个3层系统。这只是一个前端模式。
您必须解决实现多层系统的主要问题是将对象从一台服务器传输到另一台服务器。您必须找到一种方法来根据传输通道序列化所有对象。这变得缓慢并且发展变得更加复杂。
有理由有一个单独的应用程序服务器：您可能有逻辑，其他应用程序需要或应用程序服务器可能具有不同的权限比网络服务器。但很难想象一个高流量的网站，所有的请求都会导致对远程应用服务器的呼叫。
所以你的问题似乎是...
“可以只需将/ bin和所有的应用程序逻辑从演示文稿视图移动到一个单独的服务器？”
如果我的理解正确，我相信您的bin文件夹中的文件将成为您的asp.net页面的编译代码。如果是这样的话，不，我相信他们需要和asp页面在同一台机器上。
如果你想在你的业务逻辑在一个单独的机器上从表示层，你需要将该代码包装到一个单独的dll中，并通过soap或其他协议公开..然后调用这些SOAP暴露的dll另一台服务器来自表示层中的代码。
MVC是不一个3层架构。并非每个解决方案都需要为三层或n层，但了解区别仍然很重要。 MVC恰好有3个主要元素，但这些元素不以“分层”的方式工作，他们是相互依存：
Model <----- Controller
\ |
\ v
---- View
的视图取决于模型。控制器取决于查看和型号。因此，这些多个依赖路径不能用作层。
通常有3层解决方案的样子：
Data Access <--- [Mapper] ---> Domain Model <--- [Presenter/Controller] ---> UI
演示/控制器是有些可选 - 在Windows窗体开发，例如，你平时看不到它，而不是你有一个“智能客户端“用户界面，这也可以。
这是一个3层体系结构，因为3个主层（Data，Domain，UI）中的每一个都只有一个依赖关系。通常，用户界面依赖于域模型（或“业务”模型），而域模型依赖于DAL。在更现代的实现中，域模型不是依赖于DAL;相反，关系是相反的，并且稍后在使用IoC容器时注入抽象映射层。在任一情况下，每个层仅取决于先前的层。
在MVC架构，C是控制器，V是UI（查看），并且M是域模型。因此，MVC是一种演示架构，而不是系统架构。它不封装数据访问。它可能不一定完全封装域模型，可以将其视为外部依赖项。它不是分层的。
如果你想物理分开层，那么通常通过将域模型公开为Web服务（即WCF）来完成。这给了你改进的可扩展性和关注清洁分离 - 领域模型是字面上可重复使用的任何地方，可以在多台机器上部署 - 但配备了一个显著的前期开发成本，以及正在进行的维护成本。
服务器架构反映上述3层图：
Database Server <----- Web Services <----- Application
“应用程序”是你的MVC应用程序，这股域模型与Web服务（通过SOAP或REST）。 Web服务运行在专用服务器（或多个服务器）上，显然，数据库托管在自己的服务器上。这是一个3层3服务器架构。