32

Wikipedia says:

MVC provides front and back ends for the database, the user, and the data processing components. The separation of software systems into front and back ends simplifies development and separates maintenance.

I still don't see the link between the model-view-controller principle and the idea of front- and backend. Can the Model with its access to the database be seen as the Backend and the View as the frontend?

Kirinriki
  • 855
  • 4
  • 12
  • 18

6 Answers6

58

OK.. first the terms:

  • Frontend - are the parts, which are visible to users: HTML, CSS, client-side Javascript. It all is basically "frontend". In a desktop application frontend would be the GUI.
  • Backend - is the invisible part. In web applications that is your java, ruby, php or any other serverside code. It can be either interpreted or compiled, because "how" it works has no impact on "what" it is.

If you read GUI Architectures and research the MVC pattern in general, you will understand that MVC is not about separation of backend and frontend. Especially when it comes to MVC-inspired patterns, that we use for web applications.

The goal of MVC and related patterns is to separate presentation from domain business logic.

Here are the basic responsibilities of MVC parts:

  • Model - business logic
  • View - presentation logic
  • Controller - changing state of model and view (based on user input)

Let's take an example:

  • alternative client application for twitter
  • uses OAuth for authentication
  • user can input different search phrases
  • takes information via Twitter's REST API
  • validates data
  • parses the JSON responses
  • manipulates DOM to present the information

This all can be done with client-side JavaScript. You can have MVC triad running "frontend"! At the same time, the "backend" which provides REST API is an MVC-like structure. Only this time the View is generating JSON responses, instead of HTML.

*Conclusion: You can use MVC pattern both on backend and frontend.**

Post Scriptum

Since you have been building some applications with Rails, your understanding of MVC might be a but distorted. The reason I say this is because, since RoR was initially made as a prototyping framework (notice all the scaffolding and other features for generating throw-away code), and because of its origin, Rails is actually implementing a very anemic version of MVP.

I call it "anemic", because they nerfed both View (it should be a passive object in MVP, not a simple template) and Model Layer (yes, it is supposed to be a complicated layer, not a collection of ORM instances).

I would recommend for you to read two publications to get a much better grasp on the subject:

The second one is as close as you can get to initial definition of pattern. That, together with "GUI Architectures" article, should provide you a solid footing on the subject. And the PoEAA book (hard read, btw) would give you context in which to expand it.

Community
  • 1
  • 1
tereško
  • 58,060
  • 25
  • 98
  • 150
  • 1
    Great, that's a really useful answer! Thanks for your links, it helps me to get a deeper understanding. That's the point, I started building applications with Rails and continued building Applications for iOS devices with Rails as Backend. So I tried to understand which position the Rails application takes in the Model-View-Controller pattern of the iOS-App. – Kirinriki Jun 17 '12 at 07:36
  • Good answer but model has nothing to do with business logic. It's just data. Business logic implies that the model performs actions which is not the case. – Pithikos Jun 01 '20 at 10:50
  • 1
    @Pithikos model is a layer. What you are talking about are *Active Record* instances. Those are not "models". They are just DB table abstractions. – tereško Jun 15 '20 at 14:43
21

Maybe the figure below can help..

MVC               Human language 
---------------   ---------------
model          -> data           
controllers    -> actions       
views          -> GUI

In very simple applications you end up with models being the database, views the HTML (or GUI for desktop applications) and controllers just the code linking the two.

However with today's complex web applications you can have an MVC framework both at backend (Django) and frontend (React, Angular). So it's all relative.

In backend:

MVC               backend
---------------   ---------------
model          -> database
controllers    -> glue code (from user or framework)
views          -> exposed API

In frontend

MVC               frontend
---------------   ---------------
model          -> data structure (in sync with what is received from backend)
controllers    -> glue code (from user or framework)
views          -> HTML

Bottom line: You can apply MVC anywhere where you want to decouple complexity

Pithikos
  • 18,827
  • 15
  • 113
  • 136
1

The front end is what the user sees which are the views. The back end are the controllers and the model.

Daniel A. White
  • 187,200
  • 47
  • 362
  • 445
1
  • views = frontend
  • models = backend
  • controllers = glue between frontend and backend
jopke
  • 1,186
  • 6
  • 18
1

In this case, backend traditionally means the deeper OS code or even your code that is not being seen/controlled by the user.

The frontend is the actual view being seen by the user.

dgund
  • 3,459
  • 4
  • 39
  • 64
0

I assume your question is in reference with M-V-C being used in developing full stack.

Front end : View pages; Back end : Controller, Model

Sana Kamal
  • 1
  • 1
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – jv-k Jan 17 '23 at 04:41