使用MVVM模式的Asp .NET Web API

时间:2017-03-22 17:36:33

标签: asp.net asp.net-mvc asp.net-web-api mvvm

我试图了解如何将MVVM模式用于CRUD操作。目前我的API控制器中有方法,如下所示。我的问题是:使用MVVM模式,我是否还应该构建我的api(例如,访问数据库)?还是应该改变?如果没有任何变化,在这种情况下我会实现ViewModels以及它们应该如何由API管理?我做了一些研究,但对我来说还不清楚。

public IHttpActionResult GetProduct(int id)
{
    var product = _context.Products.SingleOrDefault(p => p.Id == id);
    return Ok(product);
}

[HttpPost]
public IHttpActionResult CreateProduct(Product product)
{
    ...
    _context.Products.Add(product);
    _context.SaveChanges();

    return Created(new Uri(Request.RequestUri + "/" + product.Id), product);
}

2 个答案:

答案 0 :(得分:4)

我认为问题的一部分是你不了解MVVM在Web应用程序中的作用。要理解,您必须将Web应用程序视为由两个独立的应用程序组成 - 服务器端和客户端。

服务器端,正在使用的模式是MVC(这并不奇怪,出于某种原因,它被称为ASP.NET MVC)。如果你试图让你对MVC模式的MVVM有所了解 - 不要。它不适用。服务器上的MVC模式易于理解和实现;不要试图将任何MVVM加入其中。只需使用服务器端模式设计服务器端代码即可。

客户方是另一回事。默认情况下,使用Razor页面的ASP.NET MVC会在服务器上呈现HTML并将其传递给客户端以供显示。而且,通常,HTML旨在通过回发到服务器来响应用户与页面的交互。您的控制器方法解释这些回发,执行所需的逻辑,并呈现正确的剃刀页面作为响应。但这不是编写网站的唯一方法。

越来越常见的是,人们正在设计单页应用程序。它们使用ajax回调将用户操作的结果发送回服务器,然后处理响应。在服务器端,这些请求几乎总是通过WebApi控制器方法处理,而不是ASP.NET MVC控制器方法。该请求以ajax的形式出现,并且结果通常以ajax的形式返回。没有HTML呈现。这就是MVVM发挥作用的地方。

客户端,这些网页通常使用javascript MVVM(ish)框架,如knockoutjsangular。响应json用于更新绑定到网页中HTML元素的视图模型。这些框架处理UI和这些视图模型之间的同步更新和用户操作,就像Bindings在WPF中的UI和视图模型之间同步更新一样。

简单地说,MVC是它自己的东西,MVVM通常只存在于网站的客户端,通常只有当网站广泛使用ajax回调而不是回发时。

而且,要回答您的直接问题,如果您在客户端使用MVVM,使用ajax调用来执行CRUD操作,则应将WebApi控制器方法设计为Post / Get / Put / Delete数据。

答案 1 :(得分:1)

就个人而言,我总是使用存储库模式来处理与CRUD操作有关的任何事情,例如与数据库中的实体进行交互。

我将创建一个名为“ProductRepository”的单独类,并将所有方法放在该类中获取,创建,更新和删除产品。这样,只有您的Respository关心与数据库交互和对其执行CRUD操作的详细信息。您的整个应用程序不应该关心如何完成此操作,只关心您的Repository类。这就是所谓的单一责任原则。它是设计和架构“SOLID”原则的一部分。

然后,在您的Controller或ViewModel中或者您需要它发生的地方,您只需要实例化ProductRepository并在整个应用程序中使用它的方法。

如果您为服务层和数据访问层使用单独的Web API,那么您实际上并不需要MVC。您只需要一个前端框架来使用Web API URL,例如AngularJS或您选择的任何其他JS框架。

如果你想使用MVC,那么你真的不需要Web API。您可以将服务层和数据访问层构建到MVC应用程序中,或者将它们构建为单独的项目(类库)并将它们包含在整个项目解决方案中。这一切只取决于您希望架构如何以及您想要使用它的复杂程度。

但无论哪种方式,都应该涉及“ProductRepository” - 无论是在你的Web API中(如果你去那条路线),还是在你的MVC项目中(如果你去那条路线)。最终目标是分离关注点。您希望将业务逻辑层与数据访问层分开。您不希望在整个应用程序中直接调用数据库。这将导致代码紧密耦合,并且难以测试和维护。如果您将来更换数据库,您只想更新代码中的一个地方,而不是更多地方。

希望这能帮到你一些!最好的问候和快乐的编码!!!