2

抱歉，如果之前已经讨论过这个问题，已经搜索和搜索但没有发现任何有用的东西:)

但是这里。我们目前正在重写我们的 webapp 的一部分。我们的应用程序相当陈旧，因此在编程、约定和 url 方面存在一些相当牛仔风格的方法。

我们正在寻找一种简单干净的方式来设计我们的视图和 url，以便我们将来可以更轻松地维护它们。

问题是; 到目前为止，我们用于主站点的 urls.py 文件是一团糟。许多 url 指向一个独特的视图，只有一个薄。前任。list_books/, edit_book/ 等当涉及到特定格式等时，我们有类似 list_books_json/ 的东西

（虽然这些不是实际的网址，但只是用来证明一点，因为真正的网址要糟糕得多）

我们现在要做的就是稍微清理一下。我们想知道绕过它的最佳方法是什么？

到目前为止我们所想到的（在阅读了很多关于这个主题的东西之后）：

我们考虑过按照以下模式设计我们的 url：domain/object/action/

因此，用于在应用程序中更改书籍的应用程序“员工”网站的 URL 将是：员工/书籍 - 查看所有书籍 (GET) 员工/书籍/ID - 查看一本书 (GET) 员工/书籍/新 - 到创建新书 (POST) staff/books/ID/edit - 编辑特定书籍 (POST) staff/books/ID/delete - 删除特定书籍 (POST)

当时的想法是只有 1 个视图，views.staff_books() 来处理通过站点的“员工”部分处理书籍时的所有这些操作。以便 staff_books() 检查 ID 或某个“操作”（编辑、新建、删除等）

结果会更少，但更大的视图必须处理员工/书籍的各个方面。现在我们有很多只处理一件事的小视图。

这有意义吗，你能看到潜在的问题吗？你们是怎么处理的？？

我认为我们迷路的一个地方是格式。你会把前任放在哪里。在 json 中返回响应的请求？我们想知道“staff/books.json”或“staff/books/ID.json”等，然后将所有 json 逻辑保存在同一个“staff_books()”视图中。

基本上就是这样。对不起，这个问题有点“蓬松”......我们基本上需要一些关于如何构建 url 和视图的示例或好的设计建议。

亲切的问候

皮特

4

1 回答 1

1

作为您问题的扩展（和解决方案），我建议使用策略模式。由于您已经有了一个结构，并且唯一不同的是它应该如何执行，因此这种模式非常适合您的问题。我的意思是：

  1. 创建一个视图，它是您的应用程序的入口点，其功能命名为基于 url 的功能（编辑、新建、删除等）。即你的 url.py 决定从那里去哪里。
  2. 创建基于您的域等执行您的工作的类。我们现在称它们为 Book、Calendar 等。
  3. 实现这些类的功能，如编辑、新建、删除等。
  4. 然后在您的视图中，确定要实例化的类并调用相应的函数，例如在 View.edit() 中调用 domain.edit()

我认为应该这样做^^希望它有所帮助：D

于 2013-05-17T12:17:22.797 回答