Обеспечивает ли разработка Django действительно гибкую трехслойную архитектуру?

Question

Несколько недель назад я задал вопрос "Подходит ли дизайн PHP, Python, PostgreSQL для не-веб-бизнес-приложений?" Подходит ли дизайн PHP, Python, PostgreSQL для бизнес-приложение?

Во многих ответах рекомендуется пропустить кусок PHP и использовать Django для создания приложения. Изучая Django, я начал подвергать сомнению один конкретный аспект моих целей и то, как Django вступает в игру для не-веб-приложения для бизнеса .

Исходя из моего понимания, Django будет управлять как компонентами вида, так и контроллера, а PostgreSQL или MySQL будет обрабатывать данные. Но моя цель состояла в том, чтобы четко разделить слои, чтобы база данных, логика домена и представление могли быть изменены без существенного влияния на другие. Кажется, что я только отделяю M от слоев VC с помощью решения Django.

Так что, мне контрпродуктивно строить доменный слой в Python с помощью SQL-алхимии / эликсира ORM , PostgreSQL для уровня базы данных, и затем все еще использовать Django или PHP для уровня представления? Это возможно или чистое безумие?

По сути, я бы посмотрел на архитектуру Django / PHP> Python / SQLAlchemy> PostgreSQL / MySQL .

Редактировать: Прежде чем фанаты рассердятся на меня за то, что я задал вопрос о Джанго, просто поймите: это вопрос, а не обвинение. Если бы я знал ответ или имел собственное мнение, я бы не спросил!

Answer 1

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

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

Django не следует критиковать за то, что он не предоставляет гибкую архитектуру: он такой же гибкий, как и любое другое решение, вы просто отказываетесь от некоторых преимуществ Django, если решите поменять слой.

Если вы решите начать с Django, вы можете использовать Django ORM сейчас, а потом, если вам нужно переключиться, вы можете перейти на SQLalchemy. Это будет не сложнее, чем начать с SQLalchemy сейчас, а затем перейти к другому решению ORM.

Вы не сказали, почему ожидаете замены слоев. Это будет болезненный процесс, несмотря ни на что, потому что всегда есть много кода, который зависит от того, какой набор инструментов и библиотеку вы используете в настоящее время.

Answer 2

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

В более широком смысле, однако, я бы посоветовал вам потратить немного больше времени на чтение архитектурных шаблонов для веб-приложений, поскольку у вас, похоже, происходит серьезная концептуальная путаница. Можно с такой же легкостью сказать, что, например, в Rails отсутствует слой «представления», поскольку вы можете использовать разные файловые системы в качестве места хранения кода представления (другими словами: возможность изменять, где и как данные хранится в слое модели, это не значит, что у вас нет слоя модели).

(и само собой разумеется, что также важно знать, почему «строгий» или «чистый» MVC абсолютно ужасный подходит для веб-приложений; MVC в чистом виде полезен для приложений со многими независимые способы инициирования взаимодействия, такие как текстовый процессор с множеством панелей инструментов и панелей ввода, но его преимущества быстро начинают исчезать, когда вы переходите в Интернет, и у вас есть только один способ - HTTP-запрос - взаимодействовать с приложением. Вот почему нет «настоящих» веб-фреймворков MVC, все они заимствуют определенные идеи о разделении интересов, но ни один из них не реализует шаблон строго)

Answer 3

Вы, кажется, путаете «отдельные слои» с «отдельными языками / технологиями». Нет никаких причин, по которым вы не можете надлежащим образом разделить свои проблемы в рамках одного языка программирования или в рамках подходящей модульной структуры (такой как Django). Излишне умножение языков программирования / фреймворков просто излишне умножает сложность, которая, скорее всего, настолько сильно замедлит ваши первоначальные усилия, что ваш проект никогда не достигнет точки, где он нуждается в технологическом переключении.

Answer 4

Насколько я понимаю, Django будет управлять как элементами представления, так и контроллеров, а PostgreSQL или MySQL будет обрабатывать данные.

Не совсем, у Django есть собственный ORM, поэтому он отделяет данные от представления / контроллера.

вот запись из официального FAQ о MVC:

Где тогда находится «контроллер»? В случае с Django, вероятно, это сама структура: механизм, который отправляет запрос в соответствующее представление, в соответствии с конфигурацией URL Django.

Если вы жаждете аббревиатур, вы можете сказать, что Django - это фреймворк «MTV», то есть «модель», «шаблон» и «представление». Такая разбивка имеет гораздо больший смысл.

В конце концов, конечно, все сводится к тому, чтобы что-то сделать. И, независимо от того, как вещи называются, Django выполняет вещи наиболее логичным для нас способом.

Answer 5

У вас фактически есть трехслойная архитектура, независимо от того, используете ли вы Django ORM или SQLAlchemy, хотя вы отказываетесь от некоторых преимуществ Django, если выберете последнее.

Answer 6

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

Технология mix-n-match в этом (и предыдущем) вопросе не очень полезна.

Кто конкретно получает выгоду от замены шаблонов Django на PHP. Это не более продуктивно. Это сложнее без пользы. Кому выгодно менять ORM. Пользователи не будут и не могут сказать.