从Django模型类中解耦Domain类

Question

因此，我完成了我正在构建的Web应用程序的OO分析和设计，现在正在实施。设计决定已经实现了使用Python和Web开发框架Django来实现系统。

我想开始实现一些需要持久性的域实体类。看来Django会让我将它们实现为从Django模型类继承的类，以便使用Django ORM进行持久化。然而，这似乎是我的类实体和持久性机制之间的耦合太强。如果在某个阶段我想要抛弃Django并使用其他Web开发框架，或者只是将Django的ORM替换为另一个选项，会发生什么？现在我必须从头开始重写我的域实体类。

因此，最好将我的域类作为独立的Python类实现，将我所有的业务逻辑封装在这些类中，然后使用一些机制（设计模式，如桥或适配器或???）来委托持久性存储这些领域类到Django ORM，例如通过一个Django模型类，它已经被适当地设置了。

有没有人有关于如何去做这件事的建议？从我所读到的看来，人们只是简单地将它们的领域类实现为继承自Django模型类的类，并且在这个类中混合了业务逻辑。这似乎不是一个好主意，用于下线更改，维护，可重用等。

Answer 1

好吧，Django的使用方式是从Django的基本模型类继承。这是'积极的记录'模式。您的django模型将拥有所有的CRUD和查询方法以及您的业务逻辑（如果您决定添加它）。这在Java世界中被看作是一种反模式，但它的酷炫之处在于它可以加快开发速度。

Answer 2

你能认真设想你可能会只是沟渠Django ORM，但保留一切吗？或者，如果你完全抛弃了Django，你的代码的任何仍然适用？

你不会抱怨，如果你放弃了Django，你将不得不重写所有的模板。当然你会的，这是可以预料的。那么为什么表示层与框架绑定，而不是持久层呢？

这种前期过度分析需要避免。 Django是一个RAD工具，最适合快速迭代开发。尽管如此，许多大公司都会作证，所以它能够建立一些强大的，长期的应用程序。但它不是Java，它不是“企业级”，它不符合面向对象的原则。在Python世界中，这被看作是一个功能，而不是一个bug。

Answer 3

如果您需要不同的持久性机制，则不必“从头开始重新编写模型”。 activerecord风格的持久性系统的重点在于它对模型类施加最小的约束，并且在很大程度上透明。

如果你真的担心，将任何依赖于查询的代码抽象到他们自己的方法中。

Answer 4

我认为没有实现解耦Django模型和域类的解决方案，至少我没有找到任何解决方案。事实上，我所知道的唯一具有这种解耦的ORM仅存在于Smalltalk世界中，它被称为GLORP。它允许您将关系数据库中的域模型保留，而无需修改域类。我目前正试图实现类似的想法来从Django ORM中分离出来。我的动机是目前数据库表和域类之间的强大耦合严重损害了软件的演变。如果我成功，我会再次发帖:)