The story of how the MVC Pattern Was Developed

Speaker 1: Minutes, I'll pass the mic to you.

Speaker 2: Thank you so much. Um , So I would like to welcome you to my talk, Mega Very Cool, the story of how the Model View Controller pattern was developed. And um I think the the keyword here is uh story because I'll I'll be talking much more about kind of um Yeah, how how how it came about and um and thoughts about very kind of like um overarching um thoughts and questions about patterns and uh architectural questions um more than going in depth and showing you slides with codes code

Speaker 2: on it So uh first a little bit about myself. Um I yeah, I live here in Copenhagen and I've been uh an active member in a bunch of communities and um Some of them you'll you'll see here. So I'm very much like a community person. I think that's why I'm I was really happy to be invited to this conference because I, although I haven't been very active with jingle or even work with it so very much. Um I really kind of love the community uh that you have and I I really think it's it's really attractive uh for me to like be friends with you and I really kind of it makes me want to

Speaker 2: it makes me want to go to this conference and it makes me want to um see all the things I can learn and already like the couple of talks uh I saw today I learned so much that is like directly applicable for me. But yeah, so I've been a member of these communities and Some of them have been about um getting newcomers into the the field of programming. um very much with a with a sort of a bent on people who are not so much represented already. So I could name like some some of the communities are about. getting more women and non-binary people interested in coding and

Speaker 2: um motivated to to stay in the in the field and s and one of them is called Hackie Future, which is a coding school where um where they teach um refugees and uh migrants to Denmark to to learn how to code which is a non-profit organization that is entirely um uh reliant on getting um money uh to to run because it's uh it doesn't charge um the people who come and learn. Um and that actually kind of Maybe uh led to the job I currently have. I work as a React developer for a company called Grant Compass. And this is a platform for the private foundations in Denmark

Speaker 2: that help them run. And it's these final foundations that fund uh NGOs, nonprofits, and um culture and the arts and sustainability and many other really good things. So That's been sort of a really great fit with all these other things I've been doing for a couple of years in my spare time. So , I'll organize my talk around a couple of questions today. And those questions are, what are design patterns? What is the MBC pattern? How did it come about? Where do we go from here? And Those are all enormously big questions

Speaker 2: and my talk is slotted for 25 minutes So I'm going to loosely kind of organize these thoughts that I had for this talk around these questions , but I'll in no way like um you know, uh cover everything there is to cover on these topics. Before we dive into talking about the Model View controller, I thought it would be nice to just briefly talk about what Design patterns are because this is not something that I mean maybe some of you, but uh it's not something I think about every day as a developer. Uh so I thought it was like helpful to kind of just uh cover

Speaker 2: that. I can tell you what it's not software design pattern should not be confused with software pattern design, which you see this image is showing an example of. Um so that's like software that helps you, for example, make a yellow shirt. Um so so that's that's the wrong Google search. Um So I got really excited when I stumbled over like I did in my research for this, I stumbled over this book from 2004, and it's a primer on design patterns in software architecture. And I have to admit that I really liked this super cheesy cover and this amazing aesthetic and I was very feeling very inspired by it.

Speaker 2: So as a matter of fact, I took I sort of like took this like um early two thousands um mean girl um aesthetic and applied it to my entire um uh talk. So because because I thought like first of all because actually I I started reading this book and I kind of really liked it. And then um secondly also because I think that one thing I came across um was um the head this sort of bin um a heyday for um talking about um the MBC pattern and that that is that is exactly this this period of time where it was like very very much a big thing.

Speaker 2: So and yeah, I just think it's lovely. It's clearly uh before the O'Reilly started with their cool animal covers, which I also love, but this is just it's it has some qualities I think Um it does this book does feel quite dated because it's about Java and um yeah, because a lot of a lot of things happened since two 2004. But I was attracted to it because it has these delightfully kitschy illustrations and also it's made by um two men and two women and most of the illustrations have women on it and uh it just has a lot of like really wacky cartoons and it's it's overall I'm telling you it's a good book. So um here the female protagonist of one of the chapters finds herself asking, wouldn't it be dreamy

