<p>MVC并不是一个通用的解决方案,大多数时候它都做了错事,不能信守诺言:实际上修改模型也需要修改控制器,因为它做错了。如果你真的想要模型和控制器之间的松散耦合,那么——人们通常会忽略这一点——你必须使用<a href="https://fisheye6.atlassian.com/browse/~raw,r=976282/zetacomponents/trunk/MvcTools/design/model_controller_loose_coupling_example.svg" rel="noreferrer">service pattern (open as image)</a>。几乎没有人真的这么做。</p>
<p>Django没有盲目地在PHP世界中遵循MVC fuss/pseudo模式,而是采用<a href="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" rel="noreferrer">pragmatic approach</a>。因为在软件开发的共同现实中,开发者编程的东西是供用户看到的。然后用户(你的老板、客户、顾客……)会“看到”你的工作,并最终给出他希望如何“看到”工作的意见。通过使用Django,开发人员可以采用一种更“面向视图”的开发模式,并猜测是什么:它使截止日期更容易得到尊重,用户也更满意。如果你仔细想一想,它有一个“非sql”的想法,即视图(一般视图,而不是django视图)应该是幕后的老板。</p>
<p>我要感谢Django没有做错MVC,这与99%的phpmvc实现不同。</p>
<p>另一方面,Django是唯一允许在应用程序之间进行适当隔离的框架。每个应用程序可以具有:</p>
<ul>
<li>模型</li>
<li>视图</li>
<li>模板</li>
<li>网址</li>
<li>静态文件</li>
<li>测试</li>
<li>形式</li>
<li>可选插件(管理员、ajax选择的过滤器、django权限、django通知等)</li>
</ul>
<p>因此,即使您的模型/视图/模板将被绑定,您的项目也可以相应地划分为小型(也可以是易于维护的)和松散耦合的应用程序。只有<em>相关的</em>模型/视图/模板/材料被绑定在一起。在Django中,您不需要一个包含大量fat视图和url脚本的大型fat模型脚本。例如,你不希望像Article和FootballMatch这样的两个模型类生活在一起,你想制作一个“articles/“blog”应用和一个可以独立生活的“sport”应用。当然,有时它们必须绑定,在这种情况下,在90%的情况下,在项目级别是可行的(如果你碰巧需要绑定模型或模板标记,你可以制作另一个应用程序“blog_sport”)。</p>
<p>例如,在模型类中定义get_absolute_url()方法是一种非常常见的做法。是的,您的模型类在理论上只包含业务逻辑,现在与您的url定义绑定在一起。这在实践中有多糟糕?!!实际上它很出色,因为添加这个方法需要两秒钟,然后您可以在任何使用模型的地方使用它:无论是在视图中还是在模板中。另外,其他应用程序(如django.contrib.admin)也将使用它。</p>
<p>Django brilliance的另一个稍微复杂一点的例子是,查询被惰性地计算。这意味着您的视图函数/类将定义一个类似blog戋list=blog.objects.all()的查询,但是如果它调用类似{%for blog in blog戋list%}的查询,则该查询实际上将在模板中执行。因此,在这种情况下,业务逻辑发生在模板中,如果在呈现模板之前发生了故障:您保存了一个查询。但这并不是全部,如果您的模板只显示一个count{{blog{list.count},那么<em>select</em>查询根本不会生成<em>并且只执行一个count查询。“一般视图”决定了需要什么样的业务逻辑。这与MVC的承诺相去甚远,但老实说:这有多实际?</p>
<p>我的观点是,你可以用错误的方式应用理论,做正确的事情(这会减少你的选择,使你喜欢5<em>web</em>frameworks所有语言都包括在内),或者只是用一种优雅而务实的方式达到目的,让你的工作在短时间内以禅宗的方式完成:那是Django的选择。</p>