What's about the Model?

[glyad]

Hi @Andrei15193,

Nice work anyway! ...but:

You forgot about Model. The MVVM pattern requires to implement the Model facilities or it isn't MVVM really.

1. In all of the members of MV* patterns family the M[odel] is on first place and seems as a central of the world and MVVM isn't exception from that rule. The M acts as a single source of truth in the whole application.
2. What is model really?

• It answers to all of requirements of the application functional spec including all of business logic of the application;
• It includes both entities definitions (e.g., POJO or POCO classes) and entity manipulation services (stores, mediators, etc.) as well;
• The Model infra must support identity of entities. The typical entity interface is IModel, where T is the type of the id property;
• The good Model framework implementation may include a ValueObject pattern implementation to support immutable types, e.g., an id.
• All of validation rules must be declared on entities. Ideally validation rule should be decorator on property (e.g., @min(5) @max(10)). It's because the VM is only abstraction of the View or a state of the View;
• The Model infra must support undo/redo automatically (memento pattern);
• The good style is that Model (Service) represents a single point of asynchronous operations;
• You may see a model like as an independent part of the application. The good model should be [potentially] reusable, because it has no dependencies on View staff.

3. Various kinds of ViewModels:

• Application (or Navigation, or root-level) ViewModels. Those are ViewModels, which are subjects of composition. The lifecycle of such kind of ViewModels usually includes a sequence of following events: activating (usable to prevent navigation to component/page), activated, deactivating (to prevent navigation from the component, if some data not saved, for example), deactivated;
• Entity (or Object) Wrappers ViewModels. Those ViewModels are wrapping Model entities and provides entity instance to View with Model getter property. In addition, the abstract class ObjectViewModel<TModel> inheritors may provide implementations of the Commands like as "Save" or "Undo". The lifecycle of those VM's must include projection of the composable component, like as an InvoiceLineItemViewModel in front of InvoiceLineItemView (component).

4. An additional word about MVVM implementation. MVVM is a pattern. When we are talking about patterns, we are talking about separation of concerns. In other words, we expect from MVVM strong separation between its three subjects. So, to satisfy this requirement you need an engine to locate the View by ViewModel. It's also known as ViewModel-first approach. The good architecture is testable architecture. How can you test each layer of the application built on your framework separately (isolated)? E.g., how you test a VM without to involve the View and Model into the process? You need to use DI to separate VM from Model and Model from the Data Layer. So, you will be able to substitute various data providers for the Model, like as FakeDataProvider, RestDataProvider, or GQDataProvider.
5. Etc....

Anyway, your framework is very interesting as an initial point of the subject. I'll be very glad to talk (to discuss) to you, if you want.

[Andrei15193]

Hi,

Thank you for taking the time to write, I really appreciate it. It shows that people are taking an interest in this.

You are correct, this library does not address the Model at all and mostly provides the ViewModel infrastructure for React components, making this rather a library than a framework.

The Model is generally very specific to the domain that the application addresses and there are multiple approaches on how this can happen. From a purely functional one to Domain Driven Design and pure object oriented, it really depends on the application and what it wants to solve. This is the reason I haven't included anything about the Model as it is very difficult to pin what would be something common across all. Even with the ID of an entity, is it a number? Is it a string containing a GUID/UUID? What about composite keys, generally used for many-to-many relationships?

Validation can come in many shapes and forms. The Model should always be in a valid state after any method call (the method itself may update the model allowing it to have intermediary invalid states, but it is all encapsulated inside the method), this can be enforced through validation rules, like you suggested using decorators, or cover for more complex scenarios using a validate method or even a validator depending on how much we want to separate things.

Sometimes it is difficult to run a full validation on the entire model leaving developers to ensure that it is left in a valid state, this means that all inputs that may change the model are validated so that when the changes are applied it is left in a valid state (similar to Model Checking but done manually, this usually happens when there are related entities involved, we don't fully check the related entities and just assume they are valid). This leaves the form implementation to handle all validation which connects the Model and the View through a ViewModel. This is something that ViewModels can do, as opposed to Models, is to have intermediary invalid states and provide error information about that. The error information does not really belong to the Model as it should always be valid, but it makes total sense for a ViewModel.

In my opinion, I think the ViewModel is the most critical part of an MVVM implementation. Any bad Model design will be generally bad with any UI pattern, regardless of how much we try to isolate it we still have to deal with it. A good Model design will work well with any UI pattern leaving the choice of the UI pattern to be the appropriate one for the type of interaction that is desired. Sometimes it's MVVM, other times it's MVC, and on other occasions it's Flux, and others.

In my experience, the quality of an MVVM implementation rests on the quality of ViewModel design. Again, if the Model design is bad, that can leak into ViewModel design as well, but that is generally applicable with any pattern not just MVVM. This is why the accent of this library is on the ViewModel and not the other two parts, the View is handled by React, while the Model is not handled at all as it is very loosely defined to begin with. If you want MVVM, you need a good ViewModel infrastructure that works well with your View layer. The mapping between ViewModels and the Model is handled by the former (load and save methods).

I wouldn't necessarily map a single View to a ViewModel as the same ViewModel can be consumed by multiple Views. For instance, a list of items can be shows as a table, or just as a list. Different Views, same ViewModel. To find the View by the ViewModel is something that should be done outside of the ViewModels themselves and it's something that is part of the View layer. A presenter component or something like that which knows about these mappings and picks the right View for a given ViewModel.

From what I've noticed there are around 3 categories of ViewModels, global ones that are generally scoped to the lifecycle of the application (e.g.: handling notifications), display ones that are just able to load some data and provide it in a way that is easy to present (picking translation keys, tidying up the structure to what is just being presented and not the entire Model, maintaining that structure as the Model changes) and the most complex ones, edit ViewModels.

These are basically form representations, forms that are defined and live outside of the View and presented in one or multiple Views (1 form page, 1 form page with tabs, wizards/multi-step forms). They are not only able to load and provide information in a presentable way, but they also handle validation. In some cases, it's just a range check for numbers or dates, or lengths for text fields, in other cases fields have dependencies between them (the end date cannot be before the start date, or a list of items must have unique names). All of this is done by ViewModels to both define the form (what is editable) and validate it. Once we submit the form, we basically save the changes which in turn update the Model, but only at that point, not a moment before as we always need the Model to be in a valid state. The ViewModel can keep going in and out of valid states, but nothing is really being saved at that point, it's just work in progress.

[glyad]

I need a time to answer it. Sorry! I have overloaded those weeks. Anyway,... to be continued... :)

BTW... Some interesting solutions you can in Aurelia framework, which is pure MVVM framework. Anyway, it lacks Model facilities too. I implemented missing VM and M things in my own library @logofx/aurelia-mvvm-plugin
. I'll be very glad, if it's somehow helpful in your case.

[Andrei15193]

It's ok, I am glad you did write the comment because I was beginning to wonder if I would hear back from you 🙂

I have heard of Aurelia framework but never looked into it or what it does. At a glance it does look interesting and there can be useful information, thanks!

[Andrei15193]

I've added discussions to the repository, they seem really neat and I think the questions you raised are better suited for that space. They are more or less the same, however there is an emphasis on having conversations, I'd like to keep the issue tracker strictly for issues from now on.

I'll be moving this over there.

[glyad]

... and I will be very glad to follow you!