Thank you! Really, really, really well done! -- well worth the wait! The level of skill in condensing all these relatively "involved" topics into a single twenty-or-so minute video is a noteworthy feat in itself.
From what I understand, the MVC architecture was meant to be used on a small scale, so there would be a M-V-C for a button, or at worst, for a single form, another MVC for a dialog box, etc. Normally, you would not have a single Model, View, and Controller for the entire application. I guess we'd have to ask Trygve about it :)
I think there have been multiple interpretations of MVC (and most things in the computer world for that matter) and applying it to a very small thing or a small app or even a large app which happens to have a very simple structure is still good. The overly OOPy attempt to connect everything together object-to-object is just a good idea over-done.
This is a great video! One question that comes to mind about MVC is that as per the MVC architecture the when the controller updates the model, the model should notify the view that the object changed. The way this is set up seems like the controller notifying the view through the update_task_list method. The model should have a reference to the view or use the observer pattern to notify the view.
Thanks a lot for this video! This one comes in really good timing, I am currently in the process of deciding what framework and architecture we will use for a GUI app
Thanks for the great video. Specially the final point which was: "Separate Things". I'd just add some sprinkles of patterns here and there such as: - Data Binding is sometimes done with an implementation of the "Observer Pattern" (Is it "sometimes" or always? I'm not sure!) - Make sure your "model" also separates the "data layer" and the "logic" layer. - A good starting point for the logic layer's design is the "Command Pattern". (Imagine if you want to implement "undo" for your app) - One good pattern for the data layer is the repository pattern and it is also concerned with your ORM of choice (which I hear is falling out of favor with people these days!) One good way of thinking about separation is "Can I unplug this layer, and plug in a different implementation of this layer without changing other layers?" For example, can I change the view of my Todo App to a CLI? If your MV?? is written cleanly, you should be able to have a CLI up, and also a GUI up on the same backend, with no problem. This could actually be a fun exercise... hmmm... For one thing, your observer pattern impl should be strong, imagine your CLI deletes a task, and your GUI should be updated automagically!
I like your enthusiasm about architecture, but I have to disagree with your point on "abstracting to allow for plugging in a CLI instead of the UI". It's never a good idea to overengineer. If there's no user need to add the abstraction, then don't put the damn code in. Also it's really hard to reason about an abstraction of two things when one of them doesn't exist yet. You'll inevitably end up with some completely wrong abstraction that's going to stand in your way due to unnecessary coupling once you'll need to make a change. This will screw up your productivity. Honestly, the best advice I can give is that you don't overengineer for hypothetical cases. Just keep your code flexible such that it'll be easy to put the code in once it's actually needed. Don't repeat the same design misstakes over and over again 😅😅😅
I think with nearly any GUI app, if it becomes really useful, then somebody will want to automate tasks with it. This is a good argument for separating the GUI frontend from the backend engine. So then you can invoke the backend via some kind of script or CLI, independent of the GUI. In fact, you could start your new app by writing it as CLI-only, and adding a GUI later.
@@lawrencedoliveiro9104 Why do you write GUIs for stuff that can be entitely automated? Makes no sense at all 😄 And yeah, if you keep the code clear and simple, you can easily copy the stuff that does the logic and separate it lateron to launch it from your script. Well designed code is flexible and can be taken apart. It doesn't always require patterns to achieve something. In fact, patterns constrain your possibilities 🤔😉
I have found GUI programming one of the most difficult to do "properly" (i.e. have the feeling of doing things more or less "right"). How do these concepts scale to more complicated GUIs? Does each "thing" have its own model, view and controller? What architecture would you go for if you wanted to support multiple GUI frameworks (GTK, Qt, curses, ....)
You use as many models as you need to represent all the kinds of data used in your application, and then reuse those models wherever that kind of data is needed. That could definitely be in many different parts of the UI. It'd be less common to reuse a controller, but there may be some circumstances - e.g. an 'easy' simplified UI flow versus a fully configurable UI flow might use the same controller because they're achieving the same thing.
I started my career back in the early Apple Macintosh days. Back then, there was this document called the “User Interface Guidelines”, which carefully spelled out concepts like “interface stability” and “progressive disclosure” and feedback to confirm user actions. We were taught to care about actual user-interface testing, rather than just assuming that what we were doing would be “intuitive” to the user. But increasingly, I found that app vendors didn’t bother following these rules. And even Apple itself seemed to be moving away from them. Nowadays, it all seems to be about looks and following fashionable “design trends”. Hence the move away from the “3D” look to the “flat” look, which may be going back to “3D” now. Or what about this “dark theme” fad? What happened to usability testing? Seems nobody even bothers with that any more.
Agreed, my intuition is telling me that decoupling from MVVM is good but its so completely awful to do. It does make it a bit easier to separate tasks between different teams though. So far as i am learning, its just taking forever to get it into intuition. I wish there was an easier way to learn this. But it really feels like i gotta just make a bunch of apps before comfort even becomes an option.
Next video about Layers? You could go into dependencies and keeping a check on which layer depends on which layer(s), how many layers you could theoretically have and what the typical style is. I think Software Architecture beyond explaining MVC is needed :)
Hi Arjan, can we get a similar video about backend architecture, if one doesn't exist already? It would be almost the same probably, except instead of a UI you're dealing with things like API endpoints, HTTP requests etc. To be honest GUI development in general and especially desktop GUI seem like a nightmare to me lol.
20:40 - "I hate XML" This is where the Dutch are renowned for: the directness and the "no-nonsense"-attitude. Maybe it is just part of the "design principles" or "architecture" of the dutch😜 And I - as a dutch guy myself - are proud of it! It is a very effective way of teaching stuff imo. So I am happy that Arjan also keeps this no-nonsense principle in his videos!
Your videos are great, but I downloaded the design guide and it must be a joke. It's not a guide. It's a couple of pages of your course advertisement ;)
Great video! It would be nice though if you could slow down a bit when giving an explanation and elaborate a bit more on why some things are done. People who just started learning these concepts would benefit from that approach, and I suspect more viewers of your channel are those who are trying to understand those topics and not just review them.
In MVC, the view is not supposed to knowledge about the model. Normally, the data from the model is passed as an enumerated object, so that the view is unable to modify the data. Any request to change data from the view should be passed back into the control as an end point action that will then prompt the controller to tell the model to update with the new values.
@@josephvictory9536 very similar process. There is a whole family of abstractions that do essentially the same thing. For MVVM the view will push back to the server and the server will decide what models need to be used to create an updated view model and push it back to the view. In a lot of ways the most powerful I have found is MVP which looks like a play on acronyms but is just a coincidence. MVP is model view presenter. The main gist is that there is a presentation layer that encapsulates all the controller and adapter functions and presents Views with data. Behind the scenes the Presenter is accessing all the models to then aggregate the necessary data to present. The Models are all backend functions and never get close to any view. Since you mentioned the MVVM you might want to look into HVVM which switches out the Model for a Handler. The difference is that now the Handler can be any source where as Model in MVVM usually has direct access to the source data. The use of HVVM will abstract away one layer, so if you have an application and you want both a desktop and web version(possible even a phone app) now you can switch the handler more readily to the correct API. All these patterns making it easier to unit test properly and you can mix and match most of them according to need. Pick the one best suited for you application and you can wrap your head around the most and it will be all good. Having no plan or not using any of these patterns is a terrible idea.
all 3 are a design principle to abstract the business concerns of applications into logical units. My boots on the ground opinion after 44 years. There is more effort put into trying to absolve a programmer of accountability with design philosophy than writing good code. New programmers are just going to write shitty code because they are inexperienced. That's why you put them on small trivial things until they acquire that experience. Back to MVVM, MVP, MVC.... At the level that these 3 "things" become useful your not dealing with a few business systems but 25. It doesn't solve the complexity problem and at that point it really doesn't even provide organization. every single religious programming practice doesn't change the fact that shoe horning code into a mould doesn't solve problems but creates them. Sure you can google some trivial implementation but when you scale it up. Your left wondering how you did it wrong when you followed the best practices. Or you think it just feels wrong. Or experience tells you it is going to be cluster fuck down the road. You were sold promises not guarantees by guys selling books/conferences who are vested into their own success not yours. If the whole thing collapses... they still have your 50 bucks for the book and the 500 for the conference.
Where should the responsibility be to check if input is valid? To clarify my question, let's take your example and say you want to disallow adding a task that already exists. What is the proper way to do it? I see two very distinct options: - Should the controller/presenter check if the task already exists? - Should the model check if adding the task is possible and throw an exception of that's not the case? (Which the controller/presenter catches) I can make a case for either, but maybe I'm missing a third option. Would love to hear an expert opinion on this!
Great question because it seems to overlap both the View and the Controller. It's quite common. I think where those meet is at the junction of the Controller (of app logic) and the Model (a human construct representing ideas and implementation of things with data). Which is best? After the Controller checks the data you're updating the model or after the Model checks the data the Model is updated. If the checking has to do with the "business logic" (is the value valid for a purchase or interest rate or pressure level) then it probably belongs in the Controller, but if it's a presentation issue or if the values are in the proper form for the model to store, then it would belong in the Model area.
I've not seen MVP before... I shall have to look into that some more - it might "calm down" my obsession with MVVM. MVVM really comes into it's own when creating web APIs. I've recently been working on an Android App... Nothing like working with the JVM to remind me that, like you.... I hate XML! ;)
I am so happy that "m not a developer anymore. The endless discussions about what's the best structure, from the pointless debates, the "but this is faster" and "but this is cleaner" poop to the "but doing it ourselves is more fun" nonsense. What has worked best for me in the end is : Use a framework. Check them all out, choose the one that makes most sense to you and use it. Yes there will be a hundred people who will tell you it's the worst framework in the world but those people exist for every framework so it's void. What you don't want to do is build your own stuff because you end up building a framework. Building a framework is a great way to learn the hard was exactly how difficult that is and how much you should not ever want do that unless it's a customer paying you endless amounts of money. Whatever framework you build will never be finished, every three months you will find a better way of doing things (either because you saw it in a framework somewhere or because your requirements changed) and you will have to re-write huge amounts of code to incorporate the changes. One thing that is of great importance is: whatever you chose to do: be consistent. Once you go MVC, try to make eveything MVC or split your code into application and libraries. Don't mix architectures because it will be the death of your project.
Great content as usual. Just quick quesiton; at 10:23, why did we remove the direct dependency and use protocols? woundn't importing the actual class work just fine?
In MVVM, the ViewModel should not know about the View or any view technology. And you could write the bindings manually outside of the ViewModel instead. That is how you would do it in frameworks that lack built in data binding support.
Great video. I have been mostly backend developing and this is a great introsuction to frontend arhitecture. I cant wait to find a new project where I can use it.
In MVC, the View inherits from Model, that's ok? I saw every have to be independet (view and model) an its the controller who binds both. For example, i using DASH for my apps. Can i use data from de model for make the view(html)? Or i have to pass the data as a @callback for do it (in this case, is the controller who say: theres a update for a view from the model) (sry for me engish)
Remember. If you're using MVVM everthing is going to be amazing. Is what juniors believe. Me included. Though i grew past it. Now i what the saying "All code is shit" is true. Because there is no right answer. Only compromises.
Thanks for another great video. It's a pity that in the MVVM example you left out the real database. It would be instructive to see how to save the data to the database.
TLDR: - Model-View-Controller (MVC) separates the application into 3 parts: the model, which represents the data and logic, the view, which represents the user interface, and the controller, which manages user input and interacts with the model and view. - Model-View-Presenter (MVP) is similar to MVC, but shifts more of the responsibility from the controller to the presenter, which acts as a mediator between the view and model. - Model-View-ViewModel (MVVM) is a variation of MVP that uses data binding to automatically update the view when the underlying data changes. - Django's architecture is referred to as an MTV architecture, where the view delegates to a template for presentation and the framework serves as the controller. The exact architecture to use in a particular situation is not rigid and depends on the platform, the project, and personal preference. The most important thing is to separate concerns and avoid creating one large, tightly-coupled God class.
I used it in a project recently and I was very happy with it. Lots of "cookbook" examples on the site, and it was easy to get up and running. Apparently it can use tkinter or Qt, so that's pretty sweet - we used tkinter
Thank you very much for this ! Could we have an example on how to split a big project into smaller ViewModels with MVVM and how ViewModels should communicate with each other?
I use MVC slightly differently but it works for me; Models publish events to one or more views via some abstraction i.e EventBus or interfaces. Controllers get a reference to the appropriate model class in their constructor and call functions on the model directly. The model can publish events to notify views of changes whenever needed - there is no need to couple the controller to the view.
Great video but you should not have included the database in the first comparison. It had nothing with the topic to do and just complicated the comparison with the all-in-one-file solution.
It's very common, but more important for this video, it's a very handy thing to have a Model (what the programmer creates to represent the real world stuff). Then he can show how it is used next too the View and Controller.
I’ve always used MVVM. It’s very similar to MVP. A common binding library for web dev today would be React, but nearly all web dev frameworks are just complicated binding protocols: Backbone, KnockoutJS, AngularJS, Angular 2, Angular what-ever-it-is-now, Ember, Dojo.
Hi Arjan, Thanks for the video. I've been doing quite a bit of work using Pyside6 - the official Qt Library for Python. You can actually execute a script in Qt Designer to generate a Python file for the GUI - frees you from using the Ui File I've put together a quick MVVM example using Pyside6 in response to your video. What's the best way for me to pass you the Github Repo? Including it in the youtube comments results in the message being deleted.
I would like to add that PySide and PyQT are not the same thing. PyQT requires a license to be used for commercial products. PySide is LGPL, so you may use it for commercial products as long as you can provide the requirements of that license. Also using uic is pretty bad imho. Using a boilerplate is much better, since you can use the built-in functions of Qt to translate the UI files in a class representation. gmarull/pyside2-boilerplate is a nice starting point.
To be fair, I've always seen the traditional MVC pattern as a little bit too coupled, and have implemented MVP pretty much always, without calling it that. It gets tedious if you do a lot of component nesting though. Depending on how you set it up, it can be quite frustrating at times. Having to bind things 3-4 layers deep would require you to write pass forward functions and that bothers me for some reason. I feel like there should be a better way to do it, but there isn't really, if we want to keep things decoupled.
Hi @ArjanCodes Could you please make video explaining builder pattern? I tried to understand from different sources and through UML found it very confusing.
Seeing PyQt being used raises the question if there is any way to get a proper type (hint) IDE support for class attributes, like delete_button or todo_edit object. Neither using inheritance from a py file created by PyQt, nor using the uic.loadUi will make the IDE recognize all existing attributes. I am asking this because I work a lot with huge PyQt apps initialized from UI files, and the IDE not knowing the objects and attributes makes writing code more prone to typos and other errors. Up to now, I did not find a good workaround, other than writing all PyQt code myself, which is not an option when using UI files being in the multiple (ten) thousands of lines long.
In pyside, you can use pyside-uic which converts the XML attributes to a class representation. I don't know if pyqt has the same interface, but it should. If you want to give it a go, I would suggest to start from gmarull/pyside2-boilerplate
@@Sclafus In PyQt, there is pyuic5/pyuic6 which kinda does the same, so converting to a Python class file. The class however does not got the attributes on init, but as a setupUi method, so the IDE does not provide name support or Auto completion during coding. I guess that’s the death you have to die using Qt files. It’s not that bad, but sometimes you may misspell a word.
Well, I DO hate using uic like this though :D I think it does create pretty much the same code as if you let it write to a .py file JUST in memory. (your IDE never has the chance to get you code completion on the widgets) (or is there something that mangles that out of the xml?) However: This generated code probably also contains sth like "QMetaObject.connectSlotsByName(PARENT)" which DOES do automatic widget-signal-slot binding to accordingly name and "QtCoreSlot()" decorated methods.
some frameworks enforce these, but other than that I think trying to enforce these over complicates things. I think SOC is the best, just simple separation of concerns, and you may find yourself doing some of these patterns accidentally when you simply do SOC.
Ruby on Rails is the perfect example of MVC. People may argue in articles about what MVC means, but Rails has proven benefits of MVC with their approach and refined it over years so one could even say that Rails kinda defines the MVC standard.
Great video. Any guidance on how you might combine the 3 different components (I.e. M+V+C), with the idea of having separate files, on a class by class basis?
@ArjanCodes Do you have any tips on how to handle opening an extra window for example for a progress bar with the MVP architecture? Would you create an extra view and pass that on to the presenter?
MVC is best when you don't need a view-model so it works best with both GUI and non-GUI (REST API etc.) MVVM works best when you need a view-model and a change notification system that automatically wires up the events neede to update the GUI. All in all, if you look at why these architectures were created, you will find their best fits. So, choose based on that.
I don't think it's bad but you have to understand what you are doing. There is a good chance that this behavior will become part of a future release of python but there is also a risk that the behavior will change... I think mCoding did a video on __future__ which xas really interesting
After weeks of reading articles and books, this video ultimately showed me that these architectures are just tools. They aren't clearly defined, and they shouldn't be, because no application is a 100% fit. But from my experience I enjoy working with MVC in web apps, and MVP for native apps. I never used MVVM but I will have to try it with WPF some time. Thank you for making this video, it is very high quality and I love the examples you provide.
It would be nice to make parts of the plumbing more declarative. For example, I share Arjan’s distaste for carrying around large amounts of XML. Why not define a Pythonic representation for that XML info? This is what I did in DBussy, my pure-Python wrapper for libdbus.
@@lawrencedoliveiro9104 Thanks for sharing this. Shall take a look at your project at some point, it sounds very interesting. I've been "playing around" with DBus lately via Python bindings.
Thank you so so so much! I swear its been months now since I'm looking for a clear explanation about the difference between the 3, browsing the Internet without finding clear examples. I finally understand the difference, and I'd like to thank you for this!
XML is the worst dogma introduced in the software discipline in the last 20 years. It is neither human-friendly nor computer-friendly. It is ugly in a way that I never thought simple ASCII characters could be. It is overweight in its syntax and led to code editors becoming overweight with additional code-completion plug-ins.
Using MVC, you passed the view and model into the controller. On some websites I saw that they passed a controller and model into the view and model into the controlller. Are both approaches correcct? Or which one is the proper MVC? Thanks a lot.
@MacGuenther by "passing" I literally meant passing them as an argument for class initialisation (sorry I am a newbie in python). However, I believe your cases A) and B) described exactly what I was trying to say but in more civilised language. I use pyQt for my program. By user input actions in the VIEW, the CONTROLLER does "a computation" and modifiy the data inside the MODEL and then using signals and slots the MODEL directly send results into the view. To do that, my VIEW has to have access to the MODEL and CONTROLLER which corresponds to your case B) and my "passing model and controller as a parameter". Since I am still learning all of that, I am glad that my approach is not totally wrong. Thank you for your reply.
@MacGuenther Thanks, I am basically learning python by building a software representing hydrological simulation model which I am developing as well. The first version was a spaghetti mess but then I learned about design patterns and MVC. This channel helped me a lot by introducing to me dataclasses, protocols, abstract classes and other stuff.
@@khangnguyen96 the presentation patterns live only in the "presentation" layer of an architecture, the application and business logic have nothing to do with those presentation patterns. I would strongly advice you to read the book Clean Architecture by Robert Martin. It will totally change the way you code.
There are as many ways to skin the proverbial cat as there are coders. Only advice I can give to anyone in software development is "know your languages." as in which is best and how to get the best from each one. Possibly also "the framework is a lie" given recent, immature philosophies in coding. One last thing I HAVE to say that renders all other lessons null and void - COMMENTS?? O_o
This is good, but in the MVP example, you have the Presenter class defined in two separate files. This doesn't make sense to me, and looks like a code smell. If you're using a class more than once, why is it not defined in 1 file and imported twice?
It’s defined in one file, but what I’m doing in the example is use a Protocol class to locally define the interface of what a presenter object should look like. So it’s not a code smell, but a way to provide abstraction between the different components of the architecture.
I'm sure there's a simple answer (like: "python -m pip install Missing_module_name") but I suggest a a detour right now to learn `pyenv`. You will have to learn pyenv anyways (IMO) to get far at this. Ideally you create 1 .pyenv environment for every project/tutorial you work on.
Sir please i make a video on how to import a module from a package into another pack. For example using this our tutorial because i can see you have root folder containing sub folders.
Going by the thumbnail, if you dont even follow the simple business logic of what happened with Twitter, then I probably wouldnt trust you to advise on what software tools to use. 💁🏻♂️
The more I view this video the more I think you are just showing off. It is clear to me you have knowlegde of the topic but this is just about as much as I get from this video. It is rushed and feels like blubber jabber to someone who just discovered concept of mvc. I think I’d benefit more from studying this code itself rather then listening to your brief and confusing explanation. Please keep in mind that most people visiting your channel are just trying to learn and understand these topics. You don’t have to impress us with how fast you speak and type. Just present the material in a clear and digestible fashion. If this was a sofware design you would use “separation of concerns” to develop and make the best use of different part of the program. Why don’t you have the same approach when creating videos…?
Why bog yourself down with terms like MVC, MVP, or MVVM? Just use React or Angular and think in terms of microservices, templates, components, and services. Simplify instead of using 20-year old concepts.
(I dare to provoke 🙂) Should we abandon CPUs, RAMs, monitors and some other stuff, too, 'cause those are also 20+ year old concepts?! What about milk and bread? ;-)
