5 ms·

My understanding of the Model-View-Adapter pattern is that the adapter is the dependant of both the view and the model, which are disjoint objects. The diagram

My understanding of the Model-View-Adapter pattern is that the adapter is the dependant of both the view and the model, which are disjoint objects. The diagram shown here has the arrow inverted between the adapter and the view, and the author mistakenly assumes it is isomorphic to the MVVM pattern. This might seem nitpicking, but it's an important distinction. In the MVA pattern, the adapter is the only thing that knows about both the model and the view, ensuring that the two are cleanly separated. The MVA pattern is underused. People have a tendency to make their views dependant directly on the model, or vice-versa, and often don't keep a clean separation.

mpweiher 8y ago
I'd say the MVA (or MVP, or Apple MVC) pattern is overused. There is usually neither a point to separating the view and the model like that, nor is it usually possible. In practice, you get lots and lots (and lots and lots) of glue code that is (a) boring, (b) repetitive, (c) error-prone and (d) non-reusable. The code is non-reusable because it is specific to both the view and the model. And it doesn't usually help in keeping the view model-agnostic, because after all the view is there for displaying the data that's in the model. Additional layers can't change that fact. See also: Massive View Controller.
- deleted 8y ago
  [deleted]
- chiefalchemist 8y ago
  > "because after all the view is there for displaying the data that's in the model." I wouldn't disagree. But I also believe there's another way to look at the view, and that is as the interface between the application and the user. That UI has or needs to have (design) patterns, a la Atomic Design for example. http://atomicdesign.bradfrost.com/ http://atomicdesign.bradfrost.com/ For example, a list is a list is a list. In a well designed UI / UX that will follow / maintain a pattern. At that point, there's no real relationship per say to particulars in the model. The view / partial is "free standing" and can be repurposed as required. In the mind of the view, there is no model. Maybe I'm splitting a hairs and/or have gone off on a tangent? My apologizes.
  - usrusr 8y ago
    I would conceptually put reusable view components ("a list representation") completely outside of the scope of all MV* thinking. The "V" part is a composition of high or low level view components, not the components themselves (at implemention time - at runtime the view is the sum of active components). When you write universally reusable view components, you are not implementing the V of an MV*, you are working on tools to implement a V. Just like writing a database engine isn't defining a domain model.
  - mpweiher 8y ago
    Hmm... > a list is a list is a list. I would think that to be useful, a list will be a list of something. And that something will almost certainly be domain/model specific. Even if you expose just a list of strings, those strings will have some sort of semantic actions associated with them.
    - chiefalchemist 8y ago
      Yes. But it's not (or shouldn't be) a one to one between view and model. At least that particular view should be independent. Note: It was simply a basic example. The crux being to also look at the view from the frontend - user and frontend dev, and not only from the model forward. Fwiw I've recently taken over a project where I've found the same essentially partial four times. Not fatal, but more to maintain, as well as confusing when you're trying to unscramble things.
deleted 8y ago
[deleted]

mpweiher 8y ago

I'd say the MVA (or MVP, or Apple MVC) pattern is overused. There is usually neither a point to separating the view and the model like that, nor is it usually possible. In practice, you get lots and lots (and lots and lots) of glue code that is (a) boring, (b) repetitive, (c) error-prone and (d) non-reusable. The code is non-reusable because it is specific to both the view and the model. And it doesn't usually help in keeping the view model-agnostic, because after all the view is there for displaying the data that's in the model. Additional layers can't change that fact. See also: Massive View Controller.

deleted 8y ago
[deleted]
chiefalchemist 8y ago
> "because after all the view is there for displaying the data that's in the model." I wouldn't disagree. But I also believe there's another way to look at the view, and that is as the interface between the application and the user. That UI has or needs to have (design) patterns, a la Atomic Design for example. http://atomicdesign.bradfrost.com/ http://atomicdesign.bradfrost.com/ For example, a list is a list is a list. In a well designed UI / UX that will follow / maintain a pattern. At that point, there's no real relationship per say to particulars in the model. The view / partial is "free standing" and can be repurposed as required. In the mind of the view, there is no model. Maybe I'm splitting a hairs and/or have gone off on a tangent? My apologizes.
- usrusr 8y ago
  I would conceptually put reusable view components ("a list representation") completely outside of the scope of all MV* thinking. The "V" part is a composition of high or low level view components, not the components themselves (at implemention time - at runtime the view is the sum of active components). When you write universally reusable view components, you are not implementing the V of an MV*, you are working on tools to implement a V. Just like writing a database engine isn't defining a domain model.
- mpweiher 8y ago
  Hmm... > a list is a list is a list. I would think that to be useful, a list will be a list of something. And that something will almost certainly be domain/model specific. Even if you expose just a list of strings, those strings will have some sort of semantic actions associated with them.
  - chiefalchemist 8y ago
    Yes. But it's not (or shouldn't be) a one to one between view and model. At least that particular view should be independent. Note: It was simply a basic example. The crux being to also look at the view from the frontend - user and frontend dev, and not only from the model forward. Fwiw I've recently taken over a project where I've found the same essentially partial four times. Not fatal, but more to maintain, as well as confusing when you're trying to unscramble things.

deleted 8y ago

[deleted]