javascript - 客户端 MV* - 模型应该有保存方法吗？

Question

所以这是一个通用的模式问题，但我已经来回讨论了一段时间。

模型应该在 MV* 中有保存方法吗？

我经常在 Knockout、Ember，有时甚至是 Angular 之间来回切换，但我一直存在的一个问题是，模型是否应该在其类或原型(prototype)上有一个知道如何保存更改以减少依赖的保存方法服务上的应用程序(又名模型具有用于保存所有其他 View 模型/ Controller 通过了解模型继承的服务)或者是否应该有每个 View 模型/ Controller 所依赖的具有特定方法的服务保存对对象的更改？

示例 JavaScript 伪代码

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

对比

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

两者都实现了保存人的相同目的，但在示例 1 中， View 模型/ Controller 不知道服务或它是如何实现的，只是如果你想改变一个人，你就保存它。在示例二中，显然我们不仅要知道保存的方式，还要知道保存是如何实现的。

请在回答之前阅读此内容 -

我知道这是一个基于意见的问题，但如果你能用事实来支持你的意见，那将是事实，所以请引用支持任何声明，这样就不会因为“主要基于意见”而结束

Answer 1

这取决于模式(在我看来完全不是基于意见)。

• 您的第一个示例:具有 .save 方法的域对象称为 ActiveRecord (另见 here)。

• 您的第二个示例:数据映射层和域层之间的映射器称为 Repository (另见 here)

事件记录模式

引用福勒的话:

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

ActiveRecord 模式通常擅长原型(prototype)设计，有时在对象和数据库行之间存在 1-1 映射的非常小的应用程序中是个好主意。通常，您希望将持久化对象的逻辑与实际域对象的逻辑分开，因为它们本质上是不同的职责。

这是逻辑上处理数据持久性的最简单方法之一。

例如，这就是 Backbone 模型和集合使用它们的 sync() 方法所做的事情。这导致它们持久存在于服务器上。这通常是您看到较大的 Backbone 应用程序不完全使用 sync() 以支持实现自己的适配器的原因。毕竟，在 Backbone 世界中，它强制在您的 REST API 和您的域对象之间进行 1-1 映射，有效地使您的域对象和数据传输对象相同，随着您的应用程序的增长，这些对象会变得难以维护。

存储库模式

再次引用福勒的话:

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

对于大型应用程序，存储库通常是更好的设计模式，因为它从您的域对象中删除了持久性逻辑，因此它做得更好 separation of concerns .

在实现方面，存储库通常如下所示:

但是，对于它的用户来说，存储库可能看起来像:

作为任何抽象，另一个负责责任的对象有一些开销，但是 - 随着应用程序的增长，它开始得到返回。如果您使用 Angular 创建一个 $resource 并将其包装在一个服务中，该服务将这些对象从数据库查询映射到您的域对象(您的数据映射器)，然后像查询集合一样查询该服务——这就是一个存储库给你。