Model-View-Controller (MVC) through the ages and in Django

Speaker 1: Hello everyone. Slightly nerve-wracking to be the first talk in this conference. But thank you very much for having me. And I think the upside of it is that you're all still very fresh and excited to actually listen to somebody, right? Uh just checking that the slides are working. So my name is Nick Haldeman. I am a software engineer. Um I started building websites in the 90s, and that's more or less what I've been doing ever since. Um also for the last 10 years or so using Django in various ways. And currently I'm the CTO at a London-based startup called Lindus Health. We use lots of Django as well. So today I want to talk to you about the Model View Controller architecture pattern, a little bit

Speaker 1: about its history, and also how it is relevant to Django today. So first of all, um a little bit of history. So we're in the year 1979. Um so what is going on in the 70s in terms of computers and technology? So one place that is innovating a lot in the 70s is CROX Park. It's a research center in Palo Alto, California. Um and lots of stuff is happening there in the 70s. For example, they're developing the Xerox Alto, which is a computer, kind of a PC before there were PCs. That's pioneering a lot of technology that we would recognize today. So for example, it has a graphical user interface with a desktop metaphor, which pretty much any

Speaker 1: operating system now has. It has a mouse. It's the first computer to have an Ethernet jack, so local network connectivity. So lots of stuff that will be very relevant. Also in the 70s, um at Park the Smalltalk programming languages developed. Um so uh Tobia said uh Python it he in the in the um keyno preceding this to be us called Python old. So smalltalk I guess is ancient. So it was developed in the 70s. Um it's one of the very first object-oriented languages. It pioneers a lot of concept that would be influential for lots of languages coming afterwards.

Speaker 1: including of course Python. So if you really love meta classes in Python or maybe you really hate them, you know, you can thank Small Doc for that. They kind of came up with this idea. And also as part of the small talk group, in 1979, there's actually a visiting scientist from Norway at Park. His name is Drikve Reinsgau. Um I don't speak Norwegian, that's my best bet at how to pronounce that. All the Norwegians out there, come and correct me afterwards. I think it's Rainskow. So he's visiting at Park in 79 and he's working on small talk and user interfaces and he's the first to name the model view controller pattern. Um and uh so I'm gonna go into a lot more detail what MVC or Model View Controller is, but I'm just gonna start off with this quote by him.

Speaker 1: Where he says the essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. And also the structure is useful if the user needs to see the same model element simultaneously in different contexts and or from different viewpoints. So there's um sort of two themes in this code that are going to be important that we're going to come back to. First of all, there's a user involved. So with MEC, it's usually about some sort of user interaction with the software And there's this idea that a model might be presented in multiple views. But first let's continue our trip to history. It's the year 99. So so what what is happening in 99?

Speaker 1: So of course the movie The Matrix comes out. Um so in 99, you know, the web or the internet is kind of on the cusp of mainstream popularity. Um you uh Uh you have notions like cyberspace and virtual reality that people are becoming aware of. There's a sense of maybe that computers are computers or the internet is starting to take over our lives. Of course, all themes that are wrapped up in the matrix. Um but the reality is the the internet or the World Wide Web is still fairly primitive in 1999. So in in 99 Internet Explorer 5 comes out. um Internet Explorer at the time probably uh the most popular browser.

Speaker 1: Um and uh you know browsing the web is kind of a Still a fairly primitive experience. You can pretty much load a web page, sort of static HTML, and then if you want to do something else, you have to click somewhere and it's gonna reload a whole new page. There's very little JavaScript that can give you a little bit of interactivity. But Internet Explorer 5 is actually the first browser that ships with uh the equivalent of the XML HTTP request JavaScript object. So uh this is what allows you in JavaScript to make a network request uh from within JavaScript after a page has loaded. Um this is very new then. Nobody could predict what would happen with that, but it's of course the basis for pretty much these very interactive dynamic user interfaces that we're used to from web applications now.

Speaker 1: But at the time, again, like the web is a fairly static thing. But there is one, or there's there's several ways, but there's one way you can add some interactivity through your web page, and that's a Java applet. So it's a little uh Java program that you can embed in your web page and because Java comes with a full-blown user interface framework as well as um a networking library uh you can have very rich interactive um uh experience with a java applet. So if we look at And um the Java documentation from that time actually of the uh GUI framework, JavaSwing, we see like very close to the top, they're referencing MVC. Because indeed JavaSwing at the time and I guess still today really um implements the MVC architecture at its core.

Speaker 1: So you know we're 20 years after Rain Scow um MVC pops up in a completely different context. It's still very relevant. So uh let's move forward. It's the year 2013. Um so this year is significant for myself personally because that's when I first started using Django. So um it's actually uh so Django has been around for a few years of course at the time already. Uh it's ch it's 1. 4 is the version that's current in in 2013. And you know when I start reading the documentation, when I start playing around with it Um you know, I see references to models, I see references to views, and I'm like, well, is this just MVC again? Uh yeah, I 'm being familiar with MVC. And indeed I would claim you know Django at its core has a sort of variant.

