2017-04-16 52 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操作的項目,一個共同的應用程序,以及共同的邏輯。每個應用都有不同的視圖,命令和模板。 –

相關問題