Breeze和RESTful WebAPI

Question

题:

当我需要在WebAPI中为每个实体实现自己的POST/PUT/GET端点时,breeze提供了什么价值？

背景:

这似乎是服务器端Breeze控制器的常见实现:

[BreezeController]
public class TodosController : ApiController {

    readonly EFContextProvider<TodosContext> _contextProvider =
        new EFContextProvider<TodosContext>();

    // ~/breeze/todos/Metadata
    [HttpGet]
    public string Metadata() {
        return _contextProvider.Metadata();
    }

    // ~/breeze/todos/Todos
    // ~/breeze/todos/Todos?$filter=IsArchived eq false&$orderby=CreatedAt
    [HttpGet]
    public IQueryable<TodoItem> Todos() {
        return _contextProvider.Context.Todos;
    }

    // ~/breeze/todos/SaveChanges
    [HttpPost]
    public SaveResult SaveChanges(JObject saveBundle) {
        return _contextProvider.SaveChanges(saveBundle);
    }

    // other miscellaneous actions of no interest to us here
}

我正在构建一个RESTish API,到目前为止,它具有以下端点:

GET /api/todo/1
PUT /api/todo
POST /api/todo

似乎Breeze要求端点更简单(无论好坏) - 只是一堆GETS和一个SaveChanges POST端点.

这让我觉得Breeze使用单个Web客户端进行快速开发,轻而易举......但是只要您拥有匿名客户端,就必须强制它们进入您在客户端创建的任何微风界面约定,这似乎打败了RESTful API设计的目的.是这样的吗？

Answer 1

Breeze是第一个和formost,一个客户端JavaScript框架.如果您没有在客户端上使用Breeze,Breeze.WebApi的好处仅限于

• 增强的OData查询支持($ select和$ expand支持,扩展$ orderby)
• 保存拦截点(beforeSaveEntity和beforeSaveEntities事件)
• 保存结果处理(更新的实体键,并发列)
• 元数据提取和序列化

正如您所推测的那样,Breeze在REST方面与CRUD操作有着不同的理念.

Breeze专为可能希望在单个事务中使用不同类型的C/U/D资源的客户而设计.这允许用户以复杂的方式操作数据而无需访问服务器,然后在准备好时保存更改.例如,可以创建一个新的Order,OrderLineItem从一个Order到另一个移动两个,删除第三个OrderLineItem,在第四个上修改数量,然后SaveChanges().Breeze甚至支持使用localStorage完全与服务器断开连接.重新连接后,可以保存所有更改.

REST旨在一次在一个资源上运行.必须立即对服务器执行每个C/U/D操作,以便可以对响应代码执行操作.它适用于具有简单更新需求的应用程序,但不适用于数据输入应用程序.虽然可以在REST中支持事务,但它们最多也很麻烦.

话虽如此,您的服务器端Breeze API不仅限于您在Todos示例中看到的内容.Breeze支持命名保存,允许您为不同的操作使用不同的端点.您还可以使用" 保存拦截"来确保您的保存包仅包含它应该包含的类型.当然,没有什么可以阻止您在服务器上公开这两个API,并且同时使用相同的持久层.

如果您必须在它们之间做出决定,那么您应该从您的用户开始.真正的用户(不是开发人员)不关心REST,他们关心应用程序可以做什么.最终,REST为您的应用程序提供了HTTP的所有语义,Breeze为其提供了关系数据库或对象数据库的所有语义.向用户公开哪一个应取决于您需要支持的用例.