Speaker 1: of MVC and because it did it was probably easier for me to pick it up um if it were if if I if it would be harder for me to pick it up if I didn't know what MVC is and if Django didn't implement it Um so uh when I look at this timeline, so you know it's been going now for 40 years that MEC has popped up in various different contexts across different languages. cutting across different runtime sort of environments. And it's clearly still very relevant today if if you accept my claim that it's it's it's exists within Django, Django isn't going anywhere. Also, I'm cherry-picking examples here. Of course, it exists in other contexts. For example, there's Microsoft's ASB.

Speaker 1: net has MVC very explicitly as a sort of core component Um and also uh this is a Django conference. I don't know how people feel about using the R word, but it's relevant. Um Rails, of course, Django's big rival, Ruby on Rails um also very deliberately um uses MVC at its core. So when I see this, um so You know, we're working in software development that has so much churn in new languages, new libraries, new frameworks that we have to like learn and and and and and sort of get up to date all the time. But if I see something like that, so there's a concept that's relevant and has staying power for many decades. A question that I'm really interested in talking about is, so

Speaker 1: what does that tell me about, does it tell me something fundamental about programming or software architecture? Like what is it that makes MEC have this staying power? So that's a question I'm going to come back to in a bit. So first, um I want to talk about what is actually MVC and where do I see it in Django. So um first it's very important to say again like Rainsquaw kind of alluded to the user is important. So an MVC is usually a pattern used for Software that has some sort of user interface or user interaction. So the user is an important component here. Then I'm putting up here um a file system tree for a small Django

Speaker 1: project. This is actually what you end up with if you go through the Django tutorial and the official documentation. So you have a little uh project called MySite with an app called polls. So let's talk about the model. So what is the model? The model is the representation of your data or and or of your business logic in your application. And as Django developers, you should all be kind of familiar with that. It has a very clear equivalent in Django. We have a models file. It's going to have model classes that represent the kinds of data that your application is dealing with. So then what is a view? So the view is what a user sees. Um so uh we're not usually you know showing like a Django

Speaker 1: model object to a user directly, right? That's filtered through a view somehow And um so the view is something uh that has references to model objects. Um it can render them in various ways, and this is what's presented to the user. So um what is a controller then? So the controller is where um interactivity comes in, where user input comes in. So the controller is what accepts input from the user, and then typically the controller would manipulate model objects based on that. So updating models, deleting models, creating new models And and you know these models would then be reflected back to the user and rendered in a view. Um so now it gets a little bit tricky. So there is a terminology mismatch in uh in Django

Speaker 1: that makes it difficult to talk about MVC in the context of Django, because if you accept this definition that a view is what a user sees then what makes sense is to say, well, the templates are actually the view in the sort of MVC sense within Django. Because the templates is what takes models and would render them for a user, right? And then where is the controller? So if you accept this definition that the controller is what takes user input and uh manipulates models, then that's actually what a Django view does. Um so my claim is that the controller the most the closest equivalent in Django is actually what Django calls a view. And so, you know, let me let me put a big caveat on all of this, right?

Speaker 1: So MVC is not like a standard. There's no IEEE standard of MVC. Uh there is uh no kind of commonly accepted strict definition. Um various people describe it in different ways. And this is kind of my interpretation of what I think is the most common way of interpreting MVC, kind of filtered through the um uh lens of Django basically. And so I have a I have a nice thing to pick up on here from the keynote that preceded this by Tobias who talked about mental representation. and the chunk size of mental representation. So you can think of MEC also as a mental representation of the software architecture in your model and uh sorry

Speaker 1: in your application and the M, the V and the C are like really large chunks. in terms of chunk size in the in the mental representation. So the terminology can be confusing when talking about YMC in the context of Django. Um and it's clearly confusing enough that there's actually an SAQ uh in the official documentation. It says Django appears to be an MVC framework, but you call the controller the view and the view the template How come you don't use the standard names? And the answer is actually quite long in in whole in the whole. . . You might say that Django is an MTV framework that is model, template, and view. And regardless of how things are named, Django gets stuff done.

Speaker 1: And you know, I agree on that. Um uh we we're we're we're free to use the terms that make sense within Django. I would I would say two things. First of all The reason we talk about patterns are because they help us communicate with each other as programmers. So we describe patterns and we we we we name terms within those patterns because it's a shorthand for us to communicate. So if somebody is familiar with MVC, but not with Django, and I can tell them, hey, you know, MVC, sorry, Django uses MVC, then they might, it might be easier for them to pick it up. Um and the other thing I would say is that it's helpful to consider Django as part of this long heritage of MVC implementations. and sort of uh living in this ecosystem that's existed for several decades and has probably continued to exist.

