Python Django开发是否提供了真正灵活的3层体系结构？

几周前，我问了一个问题：“PHP、Python、PostgreSQL设计是否适合非web业务应用程序？”

许多答案建议跳过PHP部分，使用Django构建应用程序。在探索Django的过程中，我开始质疑我的目标的一个具体方面，以及Django是如何为非web业务应用程序发挥作用的

根据我的理解，Django将同时管理视图和控制器，而PostgreSQL或MySQL将处理数据。但我的目标是清楚地分离这些层，以便数据库、域逻辑和表示都可以更改，而不会对其他层产生重大影响。似乎我只是用Django解决方案将m与VC层分离

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

基本上，我要看的是Django/PHP>Python/SQLAlchemy>PostgreSQL/MySQL的体系结构

---

编辑：在粉丝们因为我问了一个关于Django的问题而对我发火之前，你要意识到：这是一个问题，不是指控。如果我知道答案或者有自己的意见，我就不会问了

无论您使用Django的ORM还是SQLAlchemy，您都有效地获得了一个三层体系结构，尽管如果您选择后者，您将放弃Django的一些好处。

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

您可以选择在Django中使用不同的ORM，但您无法获得管理应用程序（例如，通用视图）。因此，一个不同的ORM会让你从完整的Django自上而下倒退一步，但它并不是从其他异构解决方案倒退一步，因为这些解决方案一开始并没有给你管理应用层内的好处

Django不应该因为没有提供灵活的体系结构而受到批评：它和任何其他解决方案一样灵活，如果您选择交换一个层，那么您就放弃了Django的一些好处

如果您选择从Django开始，那么现在就可以使用Django ORM，以后如果需要切换，可以切换到SQLalchemy。这并不比现在从SQLalchemy开始，然后转移到其他ORM解决方案更困难

您还没有说明为什么需要交换层。不管怎样，这都是一个痛苦的过程，因为必然有很多代码依赖于您当前使用的工具集和库的行为

据我所知，Django将管理视图和控制器，PostgreSQL或MySQL将处理数据

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

这里有一个关于MVC的例子：

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

如果你渴望缩写词，你可能会说Django是一个“MTV”框架——即“模型”、“模板”和“视图”。这种细分更有意义

当然，归根结底，最终还是要把事情做好。而且，不管事情是如何命名的，Django都以一种对我们来说最合乎逻辑的方式完成事情

---

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

但是，从广义上讲，我建议您花更多的时间阅读web应用程序的体系结构模式，因为您似乎有一些主要的概念混淆。例如，可以很容易地说，Rails没有“视图”层，因为您可以使用不同的文件系统作为视图代码的存储位置（换句话说：能够更改模型层存储数据的位置和方式并不意味着您没有模型层）

---

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

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

这个（和上一个）问题中的技术混搭不是很好