4 ms·

This whole debate about mvc vs mvvm vs i don't know what really start to read like a joke. Here's the truth : your app probably has more than three major compo

• _pmf_ 10y ago
  So, you're proposing MVVM.
  • JustSomeNobody 10y ago
    Not necessarily. This could all be accomplished just be decoupling the view from everything else. It doesn't have to conform to MVVM, MVC, MVP, MVWhatever.
    • achr2 10y ago
      The part you're missing is that there is a huge grey area between 'model' and 'view'. So large in fact that all of these patterns where designed solely to help you draw lines in the sand between the pieces.
      • JustSomeNobody 10y ago
        I would argue there's a grey area between the 'view' and the 'controller', but not the 'model' and the 'view'. The model is logic and data and has absolutely nothing to do with presentation. But, I will concede there are 1001 ways to interpret these patterns (MV*).
        • achr2 10y ago
          Agreed - however, I wrote 'model' considering the binary separation that was suggested.
    • Stengo 10y ago
      Convention does have its merits, though. Knowing a pattern makes reading and writing code much easier. So having structured, known ways to decouple views (or every other component for that matter) is valuable.
      • JustSomeNobody 10y ago
        I don't disagree with what you're saying. But there are patterns where there's the View and ... everything else. It's a perfectly valid way of organizing code (for, admittedly, simpler code bases).
• mason240 10y ago
  Yes, exactly. In ASP.NET MVC land, our our general convention is to have a service layer that does all of the business logic, and the actual MVC web layer only handles UI concerns. In theory, you set your service layer (just a class assembly) up so that it can handle requests from multiple UI layers (a web MVC layer, a phone app, or even one case, a command line prompt). MVVM-C seems overly complicated.
  • bsaul 10y ago
    Yes indeed. Backend developpers have known "services" layer for a long time, but it seems to be completely unknown to frontend developpers (except maybe angular ones, which heavily promotes this pattern). Model is basically a collection of types, and services are where the business happen and shit gets done. And only in the end should you care about presenting all that stuff in a good looking way. But even this is a bit of a simplification once you get into low-level architectural decisions : is your app real time, does it handle data synchronization with a backend, can it work online and offline , does it need to make certain operations atomically ? Do you have n publisher - n subscribers types of communication between your components ? etc etc. Those are the true questions you need to ask yourself first, and not think in terms of three or four big boxes where you have to put all your junk trying to find descent names.
• Roboprog 10y ago
  > the GUI isn't the most important aspect of it. Well, if I restrict my scope to the rich web client ("SPA") style work I have mostly been doing for a bit over a year, it is. In fairness, that's because there is a back end with all of the "real" business logic in it, and I just put up what the view-model tells me to, wiring buttons and some other events to REST calls to phone home and find out what to do next. Anyway, you are usually right, but the project type matters: there might be just enough UI to enter some selection bounds and then kick off a batch process, or it might be a small game that is little more than a "busy box" consisting almost entirely of pretty artwork and responses. Plan & budget the design effort for the UI accordingly.
• tamana 10y ago
  OK sure , but the entire point of the MVC concept is how to build a powerful UI for your app. Your proposal solves a different problem.