Client MV * - should the model have a save method?

Question

So this is a common template question, but I have been going back and forth for a long time.

Should the model have a save method in MV *?

I often jump back and forth between a knockout, Ember, and sometimes even Angular, but one of the constant questions that I always have is whether the model should have a method for storing a class or prototype on it that knows how to save changes to reduce dependencies around the application on services (for example, the model has a service to save that all other models / controllers inherit, knowing about the model) or there should be a service on which each of the models / view controllers depends, which has a specific method for saving changes What is the object?

JavaScript pseudo code example

var person = new Model.Person(); person.name = 'Bill'; person.save(); 

vs

 var personService = require('services/person.service'); var person = new Model.Person(); person.name = 'Bill'; personService.save(person); 

Both fulfill the same goal of saving a person, but in example 1, the model / view controller does not know about the service or how it is implemented only if you want to change the person, you save it. In Example Two, obviously, we need to know not only how to save it, but also how storage is implemented.

Read this before replying -

I understand that this is an opinion-based question, but if you can confirm your opinion with facts, it will be factual, so please refer to the backup copies of any claims so that it is not closed as “First of all, opinion-based”

Answer 1

It depends on the template (and not on the whole opinion based on imo).

• Your first example: a domain object that has a .save method is called ActiveRecord (also see here ).

• Second example: the mapping between data mapping and domains is called Repository (also see here )

Active Record Template

Quote from Fowler:

An object that wraps a string in a database table or view encapsulates access to the database and adds domain logic to this data.

The ActiveRecord pattern is usually highlighted during prototyping and is a good idea sometimes in very small applications where there is a 1-1 mapping between objects and DB strings. As a rule, you want to separate the logic of saving the object and the logic of the real object of the domain, since they are essentially different responsibilities.

This is one of the easiest ways to logically manage data storage.

For example, this is what Backbone models and collections do with their sync() method. This makes them persist on the server. Often the reason you see that larger server applications do not use sync() at all in favor of implementing their own adapters. In the end, in the Backbone world, it creates a 1-1 mapping between your REST API and your domain objects, which makes your domain objects and data transfer objects the same, which can be difficult to grow as your application grows.

Storage template

Re-quoting Fowler:

Intermediate interaction between the display layers of a domain and data using an interface similar to a collection to access domain objects.

A repository is usually the best design pattern for larger applications, as it removes the persistence logic from your domain object, so it is better to separate problems .

The implementation is reasonable, the repository usually looks like this:

However, for its users, the repository might look like this:

Like any abstraction, another object of responsibility has some overhead, however - as the application grows, it begins to pay off. If you create $resource using Angular and transfer it to a service that maps these objects from the db request to your domain objects (your data converter) and then requests this service, such as a collection, this is the store for you.

Answer 2

The short answer in my personal opinion will be your second version. I usually think that the viewmodel on the client is basically a bag of data or properties. Services are used to save / retrieve these view modes on / from the server, and the controller is responsible for using the service methods and visualization of the presentation. In Angular.js, world directives will handle any DOM-specific behavior, but I think that ultimately the events that occur as a result of interacting with the user interface (saving, checking, etc.) will be handled by the controller (maybe by calling the service method).

I formulated this opinion when I started using Angular.js and went through my design documentation. Shortly speaking:

Use controllers to:

• Set the initial state of the viewmodel
• Add behavior to viewmodel

Do not use controllers for:

• Manipulate DOM - Controllers should contain only business logic.
• Format entry
• Filter output
• Manage the life cycle of other components (for example, to create instances of a service).

Use services to organize and share code and status in an application.