从 KnockoutJS 用户的角度来看，Angularjs 中的视图模型及其结构是什么

Question

我有一个knockoutjs+requirejs背景。

我切换到 angularjs。

我不喜欢 angularjs 中的每个绑定属性都只是附加到控制器内的 $scope 。

现在从使用angularjs的knockoutjs角度来看，我只会这样做：

创建一个customerviewmodel.js文件。

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

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

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

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

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

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

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

Answer 1

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

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

与人们长期使用 angularjs 的常见方法相比，我的方法在可测试性/可扩展性/可维护性方面是否更差？

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

正如我的评论中提到的。我倾向于使用角度工厂而不是“更新”视图模型。然而，我已经用这两种方式做到了，而且它们似乎都有效。如果您查看更大的角度项目（例如ng-grid），您可以看到它们定义的内容classes比您描述的“更新”的内容要多。

我要发表的唯一评论是关于这段代码：

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

在 Angular 中，范围很重要，因为它们定义了页面的层次结构，因此在发生操作时做出反应很重要。因此，我会通过不覆盖作用域来调整它，而是添加一个名为 的作用域属性viewModel：

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