Python Backend Logic Добавление MVC Framework (Django) - PullRequest
3 голосов
/ 02 января 2011

У меня есть программа на языке 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 (Создать общую модель), потому что я не знаю, как создать общую модель с использованием ORM и SQLAlchemy в Django.

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

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

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

Ответы [ 4 ]

3 голосов
/ 26 марта 2011

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

1 голос
/ 27 марта 2011

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

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

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

0 голосов
/ 26 марта 2011

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

0 голосов
/ 02 января 2011

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

...