MVC不是通用解决方案，大多数情况下它做错了并且不能兑现其诺言：实际上，修改模型也需要在控制器中进行修改，因为这样做是错误的。如果您确实想要Model与Controller之间的松散耦合，那么- 人们通常会忽略这一点-您 必须 使用服务模式（以图片形式打开）。实际上几乎没有人这样做。
Django并没有盲目地遵循PHP世界中的MVC大惊小怪/伪模式，而是采取了务实的方法。因为在软件开发的普遍现实中，开发人员编写了程序供用户查看。然后，用户（您的老板，客户，客户…）将“看到”您的工作，并最终给出他对如何“看到”它的意见。通过使用Django，开发人员可以采用更“面向视图”的开发模式，然后猜测一下：它使截止日期更容易遵守，用户也更加满意。如果您考虑一下，它具有“ nosql-ish”的想法，即视图（通用视图，而不是django视图）应该是幕后事情的老板。
我要感谢Django没有做错MVC，这与99％的PHP MVC实现不同。
另一方面，Django是唯一允许在应用程序之间适当隔离的框架。每个应用程序可以具有：
因此，即使将模型/视图/模板捆绑在一起，您的项目也可以相应地划分为小型（也称为：易于维护）和松散耦合的应用程序。仅将 相关的 模型/视图/模板/材料捆绑在一起。在Django中，您不需要的是具有较大的胖视图和url脚本的胖模型脚本。例如，您不希望像Article和FootballMatch这样的两个模型类一起生活，而是想要制作一个可以独立生活的“ articles” /“ blog”应用程序和“ sport”应用程序。当然，有时必须将它们捆绑在一起，在这种情况下，在90％的情况下在项目级别是可行的（如果您碰巧需要捆绑模型或模板标签，则可以制作另一个应用程序“ blog_sport”）。
例如，在Model类中定义get_absolute_url（）方法是一种超常规的做法。是的，您的模型类在理论上只必须包含业务逻辑，现在与您的url定义相关联。实际上这有多糟糕？好吧，实际上它很出色，因为添加此方法需要两秒钟，然后您可以在使用模型的任何地方使用它：在视图或模板中使用它。另外，其他应用程序（即django.contrib.admin）也将使用它。
Django辉煌的另一个稍微复杂的例子是查询是惰性计算的。这意味着，您的视图函数/类将定义一个类似blog_list = Blog.objects.all（）的查询，但是如果该查询实际上是在模板中执行的，则其调用方式为{％{ 因此，在这种情况下，如果在呈现模板之前发生故障，则模板中会发生业务逻辑：您保存了一个查询。但这还不是全部，如果您的模板仅显示一个计数{{blog_list.count}}，则根本不会产生select 查询 ， 而仅执行一个计数查询。“一般视图”决定了需要什么业务逻辑。这与MVC的承诺相去甚远，但说实话：那有多实际？
我的观点是，您可以错误地运用理论，正确地运用理论（这将您的选择减少为喜欢5种包含所有语言的 Web 框架），或者只是以一种优雅而务实的方式达到目的，以禅宗的方式完成工作立即：这是Django的选择。
602392714
清零编程群
