JavaScript - Clientside分离Model和ViewModel?

时间:2016-07-25 13:11:50

标签: javascript model-view-controller mvvm knockout.js

already asked this question在另一个网站上,但由于它几乎没有得到任何关注(更不用说答案了),我希望它可能适合这里。

我正在使用Knockout.js的Model-View-ViewModel方法开发Web应用程序。在阅读John Gossman的original introduction of MVVM后,我意识到我的ViewModel总是包含所有应用程序的逻辑,不仅包括UI逻辑,还包含所有内容。

我已经阅读过使用Knockout的地方,该模型被认为是数据库或通常是服务器上的数据。但根据MVC,该模型还包含对该数据进行一些处理但与UI无关的函数。

所以我想知道一个独立于ViewModel对象的独立Model对象是否合理?这背后的想法是ViewModel将仅包含UI逻辑(如Gossman所预期的),并且Model仅包含业务逻辑(如在MVC中),这与实际的View无关。例如:

var viewModel = {
    hint: ko.observable("idle"), //text visible in the View
    buttonClicked: function () {
        this.hint("doing stuff");
        model.doStuff();
        this.hint("done");
    }
};

var model = {
    doStuff: function () {
        //business logic, UI independent
    }
};

是否有推荐或"最佳做法"哪个可以从MVVM模式定义派生出来?

2 个答案:

答案 0 :(得分:1)

我认为尝试将仅数据模型与viewModel分开会有点模糊,因为ViewModels可以包含' derived'列和模糊'模型之间的界限。以及视图中的视图需要'

我通常使用类(忘记你如何对它们进行分类)来封装从真实服务器端模型转换到我的视图将使用的viewModels ...包括派生列(例如FullName = FirstName + '' + LastName),数据转换(例如日期格式化),以及我可用于操作viewModel的函数。

实际上,你最终拥有嵌套的(每个都是一个' viewModel'本身)来封装复杂的实体并保持转换/功能与实体组织在一起他们与...有联系。请注意,操作数组的函数比它们修改的集合中的实体高一级。

所以书籍视图模型可能看起来像:

MainVM:
  Authors: observableArray
  AddAuthor: function
  RemoveAuthor: function

Author class: 
  FirstName
  LastName
  FullName: (derived)
  Books: observableArray
  AddBook: function
  RemoveBook: function

Book class: 
  Title
  ISBN
  PublishDate (function to format raw date)

此外,UI逻辑(例如,任何做DOM东西或Jquery的东西)都不属于任何地方......但是在自定义bindingHandlers或knockout扩展中。

答案 1 :(得分:0)

我认为将Knockout视为规范与实现之间的划分更为有用。 HTML文件在外观和行为方面完全指定了应用程序。绑定指定了一个必须实现的接口才能使应用程序正常工作。

JavaScript端的所有内容 - 您的viewmodel和任何自定义绑定以及任何底层代码 - 都是关于实现指定的接口。如何分解任务完全是一个实现细节。良好的编程实践表明,如果你有一些在多个地方都有用的例程,特别是如果它们在其他项目中有用,你应该创建一个库。这似乎一般适用于业务逻辑。