MVC or MVT architecture

Using Django
1

Hi all,

I am learning Django and I have a question about the architecture of Django. I have found the are to options:
MVC (Model-View-Controller)
MVT (Model-View-Template)

In mostly all the (video) tutorials, there is mentioned that Django is based on the MVT architecture. But when I search on documents about this, Wikipedia (for example) writes that Django is an MVC :thinking:.

MVC
MVC1329Ă—152 59.8 KB

Could someone explain the difference between these two? And which one is used for Django.

Thanks.

2

<opinion>
Don’t get hung up over terminology. Regardless of what name is applied, the intent is to define components within the the system and the features and functions those components provide. An architecture specification such as this is intended to provide guidance, and a common terminology when talking about such a system.

In real life, these lines and boundaries end up being blurred anyway. I don’t think I’ve ever seen a production system that truly separates those functions into three clear, distinct, and unambiguous layers - especially since what constitutes functionality belonging to those layers are not unambiguously defined. You can read 5 different articles or blog posts about what belongs in each component and find 5 different opinions.

(The closest I’ve seen to a “true” three-tier architecture was a system built around an API “middleware” (generic term, not the Django term) that serviced a JavaScript SPA front-end and accessed an API-based data back-end. But even then there were arguments about where some functionality would reside.)

Summary:

  • MVT is probably a more accurate description of how Django was originally designed and built.
  • You can build a system in Django using just about any desired architecture model - it’s not like Django enforces any particular form of architectural layering
  • Throw JavaScript frameworks such as React or Vue into the mix, along with enhanced database features such as stored procedures or custom functions, and you’re really dealing with 5 or 6 layers instead of the 3 defined in the traditional model.

</opinion>

Ken

1 Like
3

Hi Ken,

Thanks for the response.

Wow, this makes it quite more difficult to understand. I going to assume the MVC and MVT are based on users preferences.

4

I’ll also add that those two architectural models (MVC and MVT) are only two of many possible architectures for interactive applications. It’s not like a web app is either one or the other.

5

Thanks Ken,

I think I will find my way regarding this topic during improving my Django skills. :+1:

6

I’m a total newbie to Django, but the way I see it currently is this.

Model = back end

View = gets the model instance, and can route to templates which are dependent on the view

Controller? Looking like the view to me currently.

I’m not sure how to categorize it. The view is the web-browser, the controller is pretty much the view, and the model is the model.

Maybe VVM :slight_smile:

my 2cents as newb

7

This, together with apps, was perhaps the thing the stumped me the most as I started to use Django.

Django doesn’t enforce anything. In fact, most of my Django refactoring consist in moving functions from the views to the models (or anywhere else, as most places I can put them would do).

The pros must love this flexibility, but for newbies it’s very confusing. Speaking for myself, I want less ambiguity when I start something, not more.

Oh boy, and don’t get me started on forms.py! :zipper_mouth_face:

8

I won’t deny that the learning curve can be pretty steep. I’ve only been using Django regularly for about 6 years now, and I’m far from proficient in some areas.

On the other hand, it is now our go-to tool for any web-app we need to create. That flexibility has allowed our team to deploy applications on everything from a small site running on a Raspberry Pi 3, on up to a data query tool for a 3 TB database - and lots of things in-between. We know, going into any project, that we can start with Django as our base. And that’s a degree of comfort I’ve never had with any other framework.

1 Like
9

The model layer ist the backend where the business logic lives, yes. Django views are combining the data from the backend with the template representation layer and are fulfilling the role controllers have in MVC. And templates in Django do what views do in MVC. Maybe this confusion is just caused by naming controllers views and views templates. Otherwise it’s the same as MVC :slight_smile:.

10

Thanks, I’m pretty up to speed on MVC as a design pattern, but when I looked at how Django does it, I got pretty confused with the view layer which acts like a controller. Semantics, perhaps. But I’m used to this sort of logic:

View----[request]----->Controller–[response]—>Model–[response]–>Controller----->view

or maybe

View---->Controller---->Model-----View

Anyway, I’m kind of getting there… chur

11

Well, I think concepts like MVC look very harmless in a diagram, but are quite difficult to understand. The model layer handles all of the business logic. But what is business logic? Maybe it’s easier to describe it as “all the stuff that does not depend on how it’s represented”. For example, if your Django application serves a web frontend, has a CLI for management commands and sends out newsletters via email, all of those interfaces would still use the same model layer. But requests and responses are only happening when using the web frontend.

12

`Model = back end

View = gets the model instance, and can route to templates which are dependent on the view

Controller? Looking like the view to me currently.`

This is how I look at it as well right now, thank you for this description squeezemylizard. Sometimes I thinking too much complicated I guess.

Sorry for the late response