Speaker 2: if there were a way to build software so that we need to change it? we could do so with the least possible impact on the existing code. We could spend less time reworking code and more time making the program do cooler things. And these are actually questions that bring us closer to the definition of software design patterns. I think So, in software engineering, a software design pattern, you can say it's a general, reusable solution to a commonly occurring problem with a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it's a description or template for how to solve a problem that can

Speaker 2: be used in many different situations. And finally, design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or a system. So, what is the MDC pattern and how did it come about? Yeah, so these are like, I would say these are the two questions that I like um chose to organize my thoughts about this talk loosely around. Before I go into the MVC, I think I wanted to just clear up a few things. So my background is actually in Rails, and that's

Speaker 2: That's how I was introduced to and have worked with the Model View Controller pattern exclusively. It's through Rails applications. And I am aware that uh Django has something called the Model View Template MBT, which is slightly different than the MVC. In fact, the main difference between these two patterns is that Django itself takes care of the controller part And then leaving us with a template, and the template is an HTML file that's mixed with Django template language. So I'm aware. But I'm as I said in the beginning, I'm really happy to

Speaker 2: mix up the communities, and I'm happy you want to have me. Yeah, this this is a still from a very important YouTube uh video called Ruby on Rails versus Tingo. And if you haven't seen it, um you really need to. Um and if I had enough time I would play it for you. But it's basically about beef between uh Rails and uh Django communities. But I think it's time we put that past. So back to MBC So, once upon a time in the 1970s, to be precise, mixing responsibilities was the common practice, and people were still trying to discover how to do it better.

Speaker 2: So try to imagine that you had these complex systems where code was just mixed and matched and all jumble up together. As the application complexity grew , making changes to the UI would be would inevitably imply changes to the business logic as well, increasing the complexity of the changes, the time spent to do those changes, and the likelihood of bugs. Because there would be so much more code that you needed to change. So the NBC came into play to solve these problems by promoting a separation of concerns between front-end and back end. And I think this is this separation of concern is like a sort of a key

Speaker 2: concept here and something that I keep kind of coming back to when I look at why the NBC pattern was so popularized and what people loved so much about it So I think like the way that I've like I was introduced to it um as as uh like early early career um developer was sort of like through these like myriads of uh graphics. That's like what I remember the most. And they all roughly kind of like show the same thing. You have the model. And the model defines what data the app should contain If the state of the data changes, then the model will usually notify the view, so the display can change as needed.

Speaker 2: And sometimes the controller, if different logic is needed to control the updated view, You have the view. This defines how the app 's data should be displayed. And finally you have the controller that contains logic that updates the model. But it can also view in response to input from the user of the app. So if I should sum up what in my mind makes the MBC pattern what it is. You can say it's a pattern in software at this time, commonly used to implement user interfaces, data and controller logic. It emphasizes a separation between the software's business, logic, and display. And this separation of concerns provide for a better division of labor and provides

Speaker 2: improved maintenance. So again, it's like I think it's very much this kind of the separation of of concerns that that is was one of the biggest things. And I think it's been really interesting for me to kind of, you know, in order to do this talk, to kind of think a little bit deeper about this because it's only very recently that I Started thinking about these qualities because I moved away from Rails , which was what I had spent like until last year, spent all of my career working on So the MVC was invented in the 1970s

Speaker 2: by a couple of people. And I was really fascinated to find out that it's It's um its invention is sort of tangled up in this product that I found really um delightful. It's called DynaBook. Um and it's um It's a mini computer that was like s sadly it was never really um mass produced. Um but it was sort of like invented as like a it it looks like a little iPad and it was uh meant as a lightweight computer for children. And it was invented by someone named Ellen Kaye, and he was working on this with a group of other people. in um

Speaker 2: Cirox Park. And at the same time, like they they they were kind of working on this with this idea to yeah to build these mini computers for children that were lightweight. And then Um the software comp part of that was um was yeah, like they were also alongside that developing this language called small talk. And Dynamook unfortunately never took off because they look incredibly cute. Um like maybe like a nicer version of an iPad But the software component of this research did go on to have a life of its own and um and became the language small talk. And Smalltalk was the first kind of language to introduce the Model

