Everything You NEED to Know About Client Architecture Patterns

[@editin232]

Amazing video for people that already understand what you're talking about.

[@FolkOverplay]

Nice collection of the different patterns. I appreciate short content but this was a little bit too short. It makes it very hard to understand the difference between the patterns. Especially MVC and MVP but it's hard to understand the difference between most of them.

[@hrishabhg]

The video should have given examples like what django follows, what react follows etc. in reverse way so we can connect better. Otherwise there is too much overlap based on definition itself.

[@MehranGhamaty]

Maybe I'll do that 🙂give me enough likes.

[@tonpo27]

Then you do it.

[@sapito169]

its always mvc some times they use data viding very comon in frontend javascript framework

[@MatthewRees7]

I think you're missing the point, these are just patterns. You can use any pattern with any of the frameworks, it's up to you to decide which is best for your scenario

[@suvetar]

About time I found a video that explains it properly, I've been coding for 35+ years now and have been following MVP/Viper style for quite some time, just I didn't know those patterns already had a name! Thanks for this my Dude!

[@ShreksSpliff]

Thank you for your time. I enjoy the videos and you're patience in them.

[@ivanshuba562]

Excellent! In my experience, nobody ever was able to explain this subject so clearly. Additional thanks for the diagram at the beginning of the video. It explains everything perfectly by itself.

[@hendrikmartina3552]

I was hours ago studying this topic. What a great timing!!! Thank you for covering this topic

[@SDFC]

It'd be nice to also cover the Observer pattern (which is the source of those "update" and "notify" words). In fact, the observer pattern was first used for implementing Smalltalk's MVC based user interface library. Or, also discuss one-way data binding (ReactJS) vs. two-way data binding (Angular) 🙂 You could even cover client-side frameworks (e.g. ReactJS, Angular) vs server-side frameworks (e.g. JSP, Laravel, Rails, NextJS) vs what Svelte is doing. Just some topic ideas for other shorts you could make 😁

[@KopoLPedov]

You're mixing different layers of abstraction.

[@SDFC]

I'm actually not. He commented on two-way data binding at 3:10, but glossed over it although it's a key distinction between Angular and ReactJS that you'd be acutely aware of if you've used them

[@PhilipAlexanderHassialis]

@@SDFC Yes but frontend's patterns (MVC/MVVM/etc) are bound within the confines of the browser activity. The MVC pattern holistically can be approached either on the server layer, or the front end layer or even the application as a whole (remember them "n-tier applications" of yore?). That being said, certain patterns cannot be - or shouldn't be used on the pure "backend" side, esp. if your backend side is a disparate different team/server-cluster. But as was already stated in the video, it's a matter of expertise and complexity. E.g. the project we are working now on my team has around, oh, 200 microservices, 2 different main client approaches (web/mobile), not to mention the internal infrastructural anchor points, all built across a consortium of some companies/dev-teams. A pure "MVP" or "MVVM" approach cannot be "fathomed" because simply.... it can't. The scope is too big.

[@gooseob]

​@@SDFC You have probably seen attributes like `value` and `setValue` passed to the component in React. It is the equivalent of two-way binding

[@SDFC]

@@gooseob No, that's actually explicitly demonstrating one-way data-binding. In two-way data-binding, you don't need "setValue" because the attribute named "value" is directly accessible for bi-directional reads -- _and writes_ Two-way data-binding behaves similarly to an instance variable marked as "public" in java. One-way data-binding is similar to adding a "setter" to wrap write access to an instance variable, and read access through ReactJS "props" is a bit reminiscent of constructor-based dependency injection for setting a private variable. This is actually _advantageous_ over two-way data binding because it's more conducive to the functional paradigm, via a clear point for extracting out business logic for input validation (which is similarly a common thing done in those "setter" functions in java) or translating the input into changes in other surrounding components. Here's a few links that may help with this, but it's explicitly stated that one-way data-binding is being used in the official ReactJS documentation and most things you'd find through a simple google search: - stackoverflow.com/questions/42217579/data-binding-in-react - softwareengineering.stackexchange.com/questions/419340/react-one-way-data-binding-vs-angular-two-way-data-binding - react.dev/learn/thinking-in-react The ReactJS creators like Dan Abramov are functional paradigm fanatics, btw. There's lots of great conference presentations and blog posts by them on the philosophy, rationale, and inspiration for a lot of the design decisions that they made, and I'd highly recommend checking it out. They're rather brilliant people, and their writings about what inspired their choices are a great means of finding content by even more brilliant people.

