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

kaw*_*wai 4 .net c# architecture asp.net-mvc 3-tier

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

当我部署这样的站点时,它通常在一个服务器(网站和数据库实时)或两个服务器(一个Web服务器和一个单独的数据库服务器)上.

如何进行3服务器架构(WEB,APP和DB)?Web服务器是否只有演示文稿(例如物理View/aspx页面),app服务器将保存配置文件和bin文件夹,db服务器将保持原样?

我的问题基本上是,您可以简单地将/ bin和所有应用程序逻辑移到与演示文稿视图不同的服务器上吗?如果是这样,您如何配置服务器以了解在哪里查看?如果在某个地方有一个好的入门书,或者有人可以给我低调,我将永远感激不尽.

Aar*_*ght 6

MVC 不是一个3层架构.并非每个解决方案都需要是3层或n层,但理解这种区别仍然很重要.MVC碰巧有3个主要元素,但这些元素不能以"分层"方式工作,它们是相互依赖的:

Model <----- Controller
         \       |
          \      v
           ---- View
Run Code Online (Sandbox Code Playgroud)

视图取决于模型.Controller取决于视图模型.因此,这些多个依赖路径不起层的作用.

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

Data Access <--- [Mapper] ---> Domain Model <--- [Presenter/Controller] ---> UI
Run Code Online (Sandbox Code Playgroud)

演示者/控制器在某种程度上是可选的 - 例如,在Windows窗体开发中,您通常看不到它,而是拥有"智能客户端"UI,这也是可以的.

这是一个3层体系结构,因为3个主要层(Data,Domain,UI)中的每一个都只有一个依赖项.传统上,UI取决于域模型(或"业务"模型),域模型依赖于DAL.在更现代化的实现中,域模型并不能依赖于DAL; 相反,关系被反转,稍后使用IoC容器注入抽象Mapping层.在任何一种情况下,每个只取决于前一层.

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

如果您想在物理上分离层,那么通常通过将域模型公开为Web服务(即WCF)来完成.这给了你改进的可扩展性和关注清洁分离-领域模型是字面上的任何地方重复使用,并且可以跨多台计算机进行部署-但配有显著的前期开发成本,以及正在进行的维护成本.

服务器体系结构反映了上面的3层图:

Database Server <----- Web Services <----- Application
Run Code Online (Sandbox Code Playgroud)

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