【问题标题】:Use client-side MVC/MVVM patterns with MVC server-side pattern将客户端 MVC/MVVM 模式与 MVC 服务器端模式结合使用
【发布时间】:2012-07-30 15:46:55
【问题描述】:

考虑到最流行的 MVC/MVVM 客户端模式(如 Knockout.jsAngular.jsEmber.js 等),我有一个很大的疑问:

同样考虑到双方的建模冗余,将这些客户端模式与 MVC 服务器端模式一起使用有什么优点和缺点?

【问题讨论】:

    标签: model-view-controller design-patterns mvvm client-side server-side


    【解决方案1】:

    优点是客户端模式适用于服务器无法直接访问的客户端。如果您正在构建丰富的交互式 HTML UI,请使用客户端 MVVM。在这种情况下,服务器端 MVC 可能仍然与向客户端提供适当的内容相关。例如,ASP.NET WebAPI 是一个用于创建 HTTP API 的框架,它具有与 ASP.NET MVC 框架类似的控制器架构。使用此框架实现的 API 可以由客户端代码调用,从而在服务器端产生 MVC,在客户端产生 MVVM。通常,在使用MVC服务器端和MVVM客户端时,各自的职责是非常不同的,因此没有冗余。

    【讨论】:

      【解决方案2】:

      您将 MVVM 模型合并到已经实现的 MVC 框架中也是一件好事,我们最近在一些新项目页面中添加了淘汰赛以适应已经过时的 MVC 框架(旧页面,而不是框架本身) .

      我认为 MVVM 非常棒,因为上述答案表明它提供了卓越的用户体验和极快的响应时间,您可以在后台隐藏验证调用而不会减慢它们的速度,而且它很直观。

      然而,痛苦在于单元测试非常困难,而且您可以获得一些非常大的 javascript 文件,而且由于我们的遗留系统仍然在 IE6 上运行,我们不得不做的额外编码是荒谬的。

      但 MVVM 和 MVC 不必单独使用,我们两者都使用。但是有 3 个级别的验证仍然让我感到困扰。

      【讨论】:

      • 我注意到您的第二次表扬,您已经在考虑在项目中同时使用这两种方法,抱歉!
      • 感谢您的回答,在我的项目研究中会非常考虑。很快我会选择最佳答案。再次感谢!
      • 在您的第二段中,您似乎暗示使用 MVVM 与客户端模式相同。事实并非如此。 MVVM 可用于服务器端或客户端。
      【解决方案3】:

      我为如何回答这个问题而苦恼……希望这会有所帮助,即使它是以迂回的方式。

      虽然已经说明了一些优点/缺点,但我认为最好的总结是this answer

      对我来说,使用客户端逻辑的最大优势是丰富的 UI 方面。

      但是您问题的关键部分似乎是“模型冗余”(我将其称为重复逻辑,或者至少具有重复逻辑的潜力)。在我看来,这是一个可能独立于上一个链接中的优缺点而存在的问题。

      所以首先,我认为是否使用客户端框架的决定应该基于有据可查的利弊。一旦做出决定,相关的问题就可以得到解决。

      假设您正在使用某种服务器端框架/平台,以及一个客户端框架来提供一点 UI 交互性。现在,模型逻辑的放置位置存在问题:在客户端、服务器或两者上。

      解决问题的一种方法是仅在客户端服务器中定义模型逻辑。那么你没有代码重复,但它会影响一些更高级别的优点/缺点。

      例如,如果您的模型逻辑 100% 是服务器端的,那么您会丢失一些 UI 的交互部分。或者,您不断地向服务器发送模型或从服务器发送模型,这会有一些缺点。

      如果您的模型逻辑是 100% 客户端,您可能会遇到性能问题,具体取决于您的视图/模型的大小。这是 Twitter 转向服务器端处理模型的原因之一。

      然后是“两者”......在客户端和服务器中都存在模型逻辑。我认为这是最好的解决方案,只要不重复任何逻辑

      例如,在购物车页面上,您可以根据产品价格和用户可编辑的数量框重新计算订单成本。我认为这个逻辑应该只存在于客户端。加载后不会更改的其他模型属性可能很好地托管在服务器上。

      这里有很多灰色区域......我很难将所有鸡蛋放在一个篮子里。例如,选择客户端框架,创建大量客户端逻辑,然后 [假设地] 遇到性能、浏览器支持或类似问题。现在您可能想要调整一两个页面以提高性能(例如将其移动到服务器端,例如 Twitter)。但我认为明智地构建代码将有助于缓解这个问题。如果您的代码是可维护且干净的,那么将逻辑从客户端移动到服务器不会很困难。

      【讨论】:

      • 只要没有逻辑重复”这句话回答了所有问题。
      【解决方案4】:
      • 优势
        • 这可以摇滚。
      • 缺点
        • 你可以搞砸了。

      说真的。利用将部分前端逻辑传输到浏览器中可以促进您的应用程序开发,为什么您将更严格的数据处理封装在服务器端。

      这基本上是分层的。两层,上一层与下一层对话,反之亦然:

      [client] <--> [server]
      

      您通常以轻量级序列化格式(如 Json)在两者之间交换值对象。

      这可以很好地映射用户对有用结构的期望,而服务器端的域对象不能那么详细。

      但是,如果服务器端在某些时候不是用 javascript 编写的,那么真正的力量将是,因为我认为您无法在那里创建良好的域对象。如果遇到该问题,请考虑使用 Scala(或类似的表达方式)然后

      【讨论】:

        【解决方案5】:

        在提出这个问题十个月后,我在同一个应用程序中使用了这两种模式。

        唯一的问题是需要两次映射模型。

        MVC(ASP.NET MVC 4 Web API)

        最重要的资源是路线。

        • 为数据库交互和作为参数创建模型 管制员的行动。
        • 创建了控制器来操作 API 申请并呈现意见。
        • 视图未建模 服务器端模型,但部分视图的所有资源和 部分。

        MVVM (Knockout.js)

        • 创建的模型具有与服务器端模型相同的属性。
        • 视图与模型的属性绑定,并减少了很多视图的大小。
        • 视图模型是使用 API 方法提供的值创建的。

        总体而言,MVC 与 MVVM 的组合非常有用,但它需要大量的专业知识和知识。耐心也是需要的,因为你需要考虑每个应用层的职责。

        【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2012-10-15
        • 2012-05-23
        • 1970-01-01
        • 2019-11-08
        • 2012-07-04
        • 2013-02-20
        • 2013-04-24
        • 2017-04-30
        相关资源
        最近更新 更多