mysql - 在服务器或客户端上创建 AngularJS View 模型？

Question

我很好奇其他人如何使用底层关系数据库创建他们的 AngularJS View 模型？我和我的团队很难决定是否应该在服务器端或客户端进行对象连接。

例如，我们在服务器上有几个模型，例如 Author、Book 和 BookComment。在第一个示例中，只有一个端点来获取 Author (例如 /api/author/:id)，并且它将整个 View 模型“打包”在服务器。第二个示例，每个对象都有自己的 RESTful API 端点，例如 /api/authors/:id、api/books/:id 和 /api/bookcomments/:id.

一个Author可以有1个或多个Book对象，一个Book可以有1个或多个BookComment对象.

现在让我们比较这两种情况:

服务器端加入

我们让服务器根据外键连接对象，最终得到一个像这样的对象

作者

           {
                'id':1,
                'firstName':'John',
                'lastName':'Steinbeck',
                'books':[{
                   'id':123,
                   'title': 'Grapes of Wrath',
                   'author':1,
                   'comments':[{
                       'id':555,
                       'content':'This is a great book!',
                       'book':123
                   }]
                }]
            }

这将获取正确渲染 View 所需的所有数据和对象。那么问题就变成了在原子级别管理评论和书籍，因此如果用户只编辑评论，我们不想保存整个 Author 对象，而只是更新 BookComment 对象。这需要拉出对象并使用 Angular $resource 或类似的东西引导它们。

客户端加入

我们单独询问模型，然后在客户端加入它们:

作者

        {
            'id':1,
            'firstName':'John',
            'lastName':'Steinbeck',
            'books':[]
        }

预订

        {
            'id':123,
            'title': 'Grapes of Wrath',
            'author':1,
            'comments':[]
        }

书评

         {
              'id':555,
              'content':'This is a great book!',
              'book':123
         }

如果我使用 RESTful 接口(interface)下拉对象列表，那么我可以使用类似的方法加入它们

//Get the author
var author = Author.get();

//Join the books that were authored by this author
author.books = filterFilter(books, {author:author.id});

// Iterate each book and filter the comments by book ID
angular.forEach(books, function(book){
  book.comments = filterFilter(comments, {book:book.id});
});

这两种方法各有利弊。第一个使得原子管理对象变得困难，这迫使您 POST 大对象并使后端处理更新 SQL 数据库。第二个方法给客户端增加了更多工作，因为您需要提取大型数据集，然后动态过滤/将它们连接到其他模型。

是否还有我尚未遇到的其他选择，或者这两种方法中的一种被认为是最佳实践？

Answer 1

我正在与一个团队合作开发一个大型 Angular 应用程序，我们已经尝试了这两种实现。

我们从前端链接开始。主要是因为我们没有清楚地了解如何构建数据，或者在某些情况下甚至将其关联起来。在客户端创建高度通用的资源和链接一开始似乎更加灵活。

我们最近刚刚转向维护序列化两端的对象结构，从其余 API 中出来并返回到其中。这确实消除了我们大量困惑的逻辑和模糊的关系，如果您的数据只是需要 CRUD 的基本对象，我强烈推荐它。它还具有高度可维护性，并且易于构建集成工具。

示例:

如果我请求作者资源，我会得到以下数据:

{
            'id':1,
            'firstName':'John',
            'lastName':'Steinbeck',
            'books':[{
               'id':123,
               'title': 'Grapes of Wrath',
               'author':1,
               'comments':[{
                   'id':555,
                   'content':'This is a great book!',
                   'book':123
               }]
            }]
        }

我们遍历并用 Restangular 包装每个嵌套的数据层。 。 Restangular 以一种很棒的方式抽象地将对象包装为 RESTful 资源。

然后我们可以使用 firstAuthor.books[0].remove() 等内容编辑底层对象。或者构建使用那些易于更新的对象的自定义端点，例如 Restangular.one('books',firstAuthor.books[0]).get()。

朝着这个方向发展的一个巨大的“产品”好处是更少的 API 调用/更好的浏览器性能。当我们在 Angular 中进行链接时，我有一个页面会对一个异常复杂的对象进行 50 个 API 调用，然后仍然必须在客户端中执行所有逻辑。通过嵌套序列化，它减少到 1 个 API 调用，并且该页面的性能提高了 10 倍。

一件小事——它有助于标准化后端处理外键的方式。我们知道对象的奇怪属性名称将是外键(例如将 _id 附加到服务器的属性)，服务器会查找该属性并获取其 id。对于 Python/Django，其中 book_comment 是外键:

book_comment = request.DATA["book_comment"]["id"]