Django：胖模特和瘦控？

Question

这是一个一般的架构问题。我在很多地方读到，在MVC框架中，（1）模型应该很胖，控制器应该很瘦。但我也读到（2）细节取决于你正在开发的框架。那么，如果你在django发展呢？

我对django的经验是，很多逻辑最终都被放入视图和表单中。不是“业务逻辑”，而是处理请求、会话等的详细信息。就代码行而言，这些详细信息常常超过处理模型对象的业务逻辑。我做错什么了，还是这就是django的工作方式？

Answer 1

这取决于您的应用程序是关于什么的，但是Django的优点是它不强制您将逻辑代码放在视图或模型中，这是您的调用。

如果你认为某个逻辑与你的模型密切相关，那么你可以用它来做一个方法。规则（对我来说）是你的模型应该对环境不可知（web应用、运行manage命令的Crontab等等）。

我的政策是尽量使我的模型达到最低限度。

顺便说一下，你不打算在你的模型中处理request和sessions，不是吗？那是个坏主意。

Answer 2

MVC并不是一个通用的解决方案，大多数时候它都做了错事，不能信守诺言：实际上修改模型也需要修改控制器，因为它做错了。如果你真的想要模型和控制器之间的松散耦合，那么——人们通常会忽略这一点——你必须使用service pattern (open as image)。几乎没有人真的这么做。

Django没有盲目地在PHP世界中遵循MVC fuss/pseudo模式，而是采用pragmatic approach。因为在软件开发的共同现实中，开发者编程的东西是供用户看到的。然后用户（你的老板、客户、顾客……）会“看到”你的工作，并最终给出他希望如何“看到”工作的意见。通过使用Django，开发人员可以采用一种更“面向视图”的开发模式，并猜测是什么：它使截止日期更容易得到尊重，用户也更满意。如果你仔细想一想，它有一个“非sql”的想法，即视图（一般视图，而不是django视图）应该是幕后的老板。

我要感谢Django没有做错MVC，这与99%的phpmvc实现不同。

另一方面，Django是唯一允许在应用程序之间进行适当隔离的框架。每个应用程序可以具有：

• 模型
• 视图
• 模板
• 网址
• 静态文件
• 测试
• 形式
• 可选插件（管理员、ajax选择的过滤器、django权限、django通知等）

因此，即使您的模型/视图/模板将被绑定，您的项目也可以相应地划分为小型（也可以是易于维护的）和松散耦合的应用程序。只有相关的模型/视图/模板/材料被绑定在一起。在Django中，您不需要一个包含大量fat视图和url脚本的大型fat模型脚本。例如，你不希望像Article和FootballMatch这样的两个模型类生活在一起，你想制作一个“articles/“blog”应用和一个可以独立生活的“sport”应用。当然，有时它们必须绑定，在这种情况下，在90%的情况下，在项目级别是可行的（如果你碰巧需要绑定模型或模板标记，你可以制作另一个应用程序“blog_sport”）。

例如，在模型类中定义get_absolute_url（）方法是一种非常常见的做法。是的，您的模型类在理论上只包含业务逻辑，现在与您的url定义绑定在一起。这在实践中有多糟糕？！！实际上它很出色，因为添加这个方法需要两秒钟，然后您可以在任何使用模型的地方使用它：无论是在视图中还是在模板中。另外，其他应用程序（如django.contrib.admin）也将使用它。

Django brilliance的另一个稍微复杂一点的例子是，查询被惰性地计算。这意味着您的视图函数/类将定义一个类似blog戋list=blog.objects.all（）的查询，但是如果它调用类似{%for blog in blog戋list%}的查询，则该查询实际上将在模板中执行。因此，在这种情况下，业务逻辑发生在模板中，如果在呈现模板之前发生了故障：您保存了一个查询。但这并不是全部，如果您的模板只显示一个count{{blog{list.count}，那么select查询根本不会生成并且只执行一个count查询。“一般视图”决定了需要什么样的业务逻辑。这与MVC的承诺相去甚远，但老实说：这有多实际？

我的观点是，你可以用错误的方式应用理论，做正确的事情（这会减少你的选择，使你喜欢5webframeworks所有语言都包括在内），或者只是用一种优雅而务实的方式达到目的，让你的工作在短时间内以禅宗的方式完成：那是Django的选择。

Answer 3

我对Django最大的问题是，他们似乎通过添加表单层来打破MVC模式。大多数文档都会引导您将验证逻辑放在表单中，而模型验证程序仅由formsaves调用这一事实只会加强这一约定。但在我看来，这是一个不好的约定，因为毕竟，经常被验证的是将转换为模型的数据。

最好的例子是，如果您考虑使用Django Rest框架将传统的Django项目转换为以API为中心的项目，并使用一个单独的前端客户机来使用这个API。与只保留模型的完整性和保留大量业务逻辑不同，您将不得不遍历表单并将所有逻辑移到序列化器中（不幸的是，Django Rest框架也遵循Django已损坏的MVC模式并添加了一个额外的“序列化器”层）。

我认为胖模型的方法是一条路要走。有关如何在Djangohere中实现它的更多信息。