Вопрос по архитектуре приложения

[FANATIC]

Привет всем! У меня возник такой вопрос.
В университете нас учат тому, чтобы строить модель предметной области через классы. То есть, к примеру, у нас есть аптека, со сложной бизнес-логикой, большим набором бизнес-правил, мы пишем классы "Лекарство", "Поставщик", "Покупка" и т.д. Строим набор неких бизнес правил. Дальше уже эти классы мы отражаем на БД, ну и отдаем их представлению. Все хорошо, все замечательно, мы получаем расширяемое и легко поддерживаемое приложение, но для того, чтобы обеспечить взаимодействие с БД мы должны написать еще некий набор классов, чтобы отдавать наши сущности представлению, мы должны писать еще (к примеру унаследовать от QAbstractItemModel свой класс, или придумывать еще что-то).
С другой стороны мы можем не задумываться о написании сущностей, все реализовывать с помощью уже существующей архитектуры MVC, используя QSqlTableModel, QSqlRelationalTableModel для доступа к БД. Тут все хорошо, бизнес-логику можно реализовывать в виде хранимым процедур, и т.д. Но вот если СУБД их не поддерживает, тогда насколько я понимаю, код может превратиться в "неподдерживаемое  нечто".

Какой вариант является более правильным, какой стоит использовать в проектах? Или быть может в чем-то неправ?

Направьте меня на путь истинный:)

[crossly]

что касается БД.... то все что можно реализовать средствами СУБД нужно реализовывать средствами СУБД...

[lit-uriy]

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


А то чему учат, я думаю - правильно. Т.к. создание своих моделей занятие довольно регулярное. А ПО, тупо отображающее таблицы из БД, можно и вовсе не писать, а сунуть заказчику какой-нибудь инструмент с графическим интерфейсом для администрирования БД.

П.С.
Данная тема скорее общая, чем относящаяся к Qt. Т.к. MVC есть не только в Qt.

[sergek]

То есть, к примеру, у нас есть аптека, со сложной бизнес-логикой, большим набором бизнес-правил, мы пишем классы "Лекарство", "Поставщик", "Покупка" и т.д. Строим набор неких бизнес правил. Дальше уже эти классы мы отражаем на БД, ну и отдаем их представлению.

Ну, если опустить процесс бизнес-моделирования, определения требований, создания модели вариантов использования, аналитической модели, архитектуры, а сразу переходить к модели проектирования...

Тут все хорошо, бизнес-логику можно реализовывать в виде хранимым процедур, и т.д. Но вот если СУБД их не поддерживает, тогда насколько я понимаю, код может превратиться в "неподдерживаемое  нечто".

Не понял, речь о том, где реализовывать бизнес-логику - на клиенте или в СУБД? На мой взгляд, предпочтительнее - в промежуточном слое, на сервер приложений. Это немного менее эффективно, чем в СУБД, но значительно лучше, чем на клиенте.

что касается БД.... то все что можно реализовать средствами СУБД нужно реализовывать средствами СУБД...

Есть такой подход... Теперь уже можно сказать, был. Лет 15-20 назад это считалось передовым краем, и в среде программистов так и формулировалось - "все, что можно реализовать в хранимых процедурах, надо реализовывать в виде хранимых процедур". То было время тотального господства модели клиент/сервер.
К чему это привело? Система, построенная на этих принципах за 10-15 лет эксплуатации (эксплуатация непременно подразумевает модификацию и развитие) постепенно превращалась в монолитный кусок кода, который не только было трудно масштабировать, но и дорабатывать под новые условия. И появилось уже новое правило - "изменения вносить в проект только в том случае, если изменения не вносить нельзя".
А проекты, которые строились на многозвенной архитектуре, оказались более живучи.
Хотя, конечно, понятно - всему свое время.

[Amigo_sa]

А проекты, которые строились на многозвенной архитектуре, оказались более живучи.

Не могли бы вы уточнить, что такое многозвенная архитектура? Возможно, линком помочь...

[lit-uriy]

>>в промежуточном слое, на сервер приложений.
Хотелось бы услышать о реализации такого сервера на С++/Qt. Т.к. в большинстве источников речь идёт о реализации имеющей виртуальную машину (Java, Python)

[sergek]

>>в промежуточном слое, на сервер приложений.
Хотелось бы услышать о реализации такого сервера на С++/Qt. Т.к. в большинстве источников речь идёт о реализации имеющей виртуальную машину (Java, Python)

Лет 10 назад сам задавался таким вопросом. Знающие люди советовали free ORB (например, http://www.cs.wustl.edu/~schmidt/ACE.html, http://www.cs.wustl.edu/~schmidt/TAO.html). Мне не понравилось - слишком тяжеловесно, да и фриварность у них условная, по-моему. Поэтому написал свою библиотеку, обеспечивающую объектное сетевое взаимодействие распределенных приложений: http://www.freesoft.ru/?id=671951. Там достаточно полное описание библиотеки с примерами реализации и со всеми исходниками. Работает в виндах и Linux. Может, пригодится.
Недавно доработал ее под Qt, есть примеры. Правда, в 4.6.3 не пробовал ее собирать - жарко очень... Вот жара спадет, поставлю Федору 13 и буду все проверять.

[sergek]

Не могли бы вы уточнить, что такое многозвенная архитектура? Возможно, линком помочь...

А интернета у вас нет?  Если вы надо мной не издеваетесь, то, в двух словах, - это системы, в которых клиентские программы соединяются не напрямую с СУБД (как в двухзвенных системах клиент/сервер), а к промежуточному программному слою - серверу приложений (сервер - в смысле не железяка, а программа). Сервер приложений соединен с СУБД, обрабатывает данные, полученные из нее в соответствии с заложенными правилам (часто употребляют термин "бизнес-логика") и отдает клиенту. На клиенте - минимум обработки, как правило, связанный только с отображение результатов запроса. Такие системы лучше масштабируются, меньше зависят от СУБД (поскольку обрабатывающие процедуры вынесены из хранимых процедур в серверную программу).

[Amigo_sa]

sergek, спасибо большое за разъяснения.  Вашими словами намного понятнее, чем успел прочитать.
Никак не могу избавиться от привычки спрашивать незнакомое.

[FANATIC]

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

Мне просто был интересен, так скажем, Qt-подход к построению подобных приложений И насколько я понимаю, подход с многозвенной архитектурой и ORM, не очень распространен в Qt среде?

[lit-uriy]

>>не очень распространен в Qt среде?
он не то чтобы не распространён. В Qt нет штатных средств для ORM. И сторонних тоже нет. Есть тут на форуме упоминание двух проектов, но они вроде ещё сыроваты.

А многозвенка это скорее самостоятельный набор библиотек.

[crossly]

Есть такой подход... Теперь уже можно сказать, был. Лет 15-20 назад это считалось передовым краем, и в среде программистов так и формулировалось - "все, что можно реализовать в хранимых процедурах, надо реализовывать в виде хранимых процедур". То было время тотального господства модели клиент/сервер.
К чему это привело? Система, построенная на этих принципах за 10-15 лет эксплуатации (эксплуатация непременно подразумевает модификацию и развитие) постепенно превращалась в монолитный кусок кода, который не только было трудно масштабировать, но и дорабатывать под новые условия. И появилось уже новое правило - "изменения вносить в проект только в том случае, если изменения не вносить нельзя".
А проекты, которые строились на многозвенной архитектуре, оказались более живучи.
Хотя, конечно, понятно - всему свое время.

это проблемы проектирования ... проблема переносимости это конечно проблема.... НО... во первых глупо платить деньги скажем за Oracle и не использовать всю его мощь... к тому же надо четко понимать архитектуру самой СУБД... и знать, что одни и те же вещи в разных СУБД реализованы по разному.... и по сему ORM и тот же сервер приложений вещь конечно хорошая, НО если вам нужна производительность и максимальная отдача от СУБД, то не поленитесь хорошенько изучить ее архитектуру и потратить время на проектирование.... не знаю как на счет 15-20 лет, но я как ДБА и сейчас придерживаюсь этого мнения... как впрочем и многие  админы и разработчики  известных СУБД (Oracle, Sybase, MSSQL ...)

[sergek]

НО если вам нужна производительность и максимальная отдача от СУБД, то не поленитесь хорошенько изучить ее архитектуру и потратить время на проектирование.... не знаю как на счет 15-20 лет, но я как ДБА и сейчас придерживаюсь этого мнения... как впрочем и многие  админы и разработчики  известных СУБД (Oracle, Sybase, MSSQL ...)

Да кто ж с этим спорит... Особенно, что касается разработчиков СУБД. Только это не вся правда. Эта правда аналогична сравнению производительности MSSQL и Oracle. Помните, лет 5 назад?
Только производительность СУБД заключена не только в хранимых процедурах, и не столько...
Когда мы начинаем говорить о переносимости и масштабируемости решений, мы уже подразумеваем определенный класс задач. Это не задачи масштаба предприятия и, наверное, даже не регионального уровня. То, о чем я говорю - это наблюдение тенденций, а не теоретические рассуждения. Времена шаманов с бубнами, которые могут на дохлой железяке раскочегарить систему, проходят...
А жаль!

[crossly]

я вообще то говорю не только о хранимых процедурах.... о говорю об элементарном sql.... к примеру разберитесь со значение null в oracle и mssql... и вы будите удивлена... элементарный запрос может стать не переносимым.. вернее переносимым, но результат такого переноса вас удивит... и заставит провести немного времени в раздумии "А что же не так??"