blocks|key|1503916|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

<a href="https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller" rel="nofollow noreferrer">MVC</a> was not designed for the web. Its use for the web was popularized by Ruby On Rails. Depending who you ask they are using the term wrong, or they redefined it... yet, it certainly is not <a href="http://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf" rel="nofollow noreferrer">what MVC meant in Smalltalk</a>, although a derived concept.

Why is that important? Because MVC was being used for desktop application, which did not have a big scary thing in the middle called "Internet", from which the client-side/server-side comes from.

"Internet" is a breach that is right in the middle of the View. That should answer most of your questions. I suggest the following nomenclature:

<ul>
<li>"Frontend" exists only on the client side.</li>
<li>"Presenter" exists only on the server side, it creates the "Frontend" sent to the client.</li>
<li>"View" is both, sort of. I would say includes both. However, some definitions of "View" are only the "Presenter". For others the "Presenter" is separate. Also, how much of the "Frontend" code is considered "View" is not so clear cut either.</li>
</ul>

Perhaps when there is a big scary thing called "Internet" the term "View" is not so useful.

See <a href="https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter" rel="nofollow noreferrer">Model–view–presenter</a>, let us not worry about what "Model" is there right now, will come back to that.

Let us see your questions...

<hr>

<blockquote>
 Nowadays, with modern frontend frameworks such as Angular, React, and Vue, does the entire presentation layer run on client side, and do the entire business logic layer and the entire data access layer run on the server side?
</blockquote>

Business logic and data access happen on the server side, that is correct. Angular, et.al. handle code on the frontend.

This does not mean that the frontend did not exist before such tools. Although it was usually much more static.

Now, what do you mean by presentation layer?

I assume you mean a presentation tier of n-tier architecture, and not the ISO OSI layer. However, presentation tier is a concept that does not have the big scary thing in the middle called "Internet".

Well, the frontend code needs a web framework. If you look how Express.js (the web framework associated with Angular) handles MVC, you will see that a "View" in the framework is basically a template (with HTML and so on), which is populated by (what I call) the presenter on the server side. If that is part of what you call presentation layer, then no, not all the presentation layer is on the client.

<hr>

<blockquote>
 Before the popular frontend frameworks came into use, e.g. 10-15 years ago, when Java EE and Spring were the most popular, does only a small part of the presentation layer run on client side, and do most of the presentation layer, the entire business logic layer and the entire data access layer run on the server side?
</blockquote>

Right, business logic and data access were also on the server.

There was less client side logic, however there was.

Using AJAX was a thing, however staying in the same page and doing dynamic load was much less common. Also stuff like <a href="https://developer.mozilla.org/en-US/docs/Web/API/History_API" rel="nofollow noreferrer">History API</a> and <a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API" rel="nofollow noreferrer">Web Workers</a> were not there... thus, some things we take for granted could not be done.

<hr>

<blockquote>
 When using MVC, is it correct that model means the same as the business logic layer, controller and view mean the same as the presentation layer?
</blockquote>

I think you got these backwards. The model, is a data model, no business logic. The logic goes in the controller. Or rather that is how it used to be...

I do not follow what Web MVC folks do, but I have seen the motto "Thin Controller - Fat Model" (sometimes reversed), meaning to move logic from controllers to models.

If Model, View, and Controller are the only options you have about where to put logic, you will end up debating where to put things that are neither (a.k.a the fat).

There are other things aside from Model, View, Controller. You have views, yet you still need a router. You have a model, yet you still need data access. There are other concerns such as authentication, logs, configuration, templates, internationalization, etc... they have to go somewhere... Model, View or Controller?

Please watch <a href="https://www.youtube.com/watch?v=iUe6tacW3JE" rel="nofollow noreferrer">Baruco 2012: Deconstructing the framework, by Gary Bernhardt</a>.

<hr>

<blockquote>
 With modern frontend frameworks, where are model, controller and view running: server side or client side?
</blockquote>

Here is a hurdle: You can have a Web API first, then have a frontend framework with templates and populate them with data from the Web API.

Thus, you are passing a data model to the view. Hmm... isn't that a viewmodel? Wait, that is another model. So... Model–view–presenter could be that? Will come back to that.

See <a href="https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel" rel="nofollow noreferrer">Model–view–viewmodel</a>.

