Django 开发是否提供了真正灵活的 3 层架构？答案

【问题标题】：Does Django development provide a truly flexible 3 layer architecture?Django 开发是否提供了真正灵活的 3 层架构？
【发布时间】：2009-01-19 07:06:07
【问题描述】：

几周前我问了一个问题“PHP、Python、PostgreSQL 设计是否适合非 Web 业务应用程序？” Is a PHP, Python, PostgreSQL design suitable for a business application?

很多答案建议跳过 PHP 部分并使用 Django 来构建应用程序。在探索 Django 时，我开始质疑我的目标的一个特定方面，以及 Django 如何在非网络业务应用程序中发挥作用。

根据我的理解，Django 将管理视图和控制器部分，而 PostgreSQL 或 MySQL 将处理数据。但我的目标是清楚地分离这些层，以便数据库、域逻辑和表示可以在不显着影响其他的情况下进行更改。看来我只是用 Django 解决方案将 M 与 VC 层分开。

那么，使用 SQL Alchemy/Elixir ORM 工具、PostgreSQL 在 Python 中构建域层对我来说是否适得其反？数据库层，然后仍然使用 Django 或 PHP 作为表示层？这是可能的还是纯粹的精神错乱？

基本上，我会研究 Django/PHP > Python/SQLAlchemy > PostgreSQL/MySQL 的架构。

编辑：在粉丝们因为我问关于 Django 的问题而生我的气之前，请意识到：这是一个问题，而不是指责。如果我知道答案或有自己的看法，我就不会问了！

【问题讨论】：

嘿...胆小的开车路过的投票者...为什么这是一个无益的问题？我真的很好奇。（+1 抵消懦夫）。
说实话我不太明白这个问题，你到底在问什么？

标签： python django model-view-controller orm

【解决方案1】：

您似乎在说选择 Django 会阻止您以后使用更异构的解决方案。事实并非如此。 Django 在层之间提供了许多有趣的连接，并且将 Django 用于所有层可以让您利用这些连接。例如，使用 Django ORM 意味着您几乎可以免费获得出色的 Django 管理应用程序。

您可以选择在 Django 中使用不同的 ORM，只是不会同时获得管理应用程序（或通用视图）。因此，不同的 ORM 让您从完整的 Django 自上而下向后退了一步，但这并不是从其他异构解决方案的倒退，因为这些解决方案一开始并没有为您提供管理应用程序的层内优势.

不应该批评 Django 没有提供灵活的架构：它与任何其他解决方案一样灵活，如果您选择换出一个层，您只是放弃了 Django 的一些好处。

如果你选择从 Django 入手，现在可以使用 Django ORM，以后如果需要切换，可以切换到 SQLalchemy。这不会比现在从 SQLalchemy 开始，然后再转向其他一些 ORM 解决方案更困难。

您还没有说明为什么您预计需要换出层。无论如何，这将是一个痛苦的过程，因为必然有很多代码依赖于您当前使用的任何工具集和库的行为。

【讨论】：

对于任何系统的长期开发来说，基于浏览器的界面的兴起不是告诉我们需要将领域层与表示层分离吗？
另外，我不是在批评 Django ...我是在问一个问题，以确保我正确地看待它。
领域层实际上不应该知道表示层。但是表示层必然依赖于领域层。现在我不明白这与 Django 有什么关系。领域层部分（视图）不依赖于表示（视图和模板）。

【解决方案2】：

Django 很乐意让你使用你想要的任何库——你想要一个不同的 ORM，使用它，你想要一个不同的模板引擎，使用它等等——但是设计提供许多可互操作应用程序使用的通用默认堆栈。换句话说，如果您更换 ORM 或模板系统，您将失去与许多应用程序的兼容性，但利用大量应用程序的能力通常比这更重要。

不过，从更广泛的意义上讲，我建议您花更多时间阅读 Web 应用程序的架构模式，因为您似乎遇到了一些重大的概念混淆。可以简单地说，例如，Rails 没有“视图”层，因为您可以使用不同的文件系统作为视图代码的存储位置（换句话说：能够更改数据的位置和方式由您的模型层存储并不意味着您没有模型层）。

（不言而喻，了解为什么“严格”或“纯”MVC 绝对可怕适合 Web 应用程序也很重要；纯粹形式的 MVC 对于具有许多独立的方式来启动交互，例如带有大量工具栏和输入窗格的文字处理器，但是当您移动到 Web 并且只有一种方式（HTTP 请求）与应用程序交互时，它的好处很快就会消失。这就是为什么没有“真正的”MVC Web 框架的原因；它们都借鉴了某些关于关注点分离的想法，但没有一个严格地实现了该模式）

【讨论】：

感谢您的回答。这很有意义。但是，由于我不是在开发基于 Web 的应用程序，这就是我的问题所在。我需要 3 个单独的层，因为并非每次交互都一定是 HTTP 请求。
Django 只是 Python。让 Django 代码访问模型层而不受 HTTP 请求/响应周期的约束，这没有任何问题。
@Carl 没错，但 Django 的大部分实用性在于它是一个集成的 Web 堆栈（尽管我偶尔会在 OS X Core Data 存储上使用它，只是为了好玩）。

【解决方案3】：

您似乎将“不同的层”与“不同的语言/技术”混淆了。您没有理由不能在单一编程语言或适当的模块化框架（例如 Django）中适当地分离您的关注点。不必要地增加编程语言/框架只是增加了不必要的复杂性，这可能会大大减慢您的初始工作，以至于您的项目永远无法达到需要技术转换的地步。

【讨论】：

我想我担心的是，如果我在 Django 中开发领域层，那么我将受限于同样是 Django 的表示层。但是，如果我使用 Python 开发领域层，我可以使用我选择的任何技术来更改演示或模型片段？
除非那不是真的。它甚至不连贯。 Django 是 Python。使用 Django 的 ORM（即 Python）与使用 SQLAlchemy（即 Python）没有什么不同。它们各有优缺点，但其中一个本质上并不比另一个更易于插拔。

【解决方案4】：

无论您使用 Django 的 ORM 还是 SQLAlchemy，您都有效地获得了 3 层架构，但如果您选择后者，您将放弃 Django 的一些好处。

【讨论】：

【解决方案5】：

根据我的理解，Django 将管理视图和控制器部分，而 PostgreSQL 或 MySQL 将处理数据。

并非如此，Django 有自己的 ORM，因此它确实将数据与视图/控制器分开。

这是一个关于 MVC 的entry from the official FAQ：

那么，“控制器”在哪里？在 Django 的例子中，它可能是框架本身：根据 Django URL 配置向适当视图发送请求的机制。

如果您对首字母缩略词很感兴趣，您可能会说 Django 是一个“MTV”框架——即“模型”、“模板”和“视图”。这种分解更有意义。

当然，归根结底，还是要把事情做好。而且，无论事物如何命名，Django 都会以对我们来说最合乎逻辑的方式完成工作。

【讨论】：

【解决方案6】：

有变化，有变化。 Django 将领域模型、业务规则和表示完全分开。您可以（几乎）更改几乎零破损的任何东西。我所说的变化是指有意义的以最终用户为中心的业务变化。

这个（和上一个）问题中的技术混合搭配并不是很有帮助。

谁——特别是——受益于用 PHP 替换 Django 模板。它没有更多的生产力。它更复杂，没有任何好处。谁从更改 ORM 中受益。用户不会也无法分辨。

【讨论】：

@wrburgess：混搭是不可避免的吗？这是否意味着所有技术都不好，必须不可避免地被替换？或者这是否意味着所有技术都不可避免地转向 PHP？