Speaker 2: View controller form. So um when I started looking into the story of the model review controller, I I I I I like I had to kind of like separate um all these different think pieces where people either praise or uh talk trash about um the pattern or patterns in general. And then also sort of the story of how it was came about. And I was interested in both, I guess. So Martin Fowler, he called the MVC one of the most ill-understood patterns in the software world.

Speaker 2: And I think that was kind of interesting to hear that and um and it became clear to me why he would say that when I looked into the story. Um why was it so ill understood? Um Could it be because the first paper that introduced it called it Thing Model View Editor, which is like an incredibly confusing uh title for something, Thing. So they did publish like a second paper where they cleared it up and introduced the controller like very fast after that, but like still this is super confusing. Another reason for this confusion could be that the pattern has actually had a lot of different reincarnations

Speaker 2: and has had so many changes over time And um what we see here is from 1979. Um Model View Controller where the model represents the business logic. The view represents a widget in the UI, like button and text box, etc. The controller provides for coordination between the view and the model, and this means that it decides what views to show and with what data and translates user actions into business logic. Then in 1996, something called Model ViewPresenter appeared that you see right here. The idea was to further isolate the model from the UI concerns. The view is passive and unaware of the model.

Speaker 2: There's a focus on thin controllers that contain no business logic and simply invokes commands or queries in the model, passing raw data to a view. A change in the data does not trigger an update and view directly. It always goes through the presenter. And there's a single presenter for each view. There's yeah. So after this there came something called model view view model. After this comes some came something called Model View Adapter, and so many more. I at some point like I wanted to kind of go through the iterations of this, and at some point I had to kind of stop and dial back for a minute because I think

Speaker 2: This this really kind of it became clear that like okay the model view controller has meant a lot of different things to a lot of different people at a lot of different times. And that's maybe one of the biggest takeaways from this doing this talk. And it also kind of made me feel a little, it kind of validated like this confusion I've always had about it. The the title I chose for this talk is sort of like tongue-in-cheek. Uh make it very cool. But it's also I I chose the title because I without kind of knowing why. I always really appreciated it, but I didn't know why I appreciated it. Um when I when I was doing

Speaker 2: um Yeah, when I was working on the talk, I I asked a lot of my friends what they thought about the Model View controller and uh software design patterns in general. And I think like 50-50, like half of them said I don't know anything about that, uh, and that makes me feel like I'm a dumb programmer. And then the other half of the people I asked said Oh, I don't like that. And um started explaining why they don't. And um And I think a lot of it kind of like boiled down to um to this sort of the prestige of kind of like I think like a lot of people basically have been bullied in job interviews where they are asked to kind of know all these different patterns and

Speaker 2: like some sort of like showboating around this topic. So yeah, I that was I think like I was unraveling when I did this presentation. I was unraveling. Like I I'm not the only one who has like This feeling of being confused about it. First of all, it's confusing. And second of all, it has evolved over time, and there's been so many stakeholders pushing it in different directions So where do you go from here? What's the current state of the Model View controller and where is it now? Um yeah, as I said, like I I think like a part of my understanding of of

Speaker 2: how people think about these things, it it it also came from looking at um how what what kind of discussions there's been about design patterns and something that came up a lot was this book that's from 1994 um and it's um commonly referred to as like um the group of four because it's four people wrote it And um it's yeah, it's uh it's sort of this Bible of with that has a lot of like really elaborate uh design patterns. It does not mention the model view controller pattern, but Um it's it's sort of something that that has has been something that you needed to to be in the know of for a while. Um but it be because it was so ubi ubiquitous

Speaker 2: um of a book, I think it also kind of um inspired like a backlash uh and uh I found this really funny. Um like Very very long thread on Twitter where someone who works for Google he 's saying like he's just the whole the whole thread is just like one big rant about how much he hates this book. And here he says, oh bridge, let me be absolutely clear here. Fuck the bridge pattern. It never actually solved any problems. And like, it's just like it's an incredibly like um a funny thread where he just one after one talks about how much he hates each and every pattern in the book. And I think it's it's um It's been really uh interesting to see like all these very uh uh strong feelings people have had about