[@TimnewCNYN]

I think the video missed the most critical differences between these patterns: What is a View. Video mentioned in all these patterns, there is always the concept of View, and this is somehow treated as a common feature across these patterns. But to me, this is actually the no.1 differences between these patterns. For MVC, View is typically Model aware, and it typically extract data from model directly. So it typically requires a template engine to some kind of data binding mechanism to achieve that. Or it will lead to an even more bloated Controller in practise. In MVC, view is typically one off thing, Controller creates the view, update is typically done by recreate the view or rebound all the values again if the view isn't created by controller. MVC is typically used by http server, but also some UI frameworks, such as Cocoa/CocoaTouch (I would say Apple UI framework is more a MVC/MVP hybrid) MVP was created to reduced the Model View coupling, by introducing a dedicated Presenter in the middle, so the View can be completely decoupled from Model. And also Presenter can be used to not just creating the View but also used to update the View, when data changed, which allow a more granular control of the View. such as partial update. And View is kind of reused, and keep being updated. (Typically used by last gen UI framework, like Android or iOS, or WinForm is also kind of this type) MVP allow View to be provided by UI framework, and completely focused on rendering, and is business logic free. MVVM was introduced due to App is moving a bit more to the data driven way again. Like MVC, View in MVVM is again model aware and is capable for data binding. But data binding here is tends to be logic-less and lightweight, so it doesn't have or tend to not have the data projection capability. So the data projection logic to convert the raw data into presenting ready data is then hosted in ViewModel, and View is bound to ViewModel instead of Model. MVVM-C is just a variation of MVVM, a hybrid of MVVM to MVC, Coordinator is like the old Controller, oversees the lifecycle, navigation or other admin responsibilities. VIPER, I'm not sure this is a widely used term, but again it is just a MVVM variation, it has Router, pretty much a controller but more focused on navigation and lifecycle management. Presenter is similar to ViewModel is the View has data binding capability or become MVP presenter when View doesn't have data binding capability. Interactor is an action model that extract the business logic from the model (to avoid ActiveModel pattern, which is considered as anti-pattern by a certain group of people), and interactor allow to to involves more external resources rather than just model. Interactor has a more passive version which is typically called UseCase. So above all, per me, the major difference between MVC, MVP, MVVM is the caused by responsibility of View. MVC: View creation is relatively cheap, creating custom view is relatively cheap, so developer bind data to view by creating data aware custom views. user interaction on view is typically simple. Typically HTTP server. MVP: View is created and updated, and View is provided by UI framework, and user creating custom view is expensive, so developer write Presenter to bind data to view, and update the view when data changed. MVVM: Move to the data driven way, Update is done by UI Framework by tree diff, normally the View created here isn't the real render object. View is typically a layer of pseudo element. Mostly mordern UI framework, such as React, SwifUI, Jetpack Compose, Flutter. But also could be some old fashion framework, such as .net WPF....

[@mme725]

Nothing to add, just wanted to say thanks for the clarification 👏

[@donglu4390]

@@mme725 amazing clarification! thanks a lot!👍

[@VladimirMinkin]

There are different types of model - active (mvc) and passive (mvp), in these types view can't change data directly, but in mvvm view can, side effects also possible (adding c to equation).

[@LuckyFortunes-b3q]

MVVM is garbage because it should separate responsibilities not create a bunch of spagetti code. It's either the model or the view not both. MVVM violates KISS principle of keep it simple. Go ahead and throw what I said into AI and it will say I'm correct.

