2017-04-16 53 views
0

我看到一些类似的问题,但它们看起来不一样或有答案。在同一个项目中的两个应用程序之间共享Django用户模型

我正在练习Django并试图做一个简单的荷兰拍卖项目。最初我认为这个想法是创建两个不同的应用程序,一个买方应用程序和一个卖方应用程序,并且让它们共享数据库(或三个应用程序,一个普通应用程序,一个买方应用程序和一个卖方应用程序)。然而,我越深入这看起来就越复杂 - 我觉得Django并不是真的意味着有不同的应用程序,这些应用程序是围绕着从一组表中共享所有数据而设计的(也许我错了?),松散地基于我已经发现的关于不得不修改迁移工作来适应这种情况的方式。

因此,想法#2,只是做一个应用程序,通过仔细管理视图分离出的功能,但只保留一组模型,因为几乎所有我能想到的数据(用户,产品等) )无论如何都是共享的。这看起来好像让Django做了所有的数据管理,而不必为数据库设计而烦恼。但是,我担心管理观点会变得过于复杂。

也许有一个想法#3,这种项目是有意义的,我没有考虑过,因为我是一个新手,也许是一个告诉我,Django甚至不是这个工作的正确工具...

我尝试编程思想#1,它很快成为意大利面条,只有当事情非常小时才起作用。我目前正在研究想法#2,到目前为止我认为这样做还行,但是我很难概念化如何在视图中分离东西,但这可能只是我缺乏经验。

所以我的问题是:是否有一个明显的资源,我错过了这种信息?如果是这样,你能指点我吗?

+0

你的想法#2似乎准确。我有多个以相同方式制作的项目。哪部分不工作? –

+0

没有什么东西不能工作,我认为这是我不确定如何处理视图,命令,查询等,以保持事物之间的良好分离和清晰(在这种情况下)卖家和买家。从某种意义上说,我认为我需要更多的知识才能明确地提出问题。一个典型的Django开发人员是否会将卖方视图放在一个文件中(比如seller_views.py)并将买方视为另一个文件以避免混淆?我想我在问是否有这样一个项目/应用程序普遍接受的最佳做法? – TrivialCase

回答

1

里面Django项目:

manage.py startapp sellers 
manage.py startapp buyers 
manage.py startapp common 

这三个应用程序添加到settings.py。根据你的Django的版本,它可以是'sellers','buyers','common''seller.apps.SellerConfig'等等。

将模型写入common/models.py以及与这两个应用程序相关的任何其他逻辑。

然后,在您的卖家或买家的观点:

from common.models import * # or a particular model

希望这有助于。

+0

这对我来说很好,我只是犹豫不决,因为它不符合Django的精神,只有包含没有视图的模型的应用程序。但我猜这个框架并不是真的为这种应用程序设计的? – TrivialCase

+0

我认为是专为这种类型的应用程序。我个人有一个包含5个应用程序的项目:一个针对客户,一个针对卖家(用户,但具有不同的逻辑),站点管理员(使站点运行的人),一个针对ETL操作的项目,一个共同的应用程序,以及共同的逻辑。每个应用都有不同的视图,命令和模板。 –

相关问题