Django的逻辑和它放在哪里？

我是Django的新手，但我最近创建了我的第一个应用程序。我想知道如果我把我的逻辑放在错误的地方。从Django书中，我得到了这个逻辑，但应该将它放入模型中的视图和数据中。但我最近读到的观点应该尽可能小，让模型处理逻辑。我的问题是我的意见处理所有我的逻辑，而我的模型只处理去往和来自我的数据库的数据。我在创建这个应用程序时弄错了，如果是这样，我该如何解决它？Django的逻辑和它放在哪里？

来源

2017-03-09 J.Doe

不，你没有搞砸了。您可以通过经验（多年的开发）找到您的解决方案。

所以，无论是使用胖模型和瘦视图或相反，它取决于你和你的应用程序的要求。

在您学习的过程中，您会发现新的技术和方法，可以帮助您扩展“逻辑”和应用程序实现。

在开始你会犯错，但没关系。我们需要他们成为更好的开发人员，编码员等。

所以我的建议是：保持冷静和学习（良好做法）！

来源

2017-03-09 19:38:31

我是否正确地认为“胖模型和薄视图”通常是针对大型应用程序并需要ORM？当我尝试构建时，我总是暗自思考和OP一样：P – roganjosh

不会。其中一个并不意味着另一个。只要你保持你的[DRY]（https://en.wikipedia.org/wiki/Don't_repeat_yourself）并保持一致，你就可以拥有任何你想要的东西。例如，我在一些项目中使用胖模型，胖视图和薄模板。在其他人中，我有瘦模型，胖视图和胖模板。它总是取决于每个项目和你处理每个项目的方式。困难的部分是（一如既往）开始... –

有趣的。是的最后一部分;对我来说，闯入'django'也意味着学习JS和HTML。当你知道你可以用'views'识别的方式覆盖Python部分时，只需完全抛弃'models'即可。对于小型应用程序，我可以确保自己的（小）SQL安全等等。然后再次，网络是如此令人生畏，以至于你总是觉得你错过了一些你没有看到的保护措施。 – roganjosh

最好有“脂肪模型，瘦视图”。许多Django专家会给你这个提示。谷歌这个短语，你会发现一些资源，说：“胖模型，瘦视图，”或“胖模型，瘦瘦的控制器。”顺便说一下，Django的创建者将Controllers命名为Views，将Views视为Templates，这可能会导致一些误解，同时阅读关于Django中的MTV MVC的文章。

来源

2017-03-09 19:44:18 Ambitions

这样做很简单。而且我会说，如果你的逻辑主要在视图中，它并不是真的搞砸了。

您在多个函数的视图中使用的最重复的函数和逻辑，您可以创建一个在模型中定义的函数，然后在视图中调用该函数。（你可以一步一步做）

例如，如果它是一个社交网络，你正在设置用户的城市。现在随着你的应用程序的增长，可能会有许多功能和城市正在设置的许多地方。如果你正在重复地在视图中执行所有操作，那么你会在某个时间点卡住，因为要做出最小的更改，可能需要编辑所有的功能。

好的方法是在用户模型中定义set_cities(self, cities)，并在需要时调用它，如user.set_cities(cities_list)。因此，如果每次设置城市时（如发送通知或更新其他表格）都必须触发其他功能，则必须在set_cities()中定义一次。

在任何情况下，所有的逻辑不能只在模型中，所以不要太担心它。只要不断尝试简化观点，并不断将重复的逻辑转移到模型上。

来源

2017-03-09 19:50:42 sprksh

Django的理念/最佳实践鼓励“胖模型瘦控制器”（控制器是在Django中的视图）。尝试过这两种方法后，它肯定可以在“胖模型”方法中更好地工作。尽量保持逻辑与数据模型接近，这使得它更加可重用，并且您可以在Django中使用更多的功能。

一个例子是返回分页列表视图。如果你需要某种计算为每个对象在一个QuerySet，你可以

环比它在视图中做计算
，或者你可以添加一个模型的方法，然后调用它的模板每次迭代。

循环在查询集视图会做计算对整个queyset - 并不好，如果你只显示从1000

列表从模板调用模型的方法10个对象中，只能在该页面上的10个对象上进行计算。

很明显，您可以向视图添加更多代码，只对该页面上的对象进行计算，但如果您转到其他路由，则不需要额外的代码。如果您需要在另一个页面上进行相同的计算，将逻辑保留在模型方法中将可以重复使用，而不需要进行任何更改，而您需要将其剪切并粘贴到视图中，或者创建一个新方法。虽然它没有太大的差别，但是像这样的许多小事开始累积起来。

来源

2017-03-09 22:21:20

Django的逻辑和它放在哪里？

回答

相关问题