Логика Python Backend с добавлением MVC Framework (Django)

У меня есть программа Python CLI с моделями баз данных SQL, и я хочу добавить внешний интерфейс с инфраструктурой MVC (например, Django). Как лучше всего связать мою программу с фреймворком, если я уже определил свои модели?

Я тоже:

  1. Перепишите модель, чтобы она использовалась как Django, так и моей программой.
  2. Напишите слой, который взаимодействует между Django и моей программой.
  3. Удалите модель из моей программы и позвольте Django справиться с ней.

Вариант 1. Общая модель

          My Program
        /      |    \
  Binaries    Model  Classes
               |
             Django
             /    \
         View     Controller

Вариант 2. Создайте библиотеку-мост

          My Program
        /      |    \
  Binaries    Model  Classes
               |
            My-Bridge
               |
             Django
             / |    \
         View  Model Controller

Вариант № 3: использовать Django для большей части работы и удалить модель из моей программы

  Classes
         \
          My Program
        /      | 
  Binaries     |
               |
            My-Bridge
               |
             Django
             /   |    \
         View   Model   Controller

Я избегаю варианта № 1 (создать общую модель), потому что не знаю, как создать общую модель с помощью Django ORM и SQLAlchemy.

Я не уверен в выборе № 2 (создание моста), потому что я не знаю, использует ли он Django в полной мере. Из документации кажется, что Django должен обрабатывать модель, учитывая, что это структура MVC.

Я также избегаю варианта № 3 (удаление модели из программы), потому что мне придется переписать всю логику ORM SQLAlchemy, которая использует модель SQLAlchemy в My-Program.

Что вы думаете, ребята? Какой вариант лучше, учитывая, что я уже написал CLI-версию своей программы?


python django backend interaction
person Lionel    schedule 02.01.2011    source источник
comment
Отличный вопрос. Это то, что мне тоже нужно решить, но в моем случае я собираюсь начать новый проект. Я хотел бы, чтобы внутренние и внешние части были разделены точно так, как вы описываете.   -  person Piotr Dobrogost    schedule 27.03.2011
comment
Ваш интерфейс (Django) предназначен только для представления данных, управляемых вашим существующим приложением, или он изменяет данные сам по себе?   -  person Piotr Dobrogost    schedule 27.03.2011
comment
Хотелось бы, чтобы он также управлял данными, потому что есть много других более простых веб-интерфейсов для отображения данных.   -  person Lionel    schedule 27.03.2011

Ответы (4)


arrow_upward
3
arrow_downward

Я люблю Django, но, учитывая этот сценарий, вы также можете взглянуть на Pylons, так как они поддерживают SQLAlchemy. Или вы все еще можете работать с SQLAlchemy, импортировав его в свои представления. см. этот пост в примере для этого.

person Kenny Shen    schedule 26.03.2011
comment
Это, вероятно, лучший способ пойти. Модель ORM, которую вы используете, определенно диктует, как должна быть реализована интеграция между бэкендом и внешним интерфейсом. - person Lionel; 27.03.2011
comment
@ Лайонел Ну, я бы не согласился с твоим заявлением. - person Piotr Dobrogost; 27.03.2011

arrow_upward
1
arrow_downward

Начнем с того, что заметим, что интерфейс, который изменяет данные в обход сервера, не выглядит хорошим дизайном. Сказав это, я не вижу никаких технических причин, по которым это невозможно сделать. Мы должны помнить, что именно база данных обеспечивает целостность данных. Вот почему вы должны иметь возможность использовать разные ORM или одну ORM с разными моделями с одной и той же базой данных.

Модель ORM, которую вы используете, определенно диктует, как должна быть реализована интеграция между бэкендом и внешним интерфейсом.

Я бы не сказал, что это диктует выбор. Было бы проще иметь один и тот же ORM для серверной части и интерфейса, но это не обязательно.

person Piotr Dobrogost    schedule 27.03.2011

arrow_upward
0
arrow_downward

Я бы попытался перенести большую часть логики «Моей программы» в импортируемый модуль. Затем попросите django импортировать это и поделиться с ними настройками базы данных. Также можно было бы запустить экземпляр django и выполнять черновую работу, а «Моя программа» выполнять удаленные вызовы. Конечно, это, вероятно, займет больше всего работы.

person kmwhite    schedule 02.01.2011
comment
А модели? Мне пришлось бы использовать Django ORM для отображения данных, и мне пришлось бы использовать SQLAlchemy в моей программе. - person Lionel; 03.01.2011

arrow_upward
0
arrow_downward

Переписывание моделей в соответствии с API django звучит как наименьший объем работы и самый «правильный» способ решить вашу проблему. Если вы не выполняете какой-либо «расширенный» доступ к базе данных, Djangos ORM должен быть в состоянии справиться с тем, что вы хотите сделать чисто. Использование полного стека также принесет дивиденды позже, когда вы решите, что вам нужны формы, обертывающие ваши модели, и все другие части фреймворка, которые ожидают структуру модели.

person Josh Smeaton    schedule 26.03.2011