Djang的业务逻辑

Question

我想知道在哪里放置不属于视图的代码，我是说，逻辑。

我也读过一些类似的帖子，但没能得出结论。

我能理解的是：

• 视图就像一个控制器，很多逻辑不应该放在控制器中。
• 模型也不应该有很多逻辑。

那么所有基于逻辑的东西应该在哪里呢？

我来自Groovy/Grails，例如，如果我们需要访问数据库，或者如果我们有一个复杂的逻辑，我们使用服务，然后这些服务被注入控制器。

在Django中，让.py文件包含除视图和模型以外的其他内容是一种好的做法吗？

注：我读过一些人使用services.py，但后来有人说这是一种不好的做法，所以我有点困惑。。。

Answer 1

有了java背景，我可以理解这个问题。 我研究python已经有很长一段时间了。尽管我尽力把Java当作Java，把Python当作Python，但有时我会把两者混合起来，这样我就能从两者中得到很多好处。

简而言之

1. 把所有与模型相关的东西放到模型应用程序中，它可以从简单的模型定义到自定义保存、预保存挂钩。。。。。

2. 在视图中放入任何与请求/响应相关的内容，以及一些逻辑，如验证Jon模式、验证请求体。。。处理异常等。。。。

3. 将业务逻辑放在每个视图目录/app的单独文件夹/app或模块中。意思是在模型和视图之间有单独的中间模块。

没有严格的规则来组织你的代码，只要你是一致的。

项目：Ci

• 型号：ci/model/device.py

• 视图：ci/Views/list_device.py

• 业务逻辑：

  • （1）ci/business_logic/discover_device.py

    或

  • （2） ci/views/discover_设备.py

Answer 2

简而言之：Django更像是MTV或MVT（Model/Template/View），如官方FAQ中所述：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”或任何您喜欢的内容中。

Answer 3

我不知道你为什么说

we can't put a lot of logic in the controller, and we cannot have the models with a lot of logic either

你当然可以把逻辑放在这两个地方。这在很大程度上取决于该逻辑是什么：如果它与单个模型类特别相关，那么它应该放在模型中。但是，如果它与特定页面更相关，则可以进入视图。

或者，如果在多个视图中使用的是更通用的逻辑，则可以将其放在单独的实用程序模块中。或者，您可以将基于类的视图与定义逻辑的超类以及从中继承的子类一起使用。