[@VladimirMinkin]

@@LuckyFortunes-b3q Ok, thanks for sharing your experience on the topic. My comment was about addition not a critics or anything like that. There are many different way of separating concerns and responsibilities of the entities in the system, not mentioned MVI and MVU, but the goal is the same - to make system easy to understand and then modify. I think that the best tool to make things work is the one you and your team know the best, in the essence.

[@funkykong9001]

I don't understand the difference between the MVC and the MVP. They seem identical...?

[@L.K.82]

That’s because they basically are the same. The downside of mvc (which according to the video is a bloated controller) is exactly the same for the second pattern. It just gets concealed by using a lot of cloudy words.

[@teeesen]

The difference is that in MVC, the View gets data from the model whereas in MVP the view gets data from the presenter. This allows the View to be even simpler and free of logic. The classic example is where the model is a temperature and you want high temperatures to be displayed in one way and low temperatures to be displayed in another. The model just delivers a number to the presenter, and the presenter makes the determination of whether the number is high or not, so it delivers the number along with a boolean to the view and the view uses the boolean to decide how to use the number. Suppose there are two views, one displays the number with say a red or blue background, the other either makes a sound or doesn’t. With MVC, both views would have to make the same decision about whether the temperature is high or the logic would have to be put in the model, even though it arguably not really “business logic”, but rather presentation logic. A more realistic example might be an text editor. Presentation state such as the current cursor position or selection will complicate the view, but probably doesn’t belong in the model. You could put it in the controller, but now your view needs to get information from two places.

[@codex8797]

Does anyone know what he uses for the animations?

[@faiyafxmedia2636]

This was a very good explanation video, thanks!

[@ilyakirbizhekov6324]

greatest videos so far.. my kids 7 years also understood

[@robottrainer]

MVVM, MVVM-C is standard for angular, react, vue frameworks. Keyword reactive programming/data-binding.

[@RicoGrof]

I think core of all is just Input Process Output. when pattern getting bigger we separate Process again into other Input Process Output. until we reach S (Single Responsibility) from SOLID.

[@troooooper100]

Summary: they are all the same... just different words... code need to update view, store data, and act on data. how you spread it or what you call doesn't matter.. No matter how complex your app is there are still 3 fundamental parts.

[@brukts3361]

I work in FAANG and I still have no clue what the differences are. For some reason, explanations never seem to provide code examples. I have a feeling the borders are blurry and it’s just not a very useful distinction

[@troooooper100]

@@brukts3361 I worked at faang as a FRONTEND engineer as well and these things are created to as marketing gimmicks by new frameworks. It's also part self promotion. Newbie eats it up, KZbinrs have more content and just a stupid cycle

[@amitpatkar]

@@brukts3361😊😊😊

[@skyhappy]

@@brukts3361 I was thinking the same thing,.without a working application's code, these are all just meaningless diagrams.

[@tomross4599]

I agree that it all depends on the implementation. That starts with the basic environment: Are we talking ReactWeb, iOS, Android? That choice alone might make one of the patterns built-in and some other pattern ridiculously hard to implement. The platform is the pattern. You’re just living in it.

[@maudjito]

How is MVP different from MVC? I got to this part of the video and don't feel like watching the rest when I already can't understand it clearly from the examples showed

[@bluesquare23]

Yeah this video is trying to point out some extremely subtle differences that are sorta not real. Tbh it's all MVC. You can think of your model as a table in a database. Your view's going to be an HTML page. And your controller is going to be some back end logic PHP or Nodejs or Python or whatever you're using. Newer web frameworks (front and backend) introduce slight differences. Like react has the virtual dom so to call it purely MVC is sorta not right cause the view isn't stateless anymore, it's reactive. So it isn't waiting there for an update from the controller about some part of the model like it would be for a plain old stateless http exchange.

[@drewwilson8756]

Simply beautiful as always.

[@RicardoSilva-hk2er]

