Должен ли я разделить этот проект Django на два проекта?

Question

У меня есть проект Django. Он всегда должен был иметь два отдельных URL-адреса, обращенных вперед. Один был для учителей, а другой - для студентов. Учитель может опубликовать задания, подождать, пока ученики это сделают, а затем просмотреть работу. Оба сайта имеют очень разную функциональность.

В настоящее время наличие кода в одном проекте становится все более проблематичным. Ученики могут записаться ленивым способом (т.е. после выполнения работы), но учителя не могут. У меня сложная логика, чтобы убедиться, что пользователь играет правильную роль при регистрации и отображении просмотров. У учителей и учеников разные профили (поэтому в настоящее время я не могу использовать AUTH_PROFILE_MODULE). Мне все равно, если у меня есть отдельные таблицы для двух типов пользователей. На самом деле, я предпочитаю это.

Если бы я разделил это на два проекта, я думаю, что многие вещи были бы концептуально проще. Единственная проблема заключается в том, что когда учитель отправляет задание, мне нужно как-то опубликовать это задание на сайте ученика. Но синхронизировать контент было бы намного проще, чем держать двух типов пользователей в одном коде. (Синхронизация происходит только в двух местах, и, кроме того, эти два сайта имеют очень различную функциональность, а также модели и приложения.)

Должен ли я разбить это на два проекта? Если да, то каков безопасный способ обмена данными с одного сайта Django на другой?

Answer 1

Я думаю, что разделение его на два проекта создаст гораздо больше проблем, чем решит, и (из-за моего ограниченного знания приложения) я не думаю, что это имеет смысл - два пользователя являются частьюединой системы подачи заявок и маркировки домашнего задания и, следовательно, их следует разрабатывать как таковые.То, что это может облегчить вашу работу, не означает, что это правильный шаг.

Используете ли вы наследование?Вы написали или использовали дополнительные разрешения?Похоже, вы могли бы очистить два своих концептуально разных профиля, используя декораторы, промежуточное ПО и собственную реализацию AUTH_PROFILE_MODULE.