angularjs - 从 KnockoutJS 用户的 Angular 来看，Angularjs 中的 View 模型及其结构是什么

Question

我有 knockoutjs+requirejs 背景。

我切换到angularjs。

我不喜欢 angularjs 中的每个绑定(bind)属性都只是附加到 Controller 内部的 $scope 上。

现在从使用 angularjs 的 knockoutjs Angular 来看，我会这样做:

创建 customerviewmodel.js文件。

在里面我创建了一个构造函数，如:

function CustomerViewModel(dataFromServer)
{
   this.data = dataFromServer;
   // and many more properties
}

在我的 controller.js 中，我会这样做:

var dataFromServer = service.GetData();
$scope = new CustomerViewModel(dataFromServer);

我更喜欢这种方法，我将我的 UI-Logic 封装在单独的对象中，我可以轻松地对其进行单元测试，并且我不必创建 Controller 来对 UI-Logic 进行单元测试
这似乎很难，因为我必须模拟去网络服务器的服务调用......
此外，我可以在多个地方重用我的 customerviewmodel.js 文件，当每个属性都缝合到 Controller $scope 时，这怎么可能？

由于我对 angularjs 的零经验，我的方法是否意味着我现在无法想到的不需要的步骤或问题？

我的方法在可测试性/可扩展性/可维护性方面是否比人们长时间使用 angularjs 的常见方法更糟糕？

Answer 1

Does my approach implies unneeded steps or problems I can not think of now due to my zero experience with angularjs?

当 Controller 足够复杂时，我倾向于转向“完整” View 模型。如果我有很多关于如何构建与从服务器返回的数据不同的 View 模型的规则。或者，正如您所提到的，当您要呈现的数据只是服务器返回的数据的一小部分时。

Is my approach worse concerning testability/extendability/maintainability vs the common approach people do using angularjs a long time?

将 UI 数据关注点与服务器返回的数据分开会使您的代码复杂化(因为您有更多移动部件)。因此，可维护性略有下降。否则，可测试性保持不变并且稳定性增加。我的意思是您的 UI 表单等不直接绑定(bind)到服务器返回的数据结构。这意味着如果您的服务器数据契约(Contract)发生更改，您无需更改表单。这可以使应用程序更易于维护。

正如我的评论中提到的。我倾向于使用 angular.factory 而不是“更新” View 模型。但是，我以两种方式都做到了，而且它们似乎都有效。如果您查看更大的 Angular 项目(如 ng-grid )，您可以看到它们定义了 classes比你描述的"new"。

我要做的唯一其他评论是关于这段代码:

var dataFromServer = service.GetData();
$scope = new CustomerViewModel(dataFromServer);

在 Angular 中，范围很重要，因为它们在某种程度上定义了页面的层次结构，因此当一个 Action 发生时对什么使用react是很重要的。因此，我将通过不覆盖范围来调整它，而是添加一个名为 viewModel 的范围属性。 :

var dataFromServer = service.GetData();
$scope.viewModel = new CustomerViewModel(dataFromServer);