Why is mvc so popular

The controller will be required to understand all the elements in the view and to map them to the specific calls required on the model layer. Since the controller is a single access point connecting many views to many models this can quickly get out of hand and end up being an incomprehensible controller module. Yes you can make the View only depend on the Controller only by making the Controller transform using PHP as an example the Model objects to non-Model objects like simple arrays.

As we already know, performing this transformation can be more effort than it's worth if the decoupling isn't actually needed. If the View uses the Model objects then it has this dependency. However, this can be relieved a bit by having the View depend solely on the Controller for its required input, which can be Model objects. You can still directly call upon the Model layer to retrieve objects within the View layer but it's strongly urged against for the coupling issues you bring up.

I haven't gotten back to this in a long time, mostly because I was still thinking. I was unsatisfied with the answers I received, they didn't really answer my question. A professor, recently, did steer me in the right direction. In the vanilla MVC architectural pattern, the dependency between the View to the Model is often not used, and you effectively end up with Layers. The idea is the same, the naming is just poor. You can read the full article here ASP.

I'd like to add some more things. First of all for my point of view is we use the model as container for the information we want to pass and show on the view. Usually the action method into the controller ends with return view "viewName",model. The view itself probabily will change its layour against the model :. The controller orchestrate the the views and is indipendent from the view but a bit dipendent from the model:. In my opinion ,you'd better try it in your programme , you can use ruby on rails ,or codeigniter for php ,these great framework may be helpful to your understanding the MVC.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams?

Collectives on Stack Overflow. Learn more. Why is MVC so popular? Ask Question. Asked 11 years, 2 months ago. Active 8 years, 2 months ago.

Viewed 4k times. The Layers architectural pattern defines N - 1 dependencies, where N is the number of Layers. Edit: Not ASP. With regard to griegs's post: As far as mocking, Layers still allows you to use the Command Processor pattern to simulate button clicks, as well as any other range of events. UI changes are still very easy, perhaps even easier.

Layers creates a strict separation. Both Layers are black boxes, free to vary independently in implementation. The Controller has 0 dependencies on the View. The View can be written, and time can still be saved with loose coupling. Improve this question.

Mike Mike 18k 10 10 gold badges 54 54 silver badges 72 72 bronze badges. Add a comment. Active Oldest Votes. Because you decouple the interface from the controller making changes easier. MVC supports parallel development of apps. In MVC, a developer can write code for the View while another developer can work on Controller to write business logic for the application. A team can perform multiple tasks at a time that leads to rapid app development. MVC here allows developers to build multiple views for a model easily.

Support to asynchronous technique further allows developers to build apps that load faster. As we mentioned earlier, MVC promotes parallel programming; thus, a unit of work runs separately from the main application thread. As the Model part does not depend on the views to process data, changes in either section do not affect the entire model. Due to this, MVC comes handy to develop apps that may need frequent changes in the user interface like fonts, colors, screen layouts and support for mobile or tablets, etc.

Model-View-Controller architecture returns data without formatting. The database can do whatever it needs to for storage. Neither one needs to know what the other is doing. I'm oversimplifying a bit here, and certainly there's data related operations that don't belong in the database your rocket launch countdown is a good example.

But in my experience almost every application developer thinks data storage should be a dumb thin layer on top of the filesystem, which creates chaos for everyone else that needs to do reporting or analysis on the data. I think your SAM pattern is a big step forward, as it pushes state into the model. When you shape your APIs to the view they become "ephemeral" to use Netflix's qualifier. Depending on which technology you use to build these ephemeral APIs, you are hosed.

I'll publish more snippets over the week-end that show that you really don't need an MVC framework at all, because you no longer need to wire your APIs up to the view. That was the only value these frameworks provided, albeit it was the wrong thing to do. The kids in the React team didn't even thought that was a problem, they were having too much fun with the virtual DOM, that is, until people started to build real things with React and then the question came back front and center.

Flux was clearly not the answer, Redux, slightly better, but entangled the model with the actions because the pattern is using the wrong state machine semantics. Jim, thank you for your comments, yes, after working with it for a couple of months and building an ecommerce website with it will share some snippets over the week-end I share your views that ultimately you want to achieve this: the web code can do whatever it needs to for display.

The beauty with SAM is that: a the "actions" become a conduit to the model, actions are by no means "controlling" how the data model updates, they just authorize for and prepare the data to be presented to the model b the functional construction of the view forces the front-end developer to think without any response in mind.

I was once a co-author of the SDO Service Data Object spec, to perhaps I am biased and there are better ways to deal with that question. I think it's worth to watch following presentation: www.

I created a room on Gitter for the SAM pattern. I am going to be building samples from my current work over the next couple of days and share the process there.