This topic still confuses me a bit. I mean I kinda get it but without code, I don't actually think I understand the difference of MVC and MVP. Are you just transfering responsiblity of the frontend to the backend? Wouldn't that increase the problem of bloated controller? Also, is there any frameworks using MVVM or MVVM-C? How do we achieve this bidirectional data binding? VIPER, funny enough is very intuitive. I feel dumb after this question...

[@sapito169]

mvp always presenter is in the midle mvc dont use presenter in the midle XD martin fowler have code examples mvc is the same thing that all framework use all the times mvp example ProductManagmentPresent (presenter) JFrameProductManagment (view) ProductService(model) ProductManagmentPresent use JFrameProductManagment (view) and ProductService(model) and use interfaces and use events to cordinate

[@rogertunnell5764]

@@sapito169 Using the word Service in a model class is wild.

[@rogertunnell5764]

They're all garbage patterns that over simplify things into coinable and marketable terms so people can make $ writing stupid books, ahem videos, about them. Why you would ever want your backend coupled to your frontend is beyond me. BE - here's data, FE - cool you gave me data, let me transform that into what my users want. FE - I have a new use case that would require me to hit multiple endpoints and create unnecessary load on the backend, BE - cool, I'll create a new endpoint (or GraphQL resolver) that meets your use case. The problem w/ these "patterns" is that they try to encompass both BE & FE. VIPER makes great sense for FE, but still oversimplifies. Yes, you'll interact w/ an entity, but first you'll receive a DTO that needs to be transformed into an entity. An entity is a business object. Idk how that's ever conflated w/ a DTO. The JSON representation of an object can be vastly different than a business object. Business objects e.g. entities have behavior! Make VIPER -> VIPERD and then it's pretty accurate for FE only. Then you have BE which is DTOs, Use cases, Models, Business logic, Actors, Serde, Services, Entities and Security. You can read all about it in my new book, "DUMBASSES: The Next Generation of Software Engineering"

[@aminemaghous]

MVVM was used by Oracle JET (OJET) you can find docs and tutorial about it.

[@user-so4bl6ss7k]

it's very clear, although i still don't understand it, thank you.

[@jitendersingh3684]

Hi, Any-one could you please tell me what is "Ifg" in the `typical learning curve` (At the end of the video)

[@johndoan3526]

The BEST explanation.

[@sudhanshuyadav2756]

The key takeaway from this video is Delegation. The Model(M) and View(V) will always be constant in any of the Client Architecture Patterns, the Controller(C) will start delegating the overload as our app becomes more and more complex. Keep this in mind, you can always start with MVC and end up in VIPER depending on your app's complexity and requirement phase. Architecture is always evolving in nature.

[@LuckyFortunes-b3q]

They're all MVC rebranded and overcomplicated.

[@snowy0110]

​@@LuckyFortunes-b3q how would you organize a rich client application (classic, non-web) by using MVC by the definition, for example? Imo, a simple MVC does not explain how to deal with routing between several pages.

[@LuckyFortunes-b3q]

@@snowy0110 you dont pass data between pages. A page is just one view. The model contains all business logic of the application and should be able to do all of the core features of the application without depending on the view.

[@snowy0110]

@@LuckyFortunes-b3q I still don't understand how would you approach a switch between pages

[@LuckyFortunes-b3q]

@@snowy0110 I guess coding is not for you. Don't have enough intelligence to look it up or ask ChatGPT.

[@mohammadalaaelghamry8010]

Great series, thank you.

[@MrDeeptiprasadnayak]

Can u share Which tool is used to make the data flow?

[@leomysky]

Thanks for the video

[@adilsheikh9916]

In VIPER presentation, pls correct 'Entily' to 'Entity' I always wonder how you present the tons of knowledge so simply with such excellent presentations. Appreciate your efforts. I believe, people should understand the requirements first & understand the usage patterns, before picking any pattern. In fact, I think patterns will be coming to picture naturally if the development is done with open minds & not like 'My way or Highway' That way a project will be a good one to work for, but it may cause many other projects to shutdown, as in many projects work is done like anything in the name of coding, development, innovation & what not.... By watching your videos, people fake a lot during System Design interviews...in the name of 'Back of the Envelope' calculations, these people give any numbers & then present the design what they have seen over the internet...I believe if someone ask the relation between their numbers & designs then most candidates will be blank.

