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和所有应用程序逻辑移到与演示文稿视图不同的服务器上吗?如果是这样,您如何配置服务器以了解在哪里查看?如果在某个地方有一个好的入门书,或者有人可以给我低调,我将永远感激不尽.
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服务器架构.
| 归档时间: |
|
| 查看次数: |
2313 次 |
| 最近记录: |