Building Better Developers, Episode 537

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season where we are looking at architectural patterns and anti-patterns. We are subtly into a list of patterns and today we're going to look at model view controller or MVC. Now this is a pattern that is very common, particularly any of the frameworks out there that have a user interface piece to them. You will find MVC often the pattern that is used to implement that is also one that has been around for quite a while, has a large amount of documentation, examples, tutorials. It is more or less a staple of modern software development when you have a user interface involved. Now just in case you haven't been exposed to it or anything, let's talk about what model view controller is. In this pattern, there are three main components that you may have guessed that already. The model, the view and the controller. The view is the most, I think, obvious by its name. The view is the front end. This is the piece, this is the section of code that handles displaying information to the user. So they're viewing data, they're viewing information. The view code is what creates that for a user. The model is the data itself. The model is the, more or less the heart of the application. This is where data lives and where we do manipulations with it. The controller is how we take requests from a user and make changes in the model. And then that may, or maybe present, craft a specific type of view and present that to the user. So this is another of the patterns that sort of split up work in a certain way. We've talked on multiple patterns where we take the overall picture and we find ways to slice and dice it and allow it to be simplified to make things a little easier because we can do it in pieces, smaller pieces and tackle those as opposed to tackling the entire solution in one shot. MVC is really not so much focused on the let's take something complicated and do something and do it in smaller bytes so it's much more manageable. Instead, we're going to take the areas that, the areas of functionality and split them up so that we can have people that are more attuned or even specialist in that given area. Because I think in the modern world of software development, this is often very different skill sets. You have people on the front end, the view, that are doing things like Angular and React and HTML, JavaScript libraries, things of that nature. On the back end, it could be high or not necessarily high end, but very heavy usage of SQL, whether it's Oracle's PLSQL or Microsoft's TSQL or MySQL, MariaDB, whatever it is, it's a very different skill set. Also within that, maybe in the model or even in the controller, you may have some middle tier type of language such as like a Python or Java or C sharp or something like that where you have very different skill sets in each of these areas. This architecture allows you to embrace that and do the work in the language that is best suited for that type of work. Now, that is typically something we talk about on a overall project or solution level. When we've talked about languages in the past, and particularly the idea of having a wide, a broad skill set of languages and environments, is that it allows us to choose the best tool for the job. MVC is an architecture that makes that a little more, a little easier, a little less of a pain to try to take a square peg and round hole. So we don't need a single language to cover all three of these types of solutions. We can have actually a language for each solution area that is specific to that. Probably more importantly, this allows us to decouple the heart of the application, the model, from how we display it, the view, which is critical when you think of modern applications and how many different ways we deliver these things. It's not uncommon to have an application that has a web interface but separately has a mobile interface and possibly multiple mobile interfaces. You may have, even within your mobile, you may have specialization there. You may have iPhone related mobile device, phones and such, and maybe you have Android related devices. That's two different views right there. They may be very similar and you may be able to use something like React or Angular or something like that that allows you more or less to code once and deploy to different platforms. But you still have things like sizes of displays and even the complexity of the ability to interface with it. This sort of touches the controller as well. Think about the differences between a phone and a watch. You start getting into very different views. If you don't use the model view controller, then you quite possibly will have logic in the view or in your first view that you create that now you have to replicate in a new one and you have to maintain that in two different places. If it's logic around the application, then why not push that back into, in this case, the model or I guess from the navigation point, the controller piece. So this is a way for us to use the best tool at the right time and also to plan for expansion. Allow for the idea, which we see in N-tier and some of the other ways that we have, some of the other application architectures, software architectures that split things up that divide out based on some level of functionality or componentizing essentially the solution. It allows us to change one piece, one component and not impact the others or add new components, new ways that we can work with this, new things that we can work with without having to rewrite the entire code. So for the view, if you started out with, let's say a web application and then somewhere along the way you say, oh, now we're going to have to support a mobile device that you can try to just do the web on the mobile device. There's plenty of ways to skin this cat, but this may be something where you need some sort of native support on the device. Now you've got to build an actual view on that device, that mobile device. And if you did it right, the view related code for the web application is all that's in that web application. The model and the controller are consistent and doesn't matter what the view is. And it may not use everything in the controller or even the view. I'm sorry, or even the model. But now we've got something that we can build that's a specific view. You may see this and this sort of that last comment, you may see this in functionality of your application where you may not have actually a single all encompassing view type of approach to application. Maybe this is a, like let's say an enterprise level, like a web application, where you may have like, let's say an enterprise level solution of some sort, where we have, let's say HR functions and accounting functions and sales functions and invoicing functions and just a bunch of different silos almost within the application of functionality. You can have an application that only touches a specific view. You have a view that only touches specific piece, I guess a specific slice of the data. You could have a view that is reporting only. You could have a review that is only accounting data. And you see this sometimes in solutions that sort of do a security or permissions by application where you have access to certain applications and that, you know, if you don't have access to it, you don't have any of that functionality. Now you may also see this in, it's not as common, but you may see it in like a shareware type of approach where you have limited access. Definitely you can see this where you have add-ons at times where you have components that you can purchase. You have like a core of the application and then you can purchase add-ons that are maybe additional views or applications. Well, actually it would be the view application in this case. And that's just some of the ways that we can utilize this pattern to present quite a bit of different options to our users without, and with the idea of being able to expand on that in the future without having to go back and recode and retest, particularly the core application. And the bonus from that is it doesn't even affect everybody. All of those other views that are out there, since you don't change the model and you don't change the controller, when you add another view, if you totally botched that delivery, the only people affected are those that utilize that view. All of the other views are untouched. All of the other views are untouched. So if you've got a web application, you've got a huge set of users, you can go build a view that is the mobile application. You can expand out to that and say, here you go. Here's something that we're going to provide that's a mobile solution. And if you botch it and people say, oh, their mobile solution is horrible, go back to the web because it hasn't changed. And you also get to sort of, you give them something where, look, you didn't have it at all before. So if the new view is working functional, but maybe not what everybody would love to have, that's okay. Particularly if it's a feature incomplete or a partial feature release, you can say, hey, on a mobile device, you have these things you can do through this feature. You have these things you can do through this view, this mobile view. If you want to do these other pieces of functionality, you can always go back to the original view. And I've seen a lot of applications expand into new spaces with that, particularly in the world of watch applications. If you look at when a particularly Apple watch first came out, there's, you know, they're the included Apple applications. And then you saw this sort of launch push of applications that were going to be available on the watch and that were available. And for the most part, what you saw was limited functionality in that watch view compared to what you could do on your phone or, you know, like if they have a web application and particularly think of just even the Apple applications of functionality. You could see the phone ringing, but you still had to talk through your phone, I think, initially. And, you know, messages like that where you can see stuff, but you couldn't really type, you know, things like that, because that view is not very good to do typing on. So, you know, you can't really respond too much. So you've got limited functionality, but that's okay, because you have views that maybe do not make sense for that type of functionality. If you think of a word processing document application, it makes sense to be able to do that when you've got a desktop or a laptop, you know, full keyboard, nice view, stuff like that. If you're looking at it on a phone, it may not make as much sense or there's not as much need, at least, to write your entire document on your phone, because it's just not going to be as comfortable to write large documents. And if you've got to do a text message, it's one thing, even an email, maybe. If you're writing a book, you're probably not going to want to write it on, you know, on your phone. Definitely not on your watch or your intelligent eyewear or whatever the next thing is. So that's the MVC architecture. It addresses a couple of different desires and how we want to both implement, initially, our application, but also keeping an eye for future growth and expansion. And it's not terribly hard to work with. The key with, as with a lot of these, is just making sure that you are intentioned about where you put your code, making sure that the model type code lives in the model, the view-related code lives in the view, and the controller-related code lives in the code component, the controller component, and that you don't mix and match. Because once you do, then you're going to have issues when you try to build, you know, maybe move to a slightly different model or move to a different controller or move to a different view. And that's it for that one. So we will wrap this one up and we're going to come back next episode and we're going to continue looking at software architecture patterns. That being said, it's time for us to get out there. So go out there yourself and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. One more thing before you go, the Develop-a-Nor podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us be great, if you go out to developernor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe it'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.