Speaker 1: So I think it's kind of just nice to consider yourself part of this ecosystem. Um so yeah, so we talked about MVC. Um Tjango says, well, okay, we're MTV, um, that's fine. So what comes out here a bit is that MVC is really kind of a family of patterns, maybe. There's a bunch of related patterns. I'm just going to name a few more that people actually use in reality. So people use model view presenter as well. People use model view view model. And uh I think it's kind of a little bit tongue-in-cheek, people have started using the term model view whatever. Just reflecting the fact that yes, some some frameworks might have a clear model and a clear view, and then it's kind of up to the programmer to choose what is that thing that binds the model and the view together with the user interaction.

Speaker 1: I'm not gonna go into the nuances of all these different variants. Um I have found this Stack Overflow discussion to be very useful. Um I will link it in the Discord as well afterwards. Um Because it reflects a variety of different opinions, had a lot of different perspectives on these different variants, and it kind of does reflect the reality that yes, there is no clear consensus, there's no clear standard on these things. So but there's one thing that comes out when we look at this picture, it's that clearly um all of these variants have some sort of model or some sort of view component, right? So this is where I come back to like what is it that's fundamental about MVC that makes it so useful and helpful for such a long time

Speaker 1: Um and when we kind of look at this, I think um that's kind of what the core of it is. So it turns out if you're dealing with users and user interfaces and users interactions Um it is extremely helpful to have a model representation and then have this idea that you might have multiple views that use that same model. Pretty much if you're have to deal with a user, you probably will have to present your information in multiple different ways, in multiple different views, but it is very helpful to have one representation of the model. I'm just take putting up two different terms. It's a representation of the data and its presentation. And I think what's also key here is that There's a very clear separation of concerns, usually in MEC frameworks, between models and the views and controllers on the other side

Speaker 1: So if you think about it in Django, you know, you have a models file and the model classes, they don't know anything about the views or the uh the templates that they're going to be rendered in or used in They're completely it's a completely separate concern from the from the views and the templates. Um so this is uh and you can think about this also in a models file in Python, you would never import something from a view or make a reference to a template. It's completely independent. So this idea that you have a representation of the data and separate view and controller, I think is just really helpful. So I'm gonna go one step further um and kind of look at the reality of what we do uh when we do software development.

Speaker 1: You know, we start out with a a handful of models and views, then you know we have to you know maintain the software, we have to add new features, we're adding more views, we're adding more models, and then you know as time goes by we add even more models and even more views. And you know this is this is hard, right? So continuously um iterating on software over years potentially and it not devolving into chaos that that's hard. So this is this problem of extensibility. And I would claim that you know the separation of concerns between models and views helps us with that because we can keep adding more views independently of models and we have a clear place where model logic lives.

Speaker 1: And so to delve even more into the reality of software programming, of course there's usually multiple people involved. So we might start out with a couple of people working on a project, but then you know more people join the team And then some people leave and and more people join. And so we have this rotating cast of people who are working on the same code base. And and that's also hard, right? How how do we how do we work together uh on on this code base without it becoming chaotic and without stepping on each other's toes. So this is the hard problem of collaboration in software uh engineering. And uh I would claim, again, like this separation between model and views really helps us with that. It gives us some amount of independence. uh being able to work on views and models separately, it gives us um

Speaker 1: some amount of discoverability. So uh I can you know read the model code. and figure out which part of this model code I could use for my new view that I'm working on. If I'm a programmer that's new to the code base. the model layer kind of makes it easy for me to discover what are the rules really of of the data within this application. So this for me is a really nice summary of you know why why even care about using a framework like Django? Um it's because it helps us with these things. It helps us keep our code base extensible, it helps us with collaboration, and it does that almost like without us even having to do anything or being really aware even of these things.

Speaker 1: Um so I'll admit that you know these are some like fairly abstract and philosophical considerations. So to wrap up the talk, I want to talk about, I want to kind of take it back down to Earth. and talk about some very practical bits. So like in my day-to-day programming, how how do I think about MVC? Like where does MVC even come into place, if if at all Um so I have a um small Django app here. Um so on the I have models on the left. So there's an author model, uh there is a book model, um the book has a reference to authors. And then I have a simple view here. The view uh looks up um an author by its ID, so it takes an author ID as input.

Speaker 1: And uh it then also looks up what is the latest book that this author um has written uh based on the publication date, and then it will render a template uh passing in that author and the latest book. So what jumps out at me if I see this code is that is is this line looking up the latest book. So So what I would say is, so this is actually model code that happens to be injected into this view or controller, whichever terminology you want to use. Um uh he has been injected in this file, possibly uh and possibly that's not a good idea. Because it becomes very clear if I um If I extract this as a method called latest book on the model, it becomes clear this is actually model code because it's independent of the view.

