Question

刚刚完成一些CBV的工作，并想知道这是不好的风格。通常，您的views.py中有一个班级，而该视图中的urls.py中有一个网址。类似的东西：

views.py

from django.views.generic.list import ListView
from project.models import Contact

class ContactList(ListView):
  model = Contact

urls.py

from django.views.generic.list import ListView   
from project.views import ContactList

urlpatterns = [
    url(r'contacts/$', ContactList.as_view()),
]

然后是一个显示数据的模板。

但是，如果只是完全跳过视图代码并在urls.py文件中执行所有操作：

from django.views.generic.list import ListView
from project.models import Contact

urlpatterns = [
    url(r'contacts/$', ListView.as_view(model=Contact)),
]

将所有内容分组到urls.py文件中是不是很糟糕？我的意思是，它摆脱了views.py内的多余代码，所以不是那么好吗？或者这是以牺牲清晰度为代价的减少？

Answer 1

将视图逻辑保留在URLConfs之外要好得多。一眼url(r'contacts/$', ListView.as_view(model=Contact))看起来似乎没问题，但实际上它违反了Django的设计理念：

网址，视图，模型之间的松散耦合已经被紧密的替换，所以现在你无法重用你的视图。
URL的灵活性被破坏。继承，CBV的主要优势是不可能在URL中使用它们。
许多其他内容，例如，如果要添加身份验证，该怎么办？授权？您需要将所有这些包装在装饰器中，您的URL很快就会变得混乱。

所以：

视图模块应包含视图逻辑。
网址模块应包含网址逻辑。

Answer 2

答案是：这取决于。

如果你正在编写一个非常小的应用程序，你知道，它不会变得更大，那么无关紧要，除非你无法抗拒代码气味，你实际上可以只在一个文件中编写你的整个应用程序，检查此SO问题的答案，例如How do I write a single-file Django application?

P.S：这个问题是普遍存在的，并不是特定于Django的。

Answer 3

好吧，“减少views.py中的多余代码”肯定不是原因。如果您要使用几个简单的参数来实现通用视图，只要它适合您，您就可以将它保存在urls.py中。如果它不再起作用，可以将其移动到views.py或将视图设为模块并将其移至views/someview.py，这没关系。

基于Django类的视图 - 将所有代码放入urls.py是不好的风格？

3 个答案: