将领域类与Django模型类解耦
我已经完成了我正在构建的一个网页应用的面向对象分析和设计，现在开始进入实现阶段。我决定使用Python和Django这个网页开发框架来实现系统。
我想开始实现一些需要持久化的领域实体类。看起来Django要求我把这些类继承自Django的模型类，这样才能使用Django的ORM（对象关系映射）来进行持久化存储。但是，这样会导致我的类和持久化机制之间的耦合太紧密。如果将来我想换掉Django，使用其他的网页开发框架，或者不再使用Django的ORM，那我就得从头开始重写我的领域实体类。
所以，我觉得更好的做法是把我的领域类实现为独立的Python类，把所有的业务逻辑封装在里面，然后使用某种机制（比如桥接模式、适配器模式等）来将这些领域类的持久化存储委托给Django的ORM，比如通过一个适当设置的Django模型类。
有没有人能给我一些建议，怎么去实现这个呢？从我所读到的资料来看，很多人只是把他们的领域类实现为继承自Django模型类的类，并且把业务逻辑混合在这个类里面。我觉得这样做对于后续的修改、维护和重用等方面都不是个好主意。
4 个回答
如果你想换一种数据保存的方式，其实不需要“从头开始重写你的模型”。使用类似ActiveRecord的保存系统的主要目的就是对模型类的限制很少，而且大部分操作都是透明的，不会影响到你的代码。
如果你真的很担心，可以把依赖于查询的代码单独抽取成自己的方法。
你能想象一下，真的有可能放弃Django的ORM（对象关系映射），但其他的都不动吗？或者说，如果你完全放弃Django，你的代码还有用吗？
你不会抱怨说，如果放弃Django，你就得重写所有的模板。那是理所当然的嘛。所以为什么展示层（就是用户看到的部分）和框架绑定在一起没问题，但持久层（就是数据存储的部分）就不行呢？
这种过度分析的想法其实是没必要的。Django是一个快速开发工具，最适合快速、反复的开发。尽管如此，它也能构建一些强大且长期使用的应用，很多大公司都能证明这一点。但它不是Java，也不是那种“企业级”的东西，而且在面向对象的原则上也不太符合。在Python的世界里，这被视为一种优点，而不是缺点。
在使用Django时，最好的做法是从Django的基础模型类继承。这种做法叫做“主动记录”模式。你的Django模型会自带所有的增删改查（CRUD）和查询方法，还有你自己添加的业务逻辑（当然，如果你愿意的话）。在Java的世界里，这种做法被认为是不太好的模式，但它的好处是可以让开发速度非常快。