Speaker 1: It doesn't have any knowledge about the view or the template that it's being used in So this is how I think about this distinction between model and view. In my day-to-day programming, I think about, well, is this really model code? Should it really go on the model? And if it is, I will move it on the model. And what that does for me is it makes um well in this case for example it makes the view actually simpler because now instead of um passing in the latest book explicitly into the template Um I can just pass in the author and the template can make a decision whether he wants to use the latest book or not. Also, um so this latest book method is now discoverable on the model. Like if my coworker now comes along

Speaker 1: and maybe wants to do a new view that also needs the latest book. They can easily discover this method and use it, as opposed to, you know, this method being somewhere in a view where they probably wouldn't find it and then they will probably duplicate it in some other view. Um so we get duplicated code, which you all know is bad. It's bad for extensibility, it's bad for collaboration. So yeah, in my day-to-day, you know, this is this is how MBC comes into play. It's mainly thinking about, okay, so what is really model code and what should really be on the model? And you know, this is a small example, of course, but over time and with lots of code, it really has an impact how you think about these things. Um and that's all I have. Thank you so much, Tjango Khan.

Speaker 1: Uh you can you can find me on the internet in various places if you like. Uh come talk to me if you have any opinions, hot takes, lukewarm takes on MVC. I'm interested to hear uh what you think in in the context of Django as well. And also there's the Discord channel uh which I will figure out how exactly it works, but you can uh ask questions there as well.

Speaker 2: Yeah, thank you very much, Nick. We have a few minutes for questions right now. If there are any questions right now, please line up at either this microphone. or this microphone or if you can't get out of your seat raise your hand and the microphone will be passed on to you. Yes, Markus.

Speaker 3: Thanks. intro to the history of MVC I guess. Um where do you see model managers as part of the MVC framework or MVC construct? concept

Speaker 1: model managers as in Django manager objects. Um yeah that's a good question. So I would just broadly consider them a part of the model, right? So model managers and Django are a way to give a bit more structure to your model code. It's a way to make sure you have chainable query sets and so on. And so query sets for me or custom query sets would also be a part of the model, I would say.

Speaker 2: Okay, next question from the left or right from your side.

Speaker 4: Um thank you for the talk. I thought that I thought that was very interesting. Um and uh in a similar line as Marcus asked, where would you in Django consider forms because they are kind of very separate and different from other frameworks.

Speaker 1: Yeah, that's a really good question. I think my problem is I actually haven't you actively used forms in literally years. And I guess I would question how much they are in active use in the Django community overall. I d I don't know. I I honestly don't know. I think it it's it's a case where there's a little bit of it could be somewhere between the view and the controller, I would say. I mean it's it it has aspects of both, I think. And yeah, I think that's okay

Speaker 2: Okay, there's another question here at the microphone.

Speaker 5: Yeah, I was wondering like uh Django Rest framework uh then comment

Speaker 1: Yeah, so this is actually a really good question and I did have originally a slide on this and then I realized I don't really have enough time to go into it too much. So yeah, the reality is a lot of us use Django as a backend, right? We we create API backends with it. So where is the user interaction in that Um so when it comes to Django RESTFork specifically, what I would say you can kind of look at a serializer in Django REST framework as part of the view. So you clearly still have the Django model layer in DRF And then you have serializers that represent the view in MVC, and you have um the DRF views that correspond again to the controller in MVC. I think that's how I would look at it.

Speaker 2: Okay, um we're gonna take one last question and then we're gonna go on to the next session.

Speaker 6: Okay, hello, thank you very much. Uh I wanted to ask you how do you account for prefecturalities and select related uh with regard to put it in the view file or model file.

Speaker 1: Sorry, I didn't I didn't understand acoustically.

Speaker 6: Select related?

Speaker 1: Or prefetch related and select related? Honestly that's a really good question, um, because I mean all of you who've used Django a lot. know that this is like a hard problem. Like how do you make it so that you reduce the n plus one problem in in SQL queries? And it's it's a place where the abstraction breaks down, frankly. So I am not aware of a good solution to the select radar prefetch related problems. I mean there's auto prefetch, if you're familiar with that, which works to some extent. But the abstraction somehow between SQL so it's an it's an abstraction in the object arrangement model that kind of breaks down. So I I don't have a good answer to that. I think it's a hard problem.

Speaker 2: Okay, and as Nick has already said, there is a Discord channel. If you come up with questions later, I'm sure you can also ask Nick in person later on. And um please have another round of applause for Nick.

Speaker 1: Thank you so much.