Speaker 2: um about it. And myself I can say that I've been looking at it from the vantage point of having shifted to React, where it's like seemingly lifted out of this entire discourse entirely because most of the time it feels like React only has view uh uh or it's sort of this um sort of um anarchistic place where there are a lot of rules have that guided the MBC world have simp simply been um set aside. Um so I think like if I if I need to kind of um Collect these thoughts.

Speaker 2: I would um I would say that uh one thing I did learn was yeah, that that these patterns and how we think of them have changed a lot over time and that um My like one of the friends that I I talked to about it uh gave me like some really good ways of thinking about it, which is to think it of think of like what goes on in in our industry as being like cyclical so that everything is a reaction to something that came before. And so um you can have a moment in time where everyone wants to work on something that's very unrestricted and where you can kind of create everything exactly as you want it. And then there'll be like a counter reaction where people want

Speaker 2: a system where there's rules and there's like it's their structure and it's like very, very like you you cannot do the wrong thing. And I think um and I see like the like MBC pattern kind of going in and out of favor. I see that very much in in in this kind of um story that that like the counter-reaction could be yeah like something like React where like you can do anything you want but you can make such a bigness if you want that. Um so finally I know you were dying to to know uh how my wonderful book from 2004 would sum up uh all these things. Um and this is one of the great illustrations

Speaker 2: this woman she's thinking, I guess. It's a think bubble. She's thinking, remember, knowing concepts like abstraction, inheritance, and polymorphism does not make you a good object-oriented designer. A design guru thinks about how to create flexible designs that are maintainable and can cope with change So I think um these are sort of words I will leave you with and uh I'll say thank you so much

Speaker 1: Thank you so much. I have a question from myself, if I'm allowed to ask. Um I've been wondering what what is it called in the race? Um and what could we just call that? Okay.

Speaker 2: Because that's That's what I was uh familiarized with.

Speaker 1: Because yeah, it's uh often for uh familiar to Django people as model view template.

Speaker 2: Yeah.

Speaker 1: Which is like the same concept, just Um like you said in the beginning that you are active in in a lot of communities and I know It's also inclusive communities like our own where we wanna give people the right sort of entry points to get into. uh our technological tools and like is can we see a like a good um pedagogical method to getting people into thinking

Speaker 2: I thought so. I think I've so I've uh I've actually taught it at a lot of like real schools beginners workshops where like it's over the course of a weekend you take someone who never seen a terminal before and then you kind of make them pour things uh at the end like like make an entire um blog uh application and they're even like ending up like deploying it to Heroku and like people are very confused uh by that weekend when it's over but I've so I've actually like tried very like specific way to to to teach that to a lot of beginners uh who are very green and I think that it's actually good for that. Cool.

Speaker 1: It's a suggestion to yeah, also those of you tutoring Gecko that that this can be a really cool tool make it very cool to uh gain an an understanding before you dive headfirst into the code Um I have a question more for myself. Um A lot of people talk about front front and back end abstractions too and and does the MVC kind of land is it is it both the wish think MVC on back end uh and also on front end does it?

Speaker 2: Um I s that was like a topic where I saw like quite a lot of think pieces, like quite a lot of medium posts out there right now of people wanting to claim authority on this and like kind of push it in a certain direction. And one voice that I I saw represented was that people are saying that there's actually more of a separation now or like if you're fully backend backend developer that you don't have anything anymore to do with the view. So um like that this kind of gets pushed further further away if you're if you're um yeah so I think Yeah, I think there's so many different uh opinions about that. And uh it's it I think it also kind of ties in together with all these discussions we have about

Speaker 2: Um where does front end start and where does it end essentially? We

Speaker 1: have any questions from uh internet? The internet is silent. All right. Um let's keep uh Luna uh Kein Applaus, thank you.