[@thisissmz]

Your explanation is very clear and short. This is what makes you stand out to me.

[@Well-o5t]

Great video! Would be cool if there was the MVI pattern

[@learnandexplorewithsab]

Always eager for your content.

[@joshy56]

Nice video, thanks for it.

[@rammehar5531]

Hi Sir, please also create video on ddd and clean architecture

[@mitotv6376]

Very nice

[@nickplays2022]

I’ve seen most of these diagrams but an example with multiple screens and a list of items would be helpful

[@gus473]

Great episode! Byte byte go is on its way to 💯 K subscribers, and so far bbg's YT "Shorts" have been excellent too! 😎✌️

[@MarcelinoDeseo]

I wonder if there's an architecture pattern that allows us to start simple and then grow bigger when needed.

[@KuopassaTv]

Yes, it's called rewrite

[@MarcelinoDeseo]

@@KuopassaTv that's the last thing i want to hear 😅, though I guess it's unavoidable 😞

[@Geza_Molnar_]

@@MarcelinoDeseo What's the reason you don't want to hear it? Isn't it better to use a very simple approach for a proof of concept and a prototype (low number of code lines, relatively, covering only parts of the happy paths and only the main uses-cases), still a simple approach for a MVP (minimum viable product 🙂), and another when the app / system is scaled up by more features and/or user number?

[@MarcelinoDeseo]

​@@Geza_Molnar_ I'm aware that refactoring the code is the way to go as the codebase grows, though it would be a slow and meticulous process. I was hoping for an architecture that you can use few concepts and you can just inject more with minimal effort more as the code base becomes larger.

[@Geza_Molnar_]

@@MarcelinoDeseo I hope, too - However, that sounds like hoping to catch the Holly Grail :-) If there is capacity for that, then the SOLID and other principles are a good thing to follow. The evangelists who spread the word say that those help to make refactoring an act of enjoyment and not a painful struggle. However, if there is no time for that, or at that moment the circumstances don't approve such an investment in the easiness of future development ... Then we'll burn in the hell of technical (and other) debts. At least, we are aware of that :-) Minimal effort - for the current round of development, or for the whole long software development lifecycle, or for the sofware lifecycle? Not only managers choose the first. And not only because they don't understand software development or the expensive consequences. In an Ideal Life I'd choose the last.

[@mpdev]

How do you know that I've just started a project that requires this knowledge? Great timing!

[@caseyfischer7015]

clear as mud.

[@TheShprota]

The example of upload the picture by client was a nice touch, it's pity that you didn't follow the whole flow with examples for last, most complex ones.

[@RaiSingh]

Sir is clean architecture is an example of VIPER ?

[@artxiom]

I totally forgot that these all exist 😄 I just use nowdays everywhere Redux or something similar - because of how simple, easy to reason about and scalable it is.

[@yordanov5.0]

Please make a video "Stack vs Heap"

[@tomross4599]

You argued that it’s about app size. I think it’s better to think of team size. The more complex the pattern, the better to work concurrently on different parts of the app. And vice versa: If you spend your lifetime working alone or in a team of two on an app, none of the patterns will give you a boost in productivity or quality.

[@metalmikecode]

I would argue with yes and no. Using design patterns will enable your application to be manageable and scalable. If the team is not big enough, the project development may go slower but can have the potential to grow faster when needed and you can plug in more developers.

[@ivanivanovich2088]

Where can I find the image that is displayed in the preview for your video?

[@nehakushwah8055]

MVP and MVC seems similiar?

[@leroyjenkins6347]

I would love to go over more reactive app architecture with technologies for jetpack compose or swiftui

[@yinglaoliu3838]

React Native with GraphQL tends to follow a component-based architecture with a focus on the UI and state management being closely integrated, rather than fitting into traditional architectures like MVC, MVP, MVVM, or VIPER.

