我切换到angularjs.
我不喜欢angularjs中的每个绑定属性只是附加到控制器内的$scope.
从使用angularjs的knockoutjs角度来看,我现在就这样做：
在里面我创建一个构造函数,如：
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的零经验,我的方法是否意味着我现在想不到的不必要的步骤或问题？
解决方法
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);
