3层架构vs. 3-server架构

Question

我正在构建一个传统的.NET MVC站点，所以我得到了一个自然的3层软件架构设置(以视图的形式呈现，控制器中的业务层，以及模型和数据访问层中的数据层)。

当我部署这样的站点时，它通常位于一台服务器(网站和db所在的位置)或两台服务器(一台web服务器和一台单独的db服务器)上。

如何使用3服务器架构(WEB、应用程序和数据库)？web服务器是否只有演示文稿(例如，physical View/aspx页面)，应用程序服务器将保存配置文件和bin文件夹，而数据库服务器将保持原样？

我的问题本质上是，您可以简单地将/bin和所有应用程序逻辑从表示视图移动到单独的服务器上吗？如果是这样的话，您如何配置服务器以知道在哪里查找？如果有一个很好的入门读物，或者有人能告诉我内幕，我将永远感激不尽。

Answer 1

MVC不是一个三层架构。并不是每个解决方案都需要是3层或n层，但了解它们之间的区别仍然很重要。MVC碰巧有3个主要元素，但这些元素不是以“分层”方式工作的，它们是相互依赖的：

Model <----- Controller
         \       |
          \      v
           ---- View

视图取决于模型。控制器取决于视图和模型。因此，这些多个依赖路径不起到层的作用。

通常，3层解决方案如下所示：

Data Access <--- [Mapper] ---> Domain Model <--- [Presenter/Controller] ---> UI

Presenter/Controller在某种程度上是可选的-例如，在Windows窗体开发中，您通常看不到它，相反，您有一个“智能客户端”UI，这也是可以的。

这是一个3层体系结构，因为3个主要层(数据、域、UI)中的每一层都只有一个依赖项。传统上，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服务器的架构。

Answer 2

在一些圈子里，我看到这种讨论被描述为n层和n层之间的区别，在这种情况下，“层”可能代表另一台机器。为了有一个使用这个定义的中间层，它必须被托管。例如，如果您有一个由表示层调用以获取其数据的服务层，则该服务层可能位于与表示层或数据库不同的计算机上。但是，该服务层作为windows服务或web服务托管。也就是说，在这台机器上有一个监听请求的进程。因此，您不能简单地将bin文件夹移动到不同的机器上，并希望能够完成这项工作。我会考虑使用WCF (Windows Communication Foundation)来创建这些类型的服务。

Answer 3

ASP.NET MVC不能帮助你建立一个3tier系统。这实际上只是一个前端模式。

实现多层系统必须解决的主要问题是将对象从一台服务器传输到另一台服务器。您必须找到一种方法来序列化所有依赖于传输通道的对象。这会变得缓慢，开发也会变得更加复杂。

有理由使用单独的应用程序服务器:您可能在其中包含其他应用程序需要的逻辑，或者应用程序服务器可能具有与You服务器不同的权限。但很难想象一个高流量的网站，所有的请求都会导致对远程应用服务器的调用。