[@zivunknown]

With the exception of VIPER, the others are all basically the same 3 logical components, even if they are split differently or some part of them is moved here or there...

[@krystianh4732]

Oh, you missed MVI pattern. Please add it to summary. Thanks for your videos

[@thepcool]

In the VIPER title, you misspelled Entity as Entily

[@golmatol6537]

Wish you had given an example for each pattern.

[@evstafyevandrew2198]

Парень, а ты какой программой делаешь такую крутую анимацию?

[@zixuanzhao6043]

so what's the difference between MVC and MVP?

[@mmmm-wm8ci]

Both In MVC and MVP there is possibility of bloated controller/presenter in MVC also UI logic is isolated in view, then what's the real diff BTW MVP and MVC

[@raj_kundalia]

thanks!

[@nyaa2054]

very helpfull

[@Dunc4n1d4h0]

Looks great in the video and I understand it, but in practice I'm confused what kind of pattern I actually use when I have app with for example separate angular frontend, Java backend with REST API, with "clean" controllers used just for get/send data, services underneath doing "hard work", repositories and entities with JPA and db. Can someone tell me what pattern is that?

[@justingiovanetti]

How are these animations made?

[@nishaantdixit9857]

So basically it's invented language used by Non Coders to say the same thing i.e. Break down logic into presentation, BLOC and Repo?

[@SDFC]

Well, the "two-way data binding" thing from 3:10 is a legitimate difference between ReactJS and Angular However, I have no idea what extra stuff is actually being handled by MVVM-C at 3:55 -- "react-router" is something that comes to mind, but I definitely don't recall excessive amounts of messy logic or state getting wrapped in handling that kind of behavior in any of the work that I've done 🤷‍♂

[@djSeakDigital]

Which one is NextJs

[@巴貝里奇]

I am a iOS engineer now, thanks for your explanation about those pattern

[@benjaminlehmann]

That was really great. Such a clear overview while also giving the right amount of detail. Great job!

[@Adrian_Galilea]

I never grasp these concepts beyond surface. I never know when to implement which and just rely on iteration. For instance, recently React implemented server components, and you can literally execute backend logic inside the same code that has no only the client code but also the view/style. So if I were to follow any approach from theory(from my understanding of it) I would create way worse code than just simply seeing which patterns feel more ergonomic and maintainable.

[@natenatters]

In all of these, which one persists the image in S3?

[@cusemoneyman]

You're probably joking, but I'm legit curious. I would call S3 the "model" in this case, since it's the final storage medium. But I also can't tell the difference between most of these patterns, since the more complex ones seem like implementation details of slightly different MVC uses...

[@awekeningbro1207]

None of them. It's a new one called MVVMS3

[@arjundureja]

@@cusemoneyman Everything is MVC at the end of the day

[@botondvasvari5758]

which one is react ?

[@arjundureja]

React doesn't strictly follow any architectural pattern, it's up to you to decide if you wanna use one. It is somewhat similar to MVVM though since data is binded to component state

[@qazyhn94]

React way with useState, is this MVVM?

[@arjundureja]

Kind of yes

[@sapito169]

i never heard off viper

[@t.mollov566]

All of them are MVC for me with some kind of helpers 😀

[@saidbakr]

Arrows in the diagrams are not clear, the order of what is happening is not clear except in MVC

[@Gemax-hope]

Ty

[@pavfrang]

MVP and MVC patterns are not very cleary distringuished!

[@yassinebouchoucha]

the most wanted question is: Next js fall in which type of Architecture Patterns ?!

[@jixiangcn]

冒昧问一下，你认识周崇廉么？

[@c00p3rok]

unfortunately they are very abstract and without code example have absolutely no use for engineers

[@Geza_Molnar_]

(Let me provoke 🙂) Engineers are able to draw the general abstraction out of specific implementations / examples, and are also able to create implementations / examples from an abstraction. Coders and Programmers not necessarily. Developers do, imo. And Architects, too, of course. Although, I haven't yet found the 'standard' where the capabilities of these roles / professions are described and compared. If anyone knows a list or table that contains something similar, please, link it here 🙂

