有名无实的RouterASP.NET MVC如果你还没有接触过后端的MVC框架的话,不妨先看看下面这段ASP.NET MVC代码并且了解一下后端MVC的工作原理。它摘自ASP.NET MVC教程中非常著名的项目MVC Music Store一段Controller组件代码: public class StoreManagerController : Controller { private MusicStoreEntities db = new MusicStoreEntities(); // GET: /StoreManager/ public ViewResult Index() { var albums = db.Albums.Include(a => a.Genre).Include(a => a.Artist); return View(albums.ToList()); } // GET: /StoreManager/Details/5 public ViewResult Details(int id) { Album album = db.Albums.Find(id); return View(album); } } 我们知道Controller的职责之一是负责响应用户在视图上的行为,而具体每个行为应如何进行响应,需要落实到Controller具体的方法上,这个方法我们可以称之为action。上面代码中的两个公开方法 但问题来了,如何将用户在视图上的行为,与响应行为的方法action关联起来?甚至与Controller关联起来? URL便是方法之一。上面代码每个action上的注释便代表这个这个action对应的URL。也就是说,当用户点击该URL时,框架中的Router服务便能通过URL解析出应该调用哪个Controller及该Controller下的哪一个action进行响应,以上面的例子为例,可以知道URL的规则为 那么响应的结果应该是什么呢?从上面的代码 举一个最熟悉的现有MVC站点的例子便是github。你会发现你在github网站上的每一处点击都有唯一的URL对应,每一次交互的结果都是服务器返回新的页面。它使用javascript非常少,比如当你选择编辑时,它也会跳转到一个新的页面,而非在当前页弹出一个编辑框。 为什么首先要聊这么多的服务器端MVC框架的特性。因为接下来回过头来看前端的MVC框架时,你会发现有非常多的差异之处。 Javascript MVC从上面可以看出,服务器端的MVC框架服务的是整个站点,它依靠不断的返回页面来响应用户请求,因此Router服务至关重要。而使用MVC框架的前端页面,大多数是Single Page Application,甚至还不如单页面,只是页面上的某一个组件,比如一个Slide。因此将用户的行为转化为URL是不现实。你或许会说的确无法生产新的页面,那么降低页面粒度如何呢?也就是说在服务器端一个URL映射的是一个页面,那么我们将URL映射为页面的某个区域或者功能呢? 比如以下面这段Backbone.js的TodoList应用Router为例: var TodoRouter = Backbone.Router.extend({ routes: { 'todo/add': 'add', // 新增项 'todo/edit/:id': 'edit', // 编辑项 'todo/remove/:id': 'remove', // 删除项 'filter/completed': 'filterCompleted', // 过滤出已完成 'filter/uncompleted': 'filterUncompleted' // 过滤出未完成 } // Todo }); 如果依照这样Route规划,我们希望当用户输入 但是这样会引起另一个问题,注意上面route的差别: 这样的设定明显是不合理的。之所以会产生这样的问题是因为对后端而言URL与页面是一一对应的关系。而如果降低页面粒度的话,无法将页面功能与URL对应起来,或者说如果想让URl覆盖单一页面上的所有功能的成本太高了。 前端的解决之道当然Route在前端MVC框架中并非武功尽废,我们仍然可以保留这样的机制,但是仅用于高粒度的操作,比如上面例子中的筛选功能。 其实Route仅仅是桥梁,将用户的行为与响应用户行为的方法联系起来。Route机制已经在前端行不通了,问题便是寻求另一种联系的机制。 Observer Pattern + MVGoogle程序员Addy Osmani(同时也是Learning JavaScript Design Patterns的作者)有一个非常著名的项目——Todomvc。他用所有的前端MVC框架将Todo List这个app重写了一遍。我们看看他的解决这样的问题的。 Backbone以Backbone.js为例,为了方便说明,在他的基础上我再次进行了简化,简化到只有50行代码,只保留了新增和删除方法。实际演示效果在这里: var Todo = Backbone.Model.extend(); var Todos = Backbone.Collection.extend({ model: Todo }); var todos = new Todos(); var ItemView = Backbone.View.extend({ tagName: "li", template: _.template($("#item-template").html()), render: function () { this.$el.html(this.template(this.model.toJSON())); return this; }, initialize: function () { this.listenTo(this.model, 'remove', this.remove); }, events: { "click .delete": "clear" }, clear: function () { todos.remove(this.model); } }); var AppView = Backbone.View.extend({ el: $("body"), initialize: function () { this.listenTo(todos, 'add', this.addOne); }, addOne: function(todo) { var view = new ItemView({ model: todo }); this.$("#list").append(view.render().el); }, events: { "click #create": "create" }, create: function () { var model = new Todo({ title: this.$("#input").val() }); todos.add(model); } }) var app = new AppView(); 这个应用有两个视图,全局视图`AppView`和单个项目视图`ItemView`,还有一个相当于Model层的Collection`todos`。它没有显式的将Controller层独立出来。你可能会说Backbone不像Angular和Ember,它本就没有Controller的设定,我不这么认为,Backbone里Router就是Controller与Router的结合体。比如它可以加入一个Router这么干: var TodoRouter = Backbone.Router.extend({ routes: { 'todo/add': 'add' }, add: function () { // do something } }); 翻译过来是: 回到这个应用,它没有将Controller显式的独立出来并不代表Controller不存在。我们需要的不是一个叫做Controller的东西,而是一些能够响应用户行为的方法。那么它把Controller放在哪了?它使用了的是最原始的解决办法,放在用户行为事件的回调函数中,比如这段代码: events: { "click #create": "create" }, create: function () { var model = new Todo({ title: this.$("#input").val() }); todos.add(model); } 虽然这种方法比较原始,但不应该认为它是一种低级的解决方案。当然接下来我们会在Emberjs和Knockoutjs看到一些其他的解决方法,从职责上来说,他们的目的是一致的。 回想在文章开头介绍的ASP.NET MVC的一个action,它做了哪些事情: public ViewResult Details(int id) { // 执行了Model层的查找(query)操作 Album album = db.Albums.Find(id); // 将查找返回的结果传递给视图(View) return View(album); } 用户的操作会涉及数据和视图更改,一般来说视图会被动一些,Model的修改可以通知视图的更新,当然视图也可以向Model请求数据(注意从这里可以看出Model与View可以直接通信而非通过Controller)。上面的代码很好的说明了这一点,并且视图的更新和数据的操作都是在同一个action里完成。 但是前端MVC框架却不这么做。 因为在前后端代码与视图的关系是不同的,后端代码生产出页面交给浏览器之后,基本上就不关心也无法关心页面了;而在前端不同,虽然前端也有“生产”这么一说(比如说使用模板引擎),但前端代码时刻都可以对Html代码和DOM元素进行监听和操作。 上面的Todo里Backbone是这么做的: var AppView = Backbone.View.extend({ el: $("body"), initialize: function () { // 在初始化该视图时(执行当前initialize函数), // 它会对这个应用唯一的Model层,就是Collection`todos`进行监听; // 更准确来说是对它的新增操作进行监听 // 一旦发现数据有新增操作,那么更新视图(调用addOne方法) this.listenTo(todos, 'add', this.addOne); }, addOne: function(todo) { var view = new ItemView({ model: todo }); this.$("#list").append(view.render().el); } 这个时候你再看看这个AppView的代码会觉得有一些绕,因为我们明明可以在create方法中,在新增数据之后立即调用更新视图的方法: create: function () { var model = new Todo({ title: this.$("#input").val() }); todos.add(model); // 更新视图 // this.addOne(model) } 但我想这么做的原因无非是为了解耦。考虑今后可能增加多个新增数据的入口(如create1, create2, create3),在每一个新增方法中调用更新视图的方法会增加代码的维护量,那么就不如采用这种观察者模式(Observer pattern)(或者采用fire事件机制也行),只在指定处更新视图。 ItemView采用的也是同样机制,就不在这里赘述了。 值得一提的是,todomvc Backbone的原版本中仍然保留了Router服务: var TodoRouter = Backbone.Router.extend({ routes: { '*filter': 'setFilter' }, setFilter: function (param) { // Set the current filter to be used app.TodoFilter = param || ''; // Trigger a collection filter event, causing hiding/unhiding // of Todo view items app.todos.trigger('filter'); } }); 如果有兴趣浏览一下原版代码,你会发现这只是作为更新视图的触发器而已。 Ember.js不仅仅Backbone采用这样的机制,我们也可以看看todomvc中简化过后的Emberjs代码,采用的也是同样机制,线上DEMO: Html: <script type="text/x-handlebars" data-template-name="index"> {{ input type="text" value=title }} <button {{action "create"}}>Add</button> <ul> {{#each item in content itemController="todo"}} <li> <span>{{item.title}}</span> <button {{action "remove"}}>delete</button> </li> {{/each}} </ul> </script> Javascript: App = Ember.Application.create({}); App.ApplicationAdapter = DS.LSAdapter.extend(); App.Todo = DS.Model.extend({ title: DS.attr("string") }) App.IndexRoute = Ember.Route.extend({ setupController: function(controller) { var todos = this.store.find('todo'); controller.set("content", todos); } }); App.TodoController = Ember.ObjectController.extend({ actions: { remove: function () { var todo = this.get('model'); todo.deleteRecord(); todo.save(); } } }) App.IndexController = Ember.ArrayController.extend({ actions: { create: function () { var title = this.get("title"); var todo = this.store.createRecord('todo', { title: title }); todo.save(); } } }); 这一段代码不做详解,与前一个Backbone的机制是一致的,需要注意的是:
MVP(Passive View)Addy的解决方案是Observer Pattern。但我更提倡另一种解决方案,MVP(Model-View-Presenter)模式中的Passive View模式。 为什么会有MVC,MVP,甚至MVVM?三个模式其实主要围绕的是两个问题:
同时参考Kjell-Sverre Jerij?rvi提出的MVP的设计原则Design Rules for Model-View-Presenter,可以找到MVP模式中一些非常重要的特征,例如以下几条:
既然Presenter对于View是相对透明的,View不能直接对Presenter进行操作(目的是实现Presenter和View之间的分离)。那么如何实现View与Presenter层之间的通信呢——通过注册事件,在Presenter上注册View的事件,并且这样以来数据的传递就不是View向Presenter去“拉(pull)”,而是Presenter“推(push)”给View层。 所以我们的目标非常的简单,分别定义三个层:
实现代码如下: var Todo = Backbone.Model.extend({ }); var Todos = Backbone.Collection.extend({ model: Todo }); var ItemView = Backbone.View.extend({ tagName: "li", template: _.template($("#item-template").html()), render: function (container) { this.$el.html(this.template(this.model.toJSON())); container.append(this.$el); }, events: { "click .delete": "_clear" }, _clear: function () { this.$el.trigger("delete", this); } }); var AppView = Backbone.View.extend({ el: $("body"), events: { "click #create": "_create" }, _create: function () { var data = { title: this.$("#input").val() }; this.$el.trigger("create", data); } }) var Presenter = Backbone.View.extend({ el: $("body"), initialize: function () { this.appView = new AppView({ container: $("#list") }); this.todos = new Todos; var _this = this; this.$el.on("create", function (e, attrs) { var model = new Todo(attrs); _this.todos.add(model); var itemView = new ItemView({ model: model }) itemView.render($("#list")); }); this.$el.on("delete", function (e, view) { _this.todos.remove(view.model); view.remove(); }); } }) var p = new Presenter; [DEMO](http:///JPL94/8/) 让我们来看看它是否复合我们的要求:
上面的两个例子我们可以看到,介于前端的特殊性,在前端MVC框架中View层与Controller层中的action联系较为密切,例如把action注册到视图元素的事件回调中。虽然这样能够代替服务器端的路由方案,但代价是牺牲了不同层之间的低耦合性,并且不易测试。 MVP在MVC的基础上,进一步进行了解耦,把视图和数据抽象仅剩下接口,并且把业务逻辑全部归纳到Presenter层中。这样不仅能够把View单独拎出测试,还能提高这一套MVP组件的可复用性。如果我们想更换View层或者Model层的话,只要保证新层具有与原层相同的接口,而不用涉及到其他层的修改。 MVVM最后一个解决方案是MVVM(Model-View-ViewModel),以Knockout.js为例,完成相同功能只需要非常少的代码: Html: <input type="text" data-bind="value: title"> <button data-bind="click: create">Add</button> <ul data-bind="foreach: todos"> <li> <span data-bind="text: title"> </span> <button data-bind="click: $root.remove">delete</button> </li> </ul> Javascript: function Todo (title) { this.title = title; } var ViewModel = function() { var _this = this; this.todos = ko.observableArray([new Todo("test1"), new Todo("test2")]); this.title = ko.observable(); this.create = function () { var title = this.title().trim(); if (title) { _this.todos.push(new Todo(title)); } } this.remove = function (todo) { _this.todos.remove(todo); } }; ko.applyBindings(new ViewModel()); [DEMO](http:///mfUVk/) 在MVP与MVC模式中,用于渲染视图的数据往往是action处理Model层返回的数据之后的结果。而MVVM中的ViewModel则是视图所需要渲染数据的直接映射,无需再经过其他服务的处理。 我不确定MVVM在WPF中(MVVM起源于微软Windows Presentation Foundation框架)是如何处理ViewModel层方法与数据的关系。但是从上面Knockoutjs的代码可以看出,ViewModel的代码是比较混乱,方法和属性都书写在一起。其实从html的绑定方式也可以看出,无论是数据还是action,都一视同仁的使用 虽然Knockout的代码写起来很舒服(我们近乎只用关心Model层的数据操作),但这样的代码无疑对代码的复用和维护提出了挑战。仅作参考,不作推荐。 参考文献: |
|
来自: wayne_liberary > 《技术博文》