A model is how you represent the data. It makes sense to have a model to deal with every external system. One external system is the web browser, another is the database. In fact, I would argue that the model should not run, it should be just data. And now the "Thin Controller - Fat Model" folks are pissed off with me.

I think treating the browser as a external system is correct. However, it also useful to think you are "uploading" code to the browser, and that code... well it is a system, for which the server side is an external system and the user is another external system. Then the frontend could have a controller... just let that sink in.

Here is another hurdle: You must have all your logic on the server. However, it makes sense to have part of the same logic on the client. It will save you some bandwidth, and will make the app more responsive. You still need it in the server, because security.

This means that, although your controller is in the server, you may have business logic in the client. That means that the frontend has a bit of business logic.

<hr>

<blockquote>
 Before the popular frontend frameworks came into use, e.g. 10-15 years ago, when Java EE and Spring were the most popular, where are model, controller and view running: server side or client side?
</blockquote>

It was clearer back then, because most logic was on the server. With little logic on the frontend. However, guess what? Having a bit of business logic on the frontend was also a thing. I am, of course, talking about client side validations.

<hr>

Listen, there is an idea behind all the n-tier architectures: have a functional core (application tier), have a layer for each external system (presentation tier to deal with the user, data tier to deal with the database), and then optionally insert layers in the middle, that is how you get your 5-tier architectures and so on.

Of course, some people teach different names for the tiers.

Speaking of inserting layers, that is what we were doing with Model–view–presenter and Model–view–viewmodel. You can imagine: View-Presenter-Viewmodel-Controller-Model. 5-tier architecture (one variant of). Here the view is the frontend, the rest is on the server side. The presenter has router, push notifications and template system. The viewmodel is the representation of the view on the server. The controller manipulates the viewmodel, the presenter sends updates to the view based on the viewmodel. The controller also talks to the model permanent storage... wait, we still need to map the model to the database... 6-tier architecture! (we can keep adding layers)

Thus, instead of trying to understand n-tiers architectures, MVC and the Ruby On Rails effects on men, I suggest to try to understand functional core and imperative shell (See <a href="https://www.destroyallsoftware.com/talks/boundaries" rel="nofollow noreferrer">Boundaries</a>). Then you go to <a href="https://www.youtube.com/watch?v=o_TH-Y78tt4" rel="nofollow noreferrer">clean architecture</a> or similar (hexagonal architecture, onion architecture, and so on) as they share the same principles.

<hr>

In my personal opinion, trying to use MVC for the web, at least as presented by most frameworks, is wrong. However, I am controversial like that. I strongly suggest a second opinion.

I have some difficulty, when trying to understand about the architecture (presentation i.e. UI layer, business logic layer, and data access layer, and MVC) and deployment (which part runs on client or server side) of web applications.

<ol>
<li>Nowadays, with modern frontend frameworks such as Angular, React, and Vue, does the entire presentation layer run on client side, and do the entire business logic layer and the entire data access layer run on the server side?</li>
<li>Before the popular frontend frameworks came into use, e.g. 10-15 years ago, when Java EE and Spring were the most popular, does only a small part of the presentation layer run on client side, and do most of the presentation layer, the entire business logic layer and the entire data access layer run on the server side?</li>
<li>When using MVC, is it correct that model means the same as the business logic layer, controller and view mean the same as the presentation layer?</li>
<li>With modern frontend frameworks, where are model, controller and view running: server side or client side?</li>
<li>Before the popular frontend frameworks came into use, e.g. 10-15 years ago, when Java EE and Spring were the most popular, where are model, controller and view running: server side or client side?</li>
</ol>

Thanks.

Where do presentation, business logic, and data access layers and MVC components run: server side or client side?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

当我试图理解web应用程序的体系结构(表示层，即UI层、业务逻辑层、数据访问层和MVC)和部署(其中部分运行在客户端或服务器端)时，我遇到了一些困难。现在，有了棱角、React和Vue等现代前端框架，整个表示层是否运行在客户端，整个业务逻辑层和整个数据访问层是否运行在服务器端？在流行的前端框架开始使用之前(例如10-15年前，Java EE和Spring是最流行的)，表示层的一小部分是否运行在客户

问表示、业务逻辑、数据访问层和MVC组件在哪里运行:服务器端还是客户端？
EN

回答 1

Software Engineering用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问表示、业务逻辑、数据访问层和MVC组件在哪里运行:服务器端还是客户端？EN