c# - 3 层架构 v. 3 服务器架构

Question

我正在构建一个传统的 .NET MVC 站点，所以我有一个自然的 3 层软件架构设置(以 View 的形式表示， Controller 中的业务层，模型和数据访问中的数据层层)。

当我部署此类网站时，它通常会在一台服务器(网站和数据库所在的服务器)或两台服务器(一个网络服务器和一个单独的数据库服务器)上运行。

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

我的问题本质上是，您能否简单地将/bin 和所有应用程序逻辑移动到与演示 View 不同的服务器上？如果是这样，您如何配置服务器以知道在哪里查找？如果某处有好的入门书或有人可以告诉我内幕，我将永远感激不尽。

Answer 1

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

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

View 依赖于模型。 Controller 依赖于 View 和模型。因此，这些多个依赖路径不作为层运行。

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

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

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

这是一个 3 层架构，因为 3 个主要层(数据、域、UI)中的每一层都只有一个依赖项。通常，UI 取决于领域模型(或“业务”模型)，而领域模型取决于 DAL。在更现代的实现中，域模型不依赖于 DAL；相反，这种关系是颠倒的，稍后使用 IoC 容器注入(inject)抽象映射层。在任何一种情况下，每个 tier 仅依赖于前一个 tier。

在 MVC 架构中，C 是 Controller ，V 是 UI( View )，M 是领域模型。因此，MVC是一种表现架构，而不是系统架构。它不封装数据访问。它不一定完全封装领域模型，可以将其视为外部依赖。它没有分层。

如果您想在物理上分离层，那么通常通过将域模型公开为 Web 服务(即 WCF)来完成。这为您提供了改进的可扩展性和更清晰的关注点分离 - 领域模型字面上可在任何地方重用，并且可以部署在多台机器上 - 但伴随着重要的前期开发成本以及持续的维护成本。

服务器架构反射(reflect)了上面的 3 层图:

Database Server <----- Web Services <----- Application

“应用程序”是您的 MVC 应用程序，它与 Web 服务共享域模型(通过 SOAP 或 REST)。 Web 服务在一个(或多个)专用服务器上运行，而数据库显然托管在它自己的服务器上。这是一个 3 层、3 台服务器的架构。