几个星期前，我问了一个问题“PHP，Python，PostgreSQL设计是否适用于非Web业务应用程序？” Is a PHP, Python, PostgreSQL design suitable for a business application?
许多答案建议跳过 PHP 部分并使用 Django 来构建应用程序。当我探索Django时，我开始质疑我的目标的一个特定方面以及Django如何为非Web业务应用程序发挥作用。
根据我的理解，Django将管理视图和控制器部分， PostgreSQL 或 MySQL 将处理数据。但我的目标是明确地分离各个层，以便可以更改数据库，域逻辑和表示，而不会显着影响其他层。看起来我只是用Django解决方案将M与VC层分开。
因此，使用 SQL Alchemy / Elixir ORM工具， PostgreSQL 在 Python 中构建域图层对我来说是适得其反的数据库层，然后仍然使用 Django 或 PHP 作为表示层？这是可能的还是纯粹的疯狂？
基本上，我会看一下 Django / PHP＆gt;的体系结构。 Python / SQLAlchemy＆gt;的PostgreSQL / MySQL的
编辑：在粉丝们因为询问关于Django的问题而生我生气之前，我们才意识到：这是一个问题，而不是一个指责。如果我知道答案或有我自己的意见，我就不会问！
答案 0 :(得分：9)
您似乎在说选择Django会阻止您以后使用更异构的解决方案。事实并非如此。 Django在各层之间提供了许多有趣的连接，并且对所有层使用Django可以让您利用这些连接。例如，使用Django ORM意味着您几乎可以免费获得优秀的Django管理应用程序。
您可以选择在Django中使用不同的ORM，您将无法获得管理应用程序（或通用视图）。因此，一个不同的ORM会让你从完全Django自上而下退一步，但它并不是从其他异构解决方案向后退一步，因为这些解决方案首先没有为管理员应用提供内层优势
不应该因为没有提供灵活的架构而批评Django：它与其他任何解决方案一样灵活，如果你选择换出一层，你就放弃了一些Django的好处。
如果你选择从Django开始，你现在可以使用Django ORM，然后，如果你需要切换，你可以转换到SQLalchemy。现在开始使用SQLalchemy并稍后转向其他ORM解决方案并不困难。
你还没有说过为什么你预计需要换掉图层。无论如何，这将是一个痛苦的过程，因为必然会有很多代码依赖于您当前使用的任何工具集和库的行为。
答案 1 :(得分：7)
Django很乐意让你使用你想要的任何你想要的库 - 你想要一个不同的ORM，使用它，你想要一个不同的模板引擎，使用它，等等 - 但是设计提供许多可互操作应用程序使用的公共默认堆栈。换句话说，如果你换掉ORM或模板系统，你将失去与许多应用程序的兼容性，但是利用大量应用程序的能力通常会超过这个。
但是，从广义上讲，我建议您花一点时间阅读Web应用程序的架构模式，因为您似乎有一些重大的概念混淆。有人可能很容易说，例如，Rails没有“视图”层，因为您可以使用不同的文件系统作为视图代码的存储位置（换句话说：能够更改数据的位置和方式由模型层存储并不意味着你没有拥有模型层。）
（并且不言而喻，知道“严格”或“纯粹”MVC为什么绝对可怕适合Web应用程序也很重要;纯粹形式的MVC对于应用程序非常有用许多独立的方式来启动交互，比如一个带有大量工具栏和输入窗格的文字处理程序，但是当你移动到网络并且只有一种方式 - 一个HTTP请求 - 与应用程序交互时，它的好处很快就会消失。这就是为什么没有“真正的”MVC Web框架;它们都借用了关于关注点分离的某些想法，但没有一个严格实现该模式）
答案 2 :(得分：4)
您似乎将“单独的图层”与“单独的语言/技术”混淆。没有理由不能在单一编程语言中或在适当的模块化框架（例如Django）中适当地分离您的关注点。不必要地增加编程语言/框架是不必要地增加复杂性，这可能会减慢您的初始工作，以至于您的项目永远不会达到需要技术转换的程度。
答案 3 :(得分：3)
无论你使用Django的ORM还是SQLAlchemy，你都有效地获得了3层架构，但如果选择后者，你会放弃Django的一些好处。
答案 4 :(得分：3)
根据我的理解，Django将管理视图和控制器部分，PostgreSQL或MySQL将处理数据。
实际上，Django有自己的ORM，所以它确实将数据与视图/控制器分开。
这是关于MVC的entry from the official FAQ：
“控制器”在哪里适合？在Django的情况下，它可能是框架本身：根据Django URL配置向适当视图发送请求的机制。
如果你渴望获得首字母缩略词，你可能会说Django是一个“MTV”框架 - 即“模型”，“模板”和“视图”。这种分解更有意义。
当然，在一天结束时，归结为完成任务。而且，无论事情是如何命名的，Django都会以对我们来说最合乎逻辑的方式完成工作。
答案 5 :(得分：-1)
有变化，而且有变化。 Django完全分离了域模型，业务规则和表示。您可以更改（几乎）任何几乎没有破损的东西。通过变革，我正在谈论有意义的以最终用户为中心的业务变革。
此（以及之前）问题中的技术混合匹配并不是非常有用。
谁 - 特别是 - 从PHP替换Django模板中获益。它没有更高的效率。没有任何好处，它会更复杂。谁从改变ORM中获益。用户不会也无法分辨。