[@Taddy_Mason]

Everyone has an architecture in mind until they get hit with the requirements.

[@emmanuelvalverderamos]

The MVC pattern, was not born as it is today, that's important to remember.

[@Elias07070]

You are a boss

[@labanmogire8973]

Did anyone grasp anything apart from MVC?

[@danielwilkowski5899]

That focuses too much on technology, and not enough on the actual architecture. Words like "view updates automatically" is just another phrasing of "the framework of my chosing updates my scaffoled application, so it looks like automation". If you want to learn more about what MVC was supposed to mean originally, checkout Robert Martins video: "Clean Architecture".

[@Adks007]

Your biggest strengh is to cover a complicated topic within 5 to 6 mins.

[@DL-iy3lf]

lfg! nice way to end the video.

[@sunofabeach9424]

UI developers are crazy

[@zimzam9166]

These 'patterns' do nothing except legitimise overspending of manpower on bloated projects that just don't need it. If you are a project lead considering implementing any of these, then consider that your team size is too big and you need to trim the fat

[@flashflexpro]

Anything more than MVVM is just to gild the lily.

[@JW-YT]

I've used MVC, never heard of the others and they seem pointlessly complex. So I'll not even bother.

[@khoihoang8888]

Not really! Those other pattern such as MVVM or MVVM-C is where you see on modern framework on front-end application. If you know React, Vue whatever, they are already utilizing these architecture, and that is where you learn how those framework works from day 1

[@JW-YT]

@@khoihoang8888 react is pointlessly complex lol. Its not needed 90% of the time.

[@awekeningbro1207]

This seems more focused towards folder structure than code architecture, because they are the same just broken down into finer parts

[@sudosai]

But what's the difference?.😢

[@alexon2010]

Para mim não faz o menor sentido este monte de padrão, só gera mais confusão, deveria ter um modelo único e evolutivo, toda aplicação seja para que motivo for tende a ficar complexa.....

[@bob-xm7ny]

Lets start with when the earth cooled. Nah bro, lets talk about current technology.

[@snowy0110]

People forget that there is no single place that defines these patterns, hence it is impossible to say when exactly a manual implementation of MVVM without a framework is in fact a simple MVP. I think, there is a lack of more fundamental thought to all these patterns - they must be categorized differently. All in all, bytebytego did a good job, but it is clear they are not masters of every topic. Especially this one. The video does not clear a lot of things: MVC and MVP are explained virtually the same. There are numerous definitions of what SOA is and what are microservices. Ridiculous that the industry can't agree on definitions.

[@count7ero]

i cannot for the life on me perceive a difference between presenter and controller. mvvm, viper and clean architecture make the stupidest, slowest, jankiest most unstable applications ever. i think they were invented only to sell more development hours

[@keepsilence6843]

What is the difference between this video and Top 5 Most Used Architecture Patterns (kzbin.info/www/bejne/nGfdiaynabuDhpo)? They both talk about the patterns of software creation.

[@Gigusx]

You make them all sound the same 😅

[@eduardoholzmann853]

to much logic binding, prefer a more clean architecture aproach indiferent from the languaje, this only works on android.

[@halavich9672]

Didn’t make any clearer

[@michaziobro5301]

I would make choice differently MVC - rather don’t use MVP - delegation or closure based MVVM - data binding approach rxswift, combine, @published VIPER same as MVVM but you need local cache and persistent layer or have complex business logic, more complex than just network services to call web api endpoints Generally use MVVM, name it MVVM and if needed add interactor layer and core data. But there is also redux style TCA or ELM like action reducers architectures. They i rather cumbersome and I recommand to not use them

[@anonymousbug3485]

Alex Gem

[@fallout__boy1130]

Without code example it is not useful at all, it looks like some pseudo consultant IT bs slide deck

[@newsgo1876]

The so-called design pattern is not a creature by human but the way God make the world.