我很好奇其他人是如何使用底层关系数据库创建AngularJS视图模型的?我和我的团队在决定是否应该在服务器端或客户端进行对象连接时遇到问题。
例如,我们在服务器上有几个模型,如Author
,Book
和BookComment
。在第一个示例中,只有一个端点来获取Author
/api/author/:id
和{"包"}整个服务器上的视图模型。第二个示例,每个对象都有自己的RESTful API端点,如/api/authors/:id
,api/books/:id
和/api/bookcomments/:id
。
Author
可以有一个或多个Book
个对象,Book
可以有一个或多个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
}]
}]
}
这将获取所有需要的数据和对象以正确呈现视图。然后问题是在原子级别管理评论和书籍,因此如果用户只编辑评论,我们不想保存整个Author
对象,而只是更新{{1}对象。这需要拉出对象并使用Angular BookComment
或类似的东西来引导它们。
客户端加入
我们单独询问模型,然后在客户端加入:
作者
$resource
图书
{
'id':1,
'firstName':'John',
'lastName':'Steinbeck',
'books':[]
}
BookComment
{
'id':123,
'title': 'Grapes of Wrath',
'author':1,
'comments':[]
}
如果我使用RESTful接口下拉对象列表,那么我可以使用
之类的东西加入它们 {
'id':555,
'content':'This is a great book!',
'book':123
}
这两者都各有利弊。第一个使得很难以原子方式管理对象,这迫使您POST大对象并使后端处理更新SQL数据库。第二个向客户端添加更多工作,因为您需要下载大型数据集,然后在运行中过滤/加入其他模型。
还有其他选择我还没有遇到过,或者这两种方式中哪一种被认为是最佳做法?
答案 0 :(得分:1)
我正在与一个大型角度应用程序的团队合作,我们已经尝试了这两种实现。
我们开始在前端进行链接。主要是因为我们没有清楚地了解我们想要如何构建数据,或者在某些情况下甚至将它与之相关联。在开始时,创建高度通用的资源并在客户端上进行链接似乎更加灵活。
我们最近刚刚开始在序列化的两端维护对象结构,从其余的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"]