Собсна вопрос — как грамотно спроектированть приложение с учётом возможностей среды Delphi?
Например: Задача — занесение в базу данных списка программ с их описанием, возможна древовидная структура с разделами.
Размышления — допустим, работаем с базой firebird, для этого у delphi есть отличные компоненты + на вкладке «Data controls» имеем компоненты для отображения информации сразу из датасетов.
Вопрос где описывать логику работы программы? Прямо в форме писать всю логику, вроде как бы не по фен-шую, которая гласит что надо разделять представление и логику. Выносить всё в отдельный юнит, тогда становится не очень удобно работать с базой, если описывать все настройки датасетов вручную. Можно, кончено, делать на Data Module, но мне кажеться есть способ поизящнее… или нет?
Поделитесь мыслями кто как строит приложения? Какие паттерны или методики применяет.
когда классы, используемые логикой программы вшиваются через её морду нормальный стиль ООП уже потерян. отчасти поэтому делфи и си++ билдер не используют для крупных и серьёзных проектов. вы можете либо разработать приложение быстро, сделав всё прямо в форме, либо создавать экземпляры этих контролов в отдельном модуле (да, такое тоже возможно). второе, конечно будет правильнее, но я бы уже не заморачивался особо.
эх, молодежжж… ну не надо про ООП в делфи и билдере — там все как у всех а кое-что даже лучше ;) Проблема в том, что ООП нормально использует только лучшая, дай бог, половина программеров в ЛЮБОМ ЯП :) проблема говно кода актуальна для всем языков, просто на некоторых(Python, Ruby) его еще не столько наплодили ;)
по делу — когда-то писал заметку о том как можно в делфях и конфетку съесть и не наговнокодить ;)
была мысль для хабра переписать, но не собрался, так что смотреть тут — pyatochkin.blogspot.com/2010/10/delphi-mvc-pattern.html
Самый минимум что должно быть это:
1. Слой работы с базой представляющий данные таблиц как объекты. (Чтение/Запись/Изменение/Удаление)
2. Слой бизнес логики работающий с этими объектами.
3. Слой обработчиков формы, который дергает бизнес логику.
4. Формочка.
Кроме этого бизнес логику еще могут дергать различные шедулеры, которые выполняют операции по расписанию.
Но реализуя все это на Delphi вы обрекаете себя на отсутствие приятных фреймворков и вам придется многие вещи переизобретать самому.
Преимущества легкой работы с базой и быстрого клепания формочек уже давно есть не только у Delphi, но и у многих других (например Java и C#).
Так что рекомендую рассмотреть вариант перехода, на более популярные и поддерживаемые языки.
Перейти на другие языки не могу. Проект уже реализован, нужно дополнить функционал и поддерживать его… Поэтому Delphi!
Но писать тем путём, к которому подталкивает среда уже больше нету сил, кучу кода приходится писать из формы в форму… Да и что — то изменять уже становится проблемно… Поэтому и хочется «причесать» проект. Но вот как это сделать с минимальными потерями.
Причесать с минимальными потерями проект, вся логика которого реализована прямо в обработчиках формы, занятие очень проблематичное.
Постарайтесь сначала вынести в отдельный слой всю работу с базой. Что бы не из обработчиков формочки кидались запросы в базу, а отдельная сущность по запросу формировала экземпляры объектов и уже с ними велась работа. Эта же сущность в итоге должна применять изменения сделанные в объектах на базу.
После этого можно попробовать вынести из обработчиков всю бизнес логику и по возможности объединить схожую.
Не знаю насколько в этом плане хорош FireBird, но иногда хорошим подходом бывает переложить бизнес-логику в обработчики и исполняемые процедуры SQL-сервера. Тогда вся логика сидит на сервере, а приложения банально работают с базой через таблицы-запросы. Удобно, если планируются альтернативные клиенты (мобильный, PHP-веб и т. д.).
как вижу, реального обсуждения архитектурных вопросов не вышло… а жаль… ладно, еще раз хочется напомнить автору вопроса, что Delphi обладает массой возможностей для написания лаконичного и поддерживаемого кода с нормальной архитектурой. по архитектуре ПО (обычно именно это подразумевают под «проектированием приложения») во всех языках идеи почти одни и теже ;) — тут спасает чтение литературы по разработке ПО (паттерны это еще не все...), потом пробуем применить прочитанное, повторять предудыщие 2 действие до достижения просветления :)
Да я только за констурктивное обсуждение, ибо проблема для меня актуальна.
Честно говоря, прочитав вашу статью, яснее не стало. Примеры кода не помешали бы.
Самое обидно что и книжек нет толковых, сколько не смотрел в инет-магазинах, либо для новичков, либо для профи, но не затрагивают аспекты проектирования. Я имею в виду книги по Delphi, такое впечатление что там по этому поводу не заморачиваются. Если кто знает, поделитесь.
сделал то, на что давно не мог решится ;) — наброcал пример к статье про MVC в delphi. в принципе, идея с фреймами должно быть ясна… про иерархию форм тема не раскрыта, но если будет интерес, можем продолжить.
Решайте задачи инструментами, для этого предназначенными.
У FB замечательно работают триггеры и хранимые процедуры, у Delphi - скорость проектирования GUI и возможности давно проверенных фреймворков для различных применений. Для Вашего случая - классические древовидные структуры никак не связаны с языком программирования и БД.
Простой
Простой
