Tiểu sử và cấu trúc mô-đun Django

Question

Tôi đang phát triển một ứng dụng Django, một hệ thống lớn yêu cầu nhiều ứng dụng phụ để giữ mọi thứ gọn gàng. Vì vậy, tôi có một thư mục cấp cao nhất mà là một ứng dụng Django (vì nó có một tập tin rỗng models.py), và nhiều thư mục con, cũng là ứng dụng trong chính chúng.

Lý do tôi đã đặt đơn đăng ký của mình theo cách này là do các ứng dụng con được tách riêng, nhưng chúng sẽ không bao giờ được sử dụng riêng, bên ngoài ứng dụng gốc. Do đó, không phân biệt chúng một cách riêng biệt.

Khi cài đặt ứng dụng của tôi, các tập tin cài đặt có bao gồm một cái gì đó như thế này:

INSTALLED_APPS = (
    ... 
    'myapp', 
    'myapp.subapp1', 
    'myapp.subapp2', 
    ... 
) 

... mà rõ ràng là tối ưu. Điều này cũng có kết quả hơi khó chịu khi yêu cầu tất cả các ứng dụng con được gọi bằng tên "bên trong" của chúng (ví dụ: subapp1, subapp2, v.v.). Ví dụ, nếu tôi muốn thiết lập lại các bảng cơ sở dữ liệu cho subapp1, tôi phải gõ:

python manage.py reset subapp1 

Đây là khó chịu, đặc biệt là bởi vì tôi có một tiểu ứng dụng gọi core - đó là khả năng xung đột với tên của ứng dụng khác khi ứng dụng của tôi được cài đặt trong dự án của người dùng.

Tôi có thực hiện điều này một cách hoàn toàn sai hay không, để đưa các ứng dụng "bên trong" này được gọi bằng tên đầy đủ của chúng?

Answer 1

Bạn đang làm đúng cách, vì bản thân django cũng làm như vậy. Ví dụ: ứng dụng quản trị được đăng ký trong INSTALLED_APPS là django.contrib.admin, nhưng để đặt lại, bạn phải sử dụng manage.py reset admin và thực sự, manage.py reset django.contrib.adminkhông hoạt động.

Nó có thể được coi là một lỗi trong django ...

Tuy nhiên, bạn không nên lo lắng bởi các cuộc xung đột tên, bởi vì bạn nên luôn luôn chạy django bên trong một môi trường virtualenv, bị cô lập với phần còn lại của cài đặt python. Đây là một giải pháp cực kỳ mạnh mẽ và linh hoạt hơn chạy django trên một cài đặt python bình thường. Thông tin thêm, ví dụ: tại đây: http://mathematism.com/2009/jul/30/presentation-pip-and-virtualenv/