Gus*_*dim 23 model-view-controller design-patterns server-side client-side mvvm
考虑到最流行的MVC/MVVM客户端模式(如Knockout.js,Angular.js,Ember.js等),我有一个很大的疑问:
还要考虑双方的建模冗余,将这些客户端模式与MVC服务器端模式一起使用的优点和缺点是什么？
Jas*_*tti 14
我一直在努力解决这个问题...希望这有助于,即使它是一个圆形的方式.
虽然已经说明了一些优点/缺点,但我认为最好的解释是在这个答案中.
对我来说,使用客户端逻辑的最大优势是丰富的UI方面.
但你问题的关键部分似乎是"模型冗余"(我称之为重复逻辑,或者至少具有重复逻辑的潜力).在我看来,这是一个可能独立于前一个链接的优点/缺点的问题.
首先,我认为是否应该使用客户端框架的决定应该基于充分记录的优缺点.做出决定后,可以解决相关问题.
让我们假设您正在使用某种服务器端框架/平台,以及客户端框架来提供一些UI交互性.现在将模型逻辑放在何处存在问题:在客户端,服务器或两者上.
解决问题的一种方法是仅在客户端或服务器中定义模型逻辑.然后你没有代码重复,但它会影响一些更高级别的优点/缺点.
例如,如果模型逻辑是100%服务器端,则会丢失UI的某些交互式部分.或者,你经常把模型扔进/从服务器扔掉,这将有一些缺点.
如果您的模型逻辑是100%客户端,则可能会遇到性能问题,具体取决于视图/模型的大小.这是Twitter转向服务器端处理模型的原因之一.
然后就是"两者"......在客户端和服务器中都存在模型逻辑.我认为这是最好的解决方案,只要没有重复的逻辑.
例如,在购物车页面上,您可以根据产品价格和用户可编辑的数量框重新计算订单的成本.我认为这种逻辑应该只存在于客户端上.一旦加载就不会更改的其他模型属性可能很好地托管在服务器上.
这里有很多灰色区域......我很努力将所有鸡蛋放在一个篮子里.例如,选择客户端框架,创建大量客户端逻辑,然后[假设]遇到性能,浏览器支持或类似问题.现在你可能想调整一两页的性能(比如移动服务器端,推特).但我认为,如何构建代码是明智的,这有助于缓解这个问题.如果您的代码可维护且干净,那么将逻辑从客户端移动到服务器并不困难.
优点是客户端模式适用于服务器无法直接访问的客户端.如果您正在构建一个丰富的交互式HTML UI,那么请使用客户端MVVM.在这种情况下,服务器端MVC可能仍然与向客户端传送适当的内容相关.例如,ASP.NET WebAPI是一个用于创建HTTP API的框架,它具有与ASP.NET MVC框架类似的控制器体系结构.使用此框架实现的API可以由客户端代码调用,从而在服务器端生成MVC,在客户端生成MVVM.通常,当使用MVC服务器端和MVVM客户端时,各方的职责非常不同,因此没有冗余.