python - django:胖模型和瘦 Controller ？

Question

这是一个通用的架构问题。我在很多地方读到在 MVC 框架中，(1) 模型应该是胖的，而 Controller 应该是瘦的。但我也读到 (2) 细节取决于您正在开发的框架。那么，如果您在 django 中开发呢？

我对 Django 的经验是，很多逻辑最终都被放入了 View 和表单中。不是“业务逻辑”，而是处理请求、 session 等的细节。在代码行数方面，这些细节往往比操作模型对象的业务逻辑更重要。我做错了什么，或者这就是django的工作原理？

Answer 1

MVC 不是一个通用的解决方案，而且大多数时候它都做错了，无法兑现 promise :实际上，修改模型也需要在 Controller 中进行修改，因为它做错了。如果你真的想要模型和 Controller 之间的松散耦合，那么 - 人们通常会忽略这一点 - 你必须使用 service pattern (open as image) .实际上几乎没有人这样做。
Django 并没有盲目地遵循 PHP 世界中的 MVC 大惊小怪/伪模式，而是采用了 pragmatic approach .因为在软件开发的共同现实中，开发人员为用户编写程序以供查看。然后用户(你的老板、客户、客户……)将“看到”你的工作，并最终给出他希望如何“看到”它的意见。通过使用 Django，开发人员可以采用更“面向 View ”的开发模式并猜测是什么:它使截止日期更容易遵守，用户更满意。如果你考虑一下，它有它的“nosql-ish”想法，即 View (一般 View ，而不是 django View )应该是幕后发生的事情的主宰。
我要感谢 Django 没有做错 MVC，这与 99% 的 PHP MVC 实现不同。
另一方面，Django 是唯一允许在应用程序之间进行适当隔离的框架。每个应用程序可以有:

型号

浏览次数

模板

网址

静态文件

测试

表格

可选插件(管理员、ajax 选择过滤器、django-authority 权限、django-notifications 通知等)

因此，即使您的模型/ View /模板将被绑定(bind)，您的项目也可以相应地划分为小的(也称为:易于维护)和松散耦合的应用程序。只有相关的模型/ View /模板/东西被捆绑在一起。带有大量 View 和 urls 脚本的大型肥胖模型脚本不是您在 Django 中想要的。例如，您不想要像 Article 这样的两个模型类。和 FootballMatch一起生活，你想做一个“文章”/“博客”应用程序和一个可以独立生活的“运动”应用程序。当然，有时它们必须绑定(bind)，在这种情况下，在 90% 的情况下，它在项目级别是可行的(如果您碰巧需要绑定(bind)模型或模板标签，您将制作另一个应用程序，“blog_sport”)。
例如，定义一个 get_absolute_url() 是一种非常普遍的做法。 Model 类中的方法。是的，理论上必须仅包含业务逻辑的模型类现在与您的 url 定义相关联。这在实践中有多糟糕？!!嗯，实际上它很棒，因为添加这个方法需要两秒钟，然后你可以在任何使用模型的地方使用它:无论是在 View 还是模板中。此外，其他应用程序(例如 django.contrib.admin )将使用它。
Django 辉煌的另一个稍微复杂的例子是查询被懒惰地评估。这意味着，您的 View 函数/类将定义一个查询，如 blog_list = Blog.objects.all() , 但如果它调用类似 {% for blog in blog_list %} ，则查询实际上会在模板中执行.因此，在这种情况下，业务逻辑发生在模板中，如果在渲染模板之前出现故障:您保存了一个查询。但这还不是全部，如果您的模板只显示计数 {{ blog_list.count }} ，选择查询根本不会产生，只会执行计数查询。 “一般 View ”决定需要什么业务逻辑。这与 MVC 的 promise 相去甚远，但老实说:这有多实用？
我的观点是，你可以以错误的方式应用理论，做对(这将你的选择减少到喜欢 5 个包含所有语言的 Web 框架)，或者只是以优雅和务实的方式切入主题，以禅宗的方式完成你的工作很快:这是 Django 的选择。