Any questions are welcomed. Thank you Jean-Jacques for providing this example! The Javascript world is currently boiling and the path you are exploring seems to disrupt a couple of framework. I like it. S - I was pleasantly surprised to look at this article :. That was an interesting article, it is great not to blindly use frameworks, and to question whether we sometimes over-engineer solutions.

There is just way too much "how" in your code. I find it so much more expressive of programmer intent to use MVI and event streams in Cycle. Fred, the "state machine" is optional, I felt that was the best way to illustrate a "state" component. You'll notice that it is not present in the other samples.

You are free to write the S, vm, A, present and nap functions the way you want including using cycle. The only constraint is that S, vm, A and nap are pure functions. That being said, the semantics of cycle. When that happens, people end up reifying lots of concepts behind streams and that does not look pretty.

Business Components are just to solve the problem stated at beginning of the article. MVC is just a way to organize the code, Business Component is just another, but more useful when the data structures change a lot and the technological layers not. SAM looks to be the answer many developers have been looking for, as the list of frameworks grow we all need to take a step back and look at the methods rather than jumping on the bandwagon with yet another Superheroic JS Framework.

Joined the gitter channel for more insight gitter. Yes, its amazing to be able to write code without a "straightjacket". Compare that to Angular Not sure where Dan picked the state machine semantics of Redux, but they are not that "predictable". That's where SAM draws all its power from. I suggest people who use Redux switch to SAM, they'll avoid this unnecessary coupling between the actions and the model in the reducer. There is an interesting discussion going on Gitter , if you are interested to learn more about SAM.

We share code samples and implementation models e. I created several rooms to discuss the different aspects of the pattern and share some code samples. This is another example based on the SAM pattern, this time using node. Very interesting post, thank you. I haven't had time to take it all in yet but there are a couple of comments I would like to make: 1. It's more specific to the task at hand rather than a general Javscript function if you know what I mean.

I'm still not convinced about the lack of a need for GraphQL. If all the front-end developers could just write Javascript functions and conceptualise what they were doing that would be great, but perhaps GraphQL is a simpler way to "write the functions. Thanks again, and I hope my comments make sense. Cheers, Ashley. Ashley, these are all great questions, and I can only encourage you to try the pattern for yourself.

They are actually fundamental questions because they have massive implications on the cost of building omnichannel solutions which is the context in which this post was written. There might be some apps where these technologies could add value, but on a day to day basis, I don't need any of them. SAM allows the designer and front-end developer to have a much cleaner separation of concerns and consequently a much better working relationship.

The reason why SAM changes everything is because the view is limited to be a "State Representation", there is never a need to go beyond "rendering the view", all the application logic stays in the SAM loop. That is why SAM is new and different.

If there was ever a need to have a slightly more dynamic behavior, SAM's composition fig 9 would again keep the application logic completely separate from the view. Template technologies including JSX, though in React you essentially create functions, so it depends how you use JSX, as a template or as a function are simply the wrong technology because they severely limit your ability to create meaningful webparts from the model, while requiring the model to match the shape the template.

Functions on the other hand deliver all the power of imperative language to render the view properly, without requesting the model to fit the view. This is also why you don't need the virtual DOM, simply because you know exactly what will change in the view. Again, I don't dispute that there might be a few cases where the virtualDOM add value, but these cases are very limited.

SAM gives you the ability to make decisions and optimizations from the model. Trying to optimize at the HTML element level is interesting from an engineering point-of-view, but again, unnecessary. The whole point of SAM is to achieve the best decoupling possible between the view and the way the model is formed fig 7.

By design in SAM, the view cannot request anything. It can only initiate reactive loops. When the loop ends, a new view is produced figuratively, based on my point about the virtualDOM. Nothing else can happen in the view at all.

This post reminds me a lot of the Elm architecture , which has recently seen a lot of traction in other languages as well redux as you mentioned and re-frame in ClojureScript.

Do you see any key differences between SAM and the Elm architecture? Yes, there is a small, albeit important difference. React, Cycle. With that in mind, if you construct a reactive loop such as Model Update View or MVI , the assertion : The logic of every Elm program will break up into three cleanly separated parts: model, update, view That assertion is erroneous. You would be missing a couple of important parts: - the logic that decides which state you are in so you can properly compute the view and enable the actions associated to the state - the next action predicate One can achieve a much better decoupling between the view and the model by introducing the concept of State to hold that kind of logic, otherwise you would have to fit it either in the view or in the model.

The concept of "State" is critical to achieve that decoupling. The view then becomes a pure state representation, and hence a pure function of the model. As a side note, some people like to call "control state" what I call state and they prefer using the word "state" to describe the content of the model. For me a model is just a set of property values with rules that decides whether some values are acceptable or not.

The Model does not know anything about actions and state. Above the model, there are the control State and the Actions.

Below is the usual CRUD to data stores. So, it is not enough to break up the logic in just Model,Update,View. None of what I am saying would break Elm, Cycle. Hmm, would you help me out? What is the coupling between model and action in the reducer - that the reducers and state are both part of the store?

Also, I don't think Flux was a reaction to people building complicated apps with React - I think Flux architecture and the idea of the universal data flow predate React at Facebook. Not certain, but that is the story I heard. With SAM, actions are external to the model and as such can be reused across models and even implemented by third parties.

In Redux, actions are merely intents. The implementation of the action is in the model reducer. That is wrong. Please note that the way Actions are structured in SAM expressed as a transformation make them composable as a pipeline: model.

The same "reducer" logic would then work just as well with different actions incrementByN. We will not get out of MVC as long as the controller will update the state.

Redux is a big step back. About Flux, my comment was just regarding the fact that React is considered to be "just the view" and something was needed for M and C. Flux has some great ideas but completely missed the model part. Redux came around but completely missed the action parts. Both of them are however missing the "state". Truly brilliant. This simple formalization is precisely what I've been searching for. I need to concretize it by doing some code studies, but the broad strokes excite me.

Once you start coding that way you'll be amazed at what you can accomplish. Feel free to join us on Gitter , there are some great discussion going on. Several readers already came forward to create some samples with their favorite framework cycle. This is being discussed here: news.

First of all, thanks for the great summary. It is a long time since I've started thinking about state localization in UI. Most of the frameworks we have to deal today spread the state among the components which results in endless bugs and virtual inability to introduce sane multitasking. I believe, your approach could solve many of these problems.

You extensively use generating the View part using HTML templates, but in most of the native frameworks generating the view is either impossible or very expensive; and in those which do support such a thing WPF data templates the usage does not exactly align with proposed paradigm.

It happens time and again, another pattern from the programmers perspective, when MVC really is much more than a pattern, and it includes the users perspective. I've made an attempt to clarify what MVC is really about. I appreciate if you read it: github. Michael, thank you for your comment. We fully agree, state is the problem and React is one of the worst offenders Most of the frameworks we have to deal today spread the state among the components which results in endless bugs and virtual inability to introduce sane multitasking and, yes, I also believe that SAM can completely change the game in Front-End construction, by bring back some sanity in that space.

When you watch this video detailing the best way to build a React app, you understand very quickly that you are much better off staying away from it, and my guess is that it's true of Angular2 as well. Just a few words about the work I have done in the mobile space, five years ago I built a model driven cross platform iOS, Android development platform called Canappi. So I know a thing or two about code generation.

You'd have to optimize how the reactive loop returns parts or all of the model. Not every application has the footprint of Facebook, so it's not such a burden do to return the whole model each time and let the view function pick up what it needs. I do disagree with your statement: the native frameworks generating the view is either impossible or very expensive Again, I wrote Canappi, so I know a thing or two about code generation.

In any case, you don't really need to "generate" anything, this is more parameterization of the view. You don't have to completely change the paradigm to start implementing SAM. Do you think that's a reasonable answer? Happy to review some code if you want to share a sample. Feel free to join us on Gitter. With that in mind, I believe that if no one understands MVC after 40 years, I believe that if Google engineers have been flip-flopping on Front-End architecture for the good part of the last 15 years, it is because, MVC, in essence, does not exist, its semantics are so weak that it leads to code that no one can write, no one can debug and no one can maintain.

MVC creates "run away" systems where the only answer to system construction is always to create more views, controllers and models. SAM takes into account all these point of views. Again, Apologies to Prof. Reenskaug, but MVC needs to go. There is no point in keep it, everyone understands that but there has never been a viable alternative. If SAM is not the answer, then another one will come. SAM is a pattern not a library. I can choose to implement the pattern as I wish.

I personally prefer a "raw" style of implementation, I tend to be see no particular value in all these frameworks. I would, again, as a personal preference, trade any day the ability for a framework to tell me I forgot to close a div to an npm install that takes 10 min to run on my Mac. Apologies, the link was not correct, here is the link to the sample that took me 10 min to install on my mac.

Hi, Great article. Some of the stuff you explain here do convince me to try it out. Can you share the node. I would also like to check them out and give it a shot : Thanks. Jean, I guess someone might have already suggested it but it would be great to start a blog with more articles and code examples along with stuff you try to assemble from and to different gitter rooms : PS: I just added myself to 3 different rooms of yours related to SAM and information there looks hard to parse and catch all that's important :.

I also have to make a living With respect to node. STAR is a small library that implements the pattern, but is not required for the implementing the pattern. VERY interesting article. I shall be digging into your code and ideas for sure. To me, this is the real killer benefit of React. Rob, thank you for your comment.

I would say it depends the type of application your are building. I didn't say you'll never need it. I understand it's value and respect the engineering behind it, but I would argue that today React is out-of-control and Angular too.

Facebook has taken a great idea and completely wrecked it. Is this really what it takes to write a Web app? I am sorry that it came across as "you shall never use these frameworks again".

Looked great. When the "diff" is on the order of the content of a div element, I am not sure you need it. SAM creates the state representation at the end of the reactive loop like React , so you are not touching the DOM several times.

Is the virtual-dom working so well because of the diff algorithm? Actually I agree with you - I've been working with web apps since the mids and even then despaired at how there seemed to be an overwhelming desire to make it all a lot more complicated than it actually was or needed to be.

So I really like your approach and the thinking behind its concepts, and I'll definitely be digging into it in more detail over the coming days.

The thing I do like about what Facebook did with React Native was realising that mapping the virtual DOM to the native iOS UI components was possible, allowing a truly native app to be created just using JavaScript as opposed to a hybrid app using Cordova.

Otherwise we're on the same page! That being said, what you need to consider is that developers and architects have a tendency to ignore state as in SAM state, not Redux state with is SAM's model. That's why "State" needs to be explicit in the Front-End Architecture, and hence SAM, otherwise we'll be heading for a big big mess I believe we already have. I agree with people that say State Machines are too heavy to write code and that's why SAM provides an interesting compromise, you can reason about State without having to result to a state machine systematically.

React or any MV patterns, especially the ones that start with MV has some inherent difficulty dealing with state because you can only infer the control state once the model has been fully mutated as a result to applying an action.

Instead of "View" people should start adopting the language of "State Representation", that would change a lot of conversations. I was reading this article this morning on Angular 1. Following up on some readers' requests, I created a github repository to help people get started with SAM jdubray.

One strong benefit of GraphQL, and in fact the original motivation for it's creation was to fulfill all data needs in a single round trip to the server, where it's often the case that using REST APIs requires subsequent round trips to get all the necessary data if you need multiple types of data for your views. This is critical for performance, especially on mobile devices where network latency can be really large and the penalty for additional round trips is large.

Relay allows you to write small pieces of a GraphQL query called "fragments" next to your React components. Relay will fold together all fragments relevant in order to make the single GraphQL query network request to load the information necessary to render your views. Relay can do some pretty interesting things with this model as well, like serve you previously fetched data from cache while going to the server for newer information.

GraphQL plays nicely with a node micorservices architecture. You can also use Facebook dataloader to take advantage of caching.

Works well with Redis github. It is the future. Everything is moving client side. REST is dead. Front-end engineering is the future. Backend will be pretty basic relative to the complexity of the front-end. You'll just have full stack Java Script engineers. Mainly comes down to economics. JS is just insanely cost effective. You don't have to believe me but it's happening just the same as JavaScript is the universal language of the future. I remember, 3 years ago, when people laughed at the idea of JavaScript taking over the world.

Now Node is 3. Facebook has a lock on the web. It's too big to stop. Anything novel, they'll just acquire, hire the creator or steal. You make some good points though and I like the idea of SAM but we need to get everyone on the same page. The only difficult thing about using RGR is the initial setup. After that, it's so easy. Just plug-n-play. Long term maintainability is so easy. The more siloed everything is, the better.

That's how the real world works and there is no reason it shouldn't be exactly the same on the web. And lastly, you're a JavaScript expert and are able to conceptualize things that others with less experience aren't able to do just yet. A lot of startups like frameworks because a they can't afford experts like you and b it gets everyone regardless of experience on the same page. You may not like the massive influx of novice coders but the demand for programmers is just gnarly I believe I understand GraphQL to a reasonable level.

All that you are saying is correct, however, in the world I live the front-end very rarely talk to the database with no business logic in between. My world is also filled with all kinds of exceptions such as unavailable systems of record or failed transactions which require compensation. When you live in that world GraphQL does not apply. Now I understand why Facebook built GraphQL and why it might work well for them, but I would refrain presenting it as a magic bullet.

When your world is well formed they work like magic with some edge cases around joins. You don't have to convince me,I strongly believe that too. Actually, quite far from it, I don't code for a living.

I actually it is the other way around Frameworks stifle innovation because they require super advanced skills to work around their broken semantics and fake optimizations. With SAM an ordinary developers can start writing very innovative and beautiful Web apps. So again, I don't discourage people using GraphQL below the model, sounds like a reasonable technology, but I would not present it as a magic bullet as you are doing, it is not applicable.

I have heard so many time the story: "after a long and complex setup everything is easy" SAM shows that everything can be easy: I can replace React. Imagine that. I'll defend that claim any day. Interesting especially with the functional approach, but still too much ceremony with all the View, Model, State and Action nouns. All you need are RxJS Subjects with message driven publish and subscribe. With all due respect, you are missing the point and confounding wiring with semantics.

SAM is about an extremely precise code factoring, you can wire the pattern any way you want, it's even ideal for "Isomophic JavaScript".