3 ms·

Can you elaborate on why MVC is not appropriate for UI's? Currently learning AngularJS and feels like they did a pretty good job of implementing MVC via the $sc

Can you elaborate on why MVC is not appropriate for UI's? Currently learning AngularJS and feels like they did a pretty good job of implementing MVC via the $scope interface.

blub 11y ago
MVC has become meaningless after being overloaded so many times. I looked at the Wikipedia definition and to my surprise I saw that it's significantly different to the one I read, with no mention of the word "input". Seems that MVC nowadays means MVP (i.e. Model view presenter where the view, presenter and model are layered and comunicate strictly to the layer above and below). In a way this is good, because MVP works and is used by most UI frameworks, even if they call the "P" "C" in the docs.
- moron4hire 11y ago
  I've been living for over 10 years in an industry that has espoused the importance of "MVC" for and I still don't really know what it means. The original article was kind of confusing on this matter--though that could be a result of me reading it right after I woke up (morning ritual: read HN for half an hour, then get out of bed). I find the Wikipedia page easier to understand [0]. And realize now that whatever I've always been doing and whatever I've seen done on all projects I've been involved on has strictly been MVP, not MVC. I find these statements to be at odds with each other: > The model directly manages the data, logic and rules of the application And then shortly after: > Whenever there is a change to the data [the model] is updated by the controller. I know every project I've worked on has interpreted that last statement to mean the model is dumb, that the model does not do anything of its own to manipulate data. Of course, that flies in the face of how they have all ended up getting implemented: relational databases with a significant number of stored procedures. When you're dealing with RDBMSes, there is a big struggle at play between correctness and performance. And there are no strict answers, everything is dependent on the particular situation. You have to profile everything, because it's nearly impossible to predict how anything will perform before trying it. And it can be a big deal, the difference between sub-second processing in one way and over-a-day the other way. It can be ludicrously bad, so you are guaranteed to be compromising "correctness" at several points in time. One way I've seen that happen is with a heavy use of stored procedures plus "logic layers". There are stored procedures for getting the data out of the database, but then there is a lot more application-level logic for further manipulating the data into its final form. But often--especially any data manipulation that has no linear dependence between records--the most performant solution is to implement the entire logic in a stored procedure. And that would mean that the store procedures the real controller. But god daaaaammit, every procedure SQL extension in existence right now is complete garbage as an application language. The more I think about it, the more I suspect MVC is meant to have the controller have only a notional understanding that "data must change", sending the minimum data necessary to the model to make that change happen, but have the model fully implement that change on its own. This is the opposite of the projects from my past: instead of a "dumb" model, it's a "dumb" controller. But SQL is far too dynamic for my tastes. I want static checking. I want to be able to test at least the validity of the logic (i.e. "yes, a column named 'Something' really does exist. No, there is no 'Soemthing' column. Yes, you can those two columns together and expect an integer out of the deal.") before ever having to even setup a database server and running it. What I really want is a strictly-typed language with first-class support for set and relational operations that can be used to validate the query logic before transpiling down to platform-specific SQL. LINQ to SQL was supposed to be that, but in the end I think it missed the boat on a lot of static checking opportunities. Entity Framework is supposed to be that, but it runs on SQL Server only [1], the performance can be bad, and the overall design and workflow seem very inflexible. There are other systems that are mostly built on C#'s `dynamic` keyword. And they all are built under the guise of hiding SQL away from the developer, thus wedging themselves firmly into object-relation impedance mismatch problem. [0] https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con... [1] There are hacks to get EF working on other databases, but they are a pain and it isn't first-class.
  - blub 11y ago
    Ditto, in a decade of UI dev I have never actually implemented MVC or used it. A lot of Apple iOS/Mac books claim that Cocoa is MVC, contributing to the confusion and now there's the JavaScript libraries which also claim to be MVC.
currywurst 11y ago
I didn't say that it's not appropriate :) Just that as originally defined, a Controller object intercepts all user input. From the article, "The controller's job is to take the user's input and figure out what to do with it." Unfortunately, I haven't had a chance to look at AngularJS in depth. But it would be great to compare the various SPA frameworks and see which parts of the classic patterns they adhere to.

Can you elaborate on why MVC is not appropriate for UI's? Currently learning AngularJS and feels like they did a pretty good job of implementing MVC via the $scope interface.

blub 11y ago

MVC has become meaningless after being overloaded so many times. I looked at the Wikipedia definition and to my surprise I saw that it's significantly different to the one I read, with no mention of the word "input". Seems that MVC nowadays means MVP (i.e. Model view presenter where the view, presenter and model are layered and comunicate strictly to the layer above and below). In a way this is good, because MVP works and is used by most UI frameworks, even if they call the "P" "C" in the docs.

moron4hire 11y ago
I've been living for over 10 years in an industry that has espoused the importance of "MVC" for and I still don't really know what it means. The original article was kind of confusing on this matter--though that could be a result of me reading it right after I woke up (morning ritual: read HN for half an hour, then get out of bed). I find the Wikipedia page easier to understand [0]. And realize now that whatever I've always been doing and whatever I've seen done on all projects I've been involved on has strictly been MVP, not MVC. I find these statements to be at odds with each other: > The model directly manages the data, logic and rules of the application And then shortly after: > Whenever there is a change to the data [the model] is updated by the controller. I know every project I've worked on has interpreted that last statement to mean the model is dumb, that the model does not do anything of its own to manipulate data. Of course, that flies in the face of how they have all ended up getting implemented: relational databases with a significant number of stored procedures. When you're dealing with RDBMSes, there is a big struggle at play between correctness and performance. And there are no strict answers, everything is dependent on the particular situation. You have to profile everything, because it's nearly impossible to predict how anything will perform before trying it. And it can be a big deal, the difference between sub-second processing in one way and over-a-day the other way. It can be ludicrously bad, so you are guaranteed to be compromising "correctness" at several points in time. One way I've seen that happen is with a heavy use of stored procedures plus "logic layers". There are stored procedures for getting the data out of the database, but then there is a lot more application-level logic for further manipulating the data into its final form. But often--especially any data manipulation that has no linear dependence between records--the most performant solution is to implement the entire logic in a stored procedure. And that would mean that the store procedures the real controller. But god daaaaammit, every procedure SQL extension in existence right now is complete garbage as an application language. The more I think about it, the more I suspect MVC is meant to have the controller have only a notional understanding that "data must change", sending the minimum data necessary to the model to make that change happen, but have the model fully implement that change on its own. This is the opposite of the projects from my past: instead of a "dumb" model, it's a "dumb" controller. But SQL is far too dynamic for my tastes. I want static checking. I want to be able to test at least the validity of the logic (i.e. "yes, a column named 'Something' really does exist. No, there is no 'Soemthing' column. Yes, you can those two columns together and expect an integer out of the deal.") before ever having to even setup a database server and running it. What I really want is a strictly-typed language with first-class support for set and relational operations that can be used to validate the query logic before transpiling down to platform-specific SQL. LINQ to SQL was supposed to be that, but in the end I think it missed the boat on a lot of static checking opportunities. Entity Framework is supposed to be that, but it runs on SQL Server only [1], the performance can be bad, and the overall design and workflow seem very inflexible. There are other systems that are mostly built on C#'s `dynamic` keyword. And they all are built under the guise of hiding SQL away from the developer, thus wedging themselves firmly into object-relation impedance mismatch problem. [0] https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con... [1] There are hacks to get EF working on other databases, but they are a pain and it isn't first-class.
- blub 11y ago
  Ditto, in a decade of UI dev I have never actually implemented MVC or used it. A lot of Apple iOS/Mac books claim that Cocoa is MVC, contributing to the confusion and now there's the JavaScript libraries which also claim to be MVC.

currywurst 11y ago

I didn't say that it's not appropriate :) Just that as originally defined, a Controller object intercepts all user input. From the article, "The controller's job is to take the user's input and figure out what to do with it." Unfortunately, I haven't had a chance to look at AngularJS in depth. But it would be great to compare the various SPA frameworks and see which parts of the classic patterns they adhere to.