我想知道在哪里放置不属于视图的代码,我的意思是逻辑.
我一直在阅读一些类似的帖子,但无法得出结论.
我能理解的是:
那么所有基于逻辑的东西应该在哪里呢？
我来自Groovy/Grails,例如,如果我们需要访问数据库,或者如果我们有一个复杂的逻辑,我们使用服务,然后将这些服务注入控制器.
在Django中包含除Views和Models之外的东西的.py文件是一个好习惯吗？
PS:我读过有些人用过services.py,但是其他人说这是一个不好的做法,所以我有点困惑......
我不知道你为什么这么说
我们不能在控制器中放入很多逻辑,也不能让模型具有很多逻辑
你当然可以在任何一个地方放置逻辑.它在很大程度上取决于逻辑是什么:如果它与单个模型类特别相关,那么它应该放在模型中.但是,如果它与特定页面更相关,则可以进入视图.
或者,如果它是在多个视图中使用的更通用的逻辑,则可以将其放在单独的实用程序模块中.或者,您可以使用基于类的视图和定义逻辑的超类以及从中继承的子类.
小智 6
有了java背景,我可以与这个问题联系起来.我已经在python上工作了很长一段时间.即使我尽力将Java视为Java和Python作为Python,但有时我将它们混合在一起,以便我可以从两者中获得很好的效果.
简而言之
把所有模型相关的东西放在模型应用程序中,它可以从简单的模型定义到自定义保存,预保存挂钩.....
在视图中放置任何请求/响应相关的东西,以及一些逻辑,如验证Jon模式,验证请求正文......处理异常等等....
将您的业务逻辑放在单独的文件夹/ app或模块中,每个视图目录/ app.含义在模型和视图之间具有单独的中间模块.
只要您保持一致,就没有严格的规则来组织您的代码.
项目:Ci
型号:ci/model/device.py
视图:ci/views/list_device.py
商业逻辑:
(1)ci/business_logic/discover_device.py
要么
简短回答：Django 更像是 MTV 或 MVT（模型/模板/视图），如官方常见问题解答中所述：https : //docs.djangoproject.com/en/dev/faq/general/#django-appears-to -be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names
业务逻辑在您的视图中占有一席之地，但没有什么可以阻止您将其放入“utils.py”、“services.py”或任何您喜欢的内容中。