从KnockoutJS用户的角度来看,Angularjs中的viewmodel及其结构是

发布时间：2020-12-17 16:58:29 所属栏目：安全来源：网络整理

导读：我有一个knockoutjs requirejs背景. 我切换到angularjs. 我不喜欢angularjs中的每个绑定属性只是附加到控制器内的$scope. 从使用angularjs的knockoutjs角度来看,我现在就这样做：创建customerviewmodel.js文件. 在里面我创建一个构造函数,如： function Cus

我有一个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很长时间的常见方法相比,我的方法在可测性/可扩展性/可维护性方面更糟糕吗？

解决方法

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

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

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

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

正如我的评论所述.我倾向于使用角度工厂而不是“新建”视图模型.但是,我在两个方面都做到了,它们似乎都有效.如果你看一个更大的角度项目(比如ng-grid),你可以看到他们定义的类比你描述的“newed-up”.

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

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

在角度中,范围很重要,因为它们定义了页面的层次结构,因此在动作发生时做出反应的重要性.所以,我会通过不覆盖范围来调整它,而是添加一个名为viewModel的范围属性：

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!