Там много говорят о модели-view-controller, model-view-viewmodel, model-view-presenter и т.д. в эти дни.
Что вы видите как лучший шаблон для использования с компонентами delphi и без данных?
Как вы обычно реализуете его?
Вы можете использовать шаблон представления представлений модели в его пассивном представлении. Некоторое время назад я написал сообщение об этом. http://www.danieleteti.it/?cat=18
Вы также можете использовать посредник Model Gui (http://www.andypatterns.com/index.php/design_patterns/model_gui_mediator_pattern)
Цель MVC - развязка. Развязанные системы явно намного легче поддерживать, и, возможно, легче развиваться в первую очередь. Можете ли вы радикально изменить дизайн БД, не влияя на ваш код GUI? Можете ли вы полностью изменить свой графический интерфейс, не слишком сильно влияя на ваш дизайн БД? Является ли согласованность данных в БД независимо от порядка, в котором происходит графический интерфейс или события на основе формы? Это вопросы, которые действительно имеют значение, и MVC - это подход к тому, чтобы ответить на эти вопросы в позитиве.
Я не эксперт, но в прошлом я был сожжен этими немногими вещами:
Попытка поместить все явные ссылки на доступ к БД и компоненты доступа БД в модуль данных. Это не имеет большого значения, если вы ошибаетесь на стороне слишком большого количества datamodules, но будьте осторожны, чтобы не ставить слишком много не связанных между собой элементов доступа к БД в одном и том же формате данных (комбинирование кода намного проще, чем разделение кода).
Хотя очень удобно подключить все ваши компоненты БД к основному компоненту соединения/сеанса во время разработки (и это одна из сильных сторон Delphi), также очень полезно иметь возможность явно устанавливать connectionString или сеанс, или ссылку на соединение динамически во время выполнения, особенно если вы хотите использовать модуль данных в другом проекте, не добавляя в исходный блок соединения с DB проекта, если таковой существует.
Сделайте все возможное, чтобы как можно меньше привести бизнес-логику в свои события компонента. Это естественное расширение использования компонентов, не поддерживающих данные. Трудно с этим справиться, потому что делать это последовательно, похоже, делать дополнительную работу, особенно в новом проекте, и вы говорите себе, что позже будете реорганизовать; конечно, вы знаете, что ложь, потому что позже никогда не приходит.
Для точки (3) может потребоваться пример. Существует значительная огромная разница в ясности и ремонтопригодности между следующими двумя фрагментами, хотя это может быть не очевидно, когда вы смотрите на них изолированно, как здесь:
// "LoadEntries" is (loosely) analogous to the "C" in MVC.
// What happens /inside/ LoadEntries is the Model,
// and button interaction is part of View functionality.
// MyList may also be viewable on screen as part of
// the View.
procedure TForm.Button1Click(Sender: TObject);
begin
MyDataModule.LoadEntriesIntoMyList(MyList); // LoadEntries is the "C" in MVC
end;
вместо
// The "controller" is missing. That omission of the essential
// decoupling mechanism between the model and the view will
// cost you or your company lots of money!
procedure TForm.Button1Click(Sender: TObject);
begin
MyList.Clear;
MyDataModule.qMyData.Open;
while not MyDataModule.qMyData.Eof do
begin
NewItem := MyList.AddNewItem();
NewItem.Blah := MyDataModule.qMyData.Fields['Field1'].Value;
...
MyDataModule.qMyData.Next;
end;
end;
В настоящее время я читаю книгу django, и их дизайн MVC действительно впечатляет. Любая часть модели, представления или контроллера, ориентированного на реализацию, может быть заменена другой системой без (значительно), воздействующей на две другие. Несомненно, другие структуры имеют сходные подходы, но я не могу комментировать их.
IMHO часть контроллера в шаблоне контроллера модели часто представляет собой накладные расходы для приложений delphi из-за характера таких приложений, основанных на событиях. Разделение модели и представления работает так же, как и на любом другом языке программирования.
Я переключился на С# и MVVM-модель (WPF).
Шутки в сторону начинаются с рассмотрения Объектно-ориентированный дизайн на форуме Embarcadero.
Вы можете взглянуть на tiOpf, так как я вижу, что у них есть некоторые компоненты для построения графического интерфейса. Существует также InstantObjects, но я не знаю, будет ли он еще развиваться.
Основная проблема с компонентами VCL заключается в том, что он не поддерживает привязку к объектам/спискам. Таким образом, решение заключается в использовании виртуального набора данных, такого как EzSepcials и компонентов, осведомленных о данных, или для использования компонентов, не относящихся к данным, и для записи медиаторов для отдельных компонентов. Я должен упомянуть Virtual TreeView.
Я думаю, что типичный MVC не подходит для приложений delphi. Я видел реализации, которые добавили так много шаблонов, что было страшно. У них было больше работы с самим собой, что у них была проблема, которую они пытались решить.
Я написал структуру MVC для delphi, но пока я использую ее только в своих собственных проектах. Я пока не нахожу его в производстве. Он основан на Model и Viewer, управляющий является только соединительной тканью между ними.
Модель содержит или обрабатывает бизнес-логику, а зритель строго предназначен для просмотра (GUI). Итак, поток выглядит следующим образом:
Я автоматизировал это, так что, когда команда вызывается из представления, автоматически вызывается соответствующий метод обработчика команды в модели. Когда модель завершает изменения, представление обновляется. Если есть метод, который соответствует имени команды в представлении, этот метод вызывается, в противном случае вызывается общий метод "UpdateView". Передаются только те данные, которые были изменены, и обновляются только релевантные части обзора. Если для модели имеется несколько представлений, все они обновляются. Среда для передачи данных назад и вперед - это XML, потому что она гибкая, поэтому нет никаких проблем с передачей данных любого типа. Да, производительность может пострадать в крайних случаях, но, похоже, все работает. Мне просто нужно очистить его, чтобы было возможно как можно меньше шаблонов и накладных расходов.
Возможно, если есть интерес, я могу блог о решении и очистить его для качества продукции.
Я не использую специально MVC или другие шаблоны, но то, что я делаю сегодня (пока я использую элементы управления DB для синхронизации данных), заключается в том, чтобы делать что-то таким образом:
Каждая форма сущности ( "сущность" в очень свободный путь, я ссылаюсь на формы, которые появляются сначала, когда пользователь нажимает на меню itens или кнопки) имеют свой Datamodule с их данными компоненты.
DM.SearchCustomers(<conditions>) или DM.SaveData(). Формы не выполняют SQL, период.У меня есть стандартная форма (и datamodule) иерархия, поэтому большинство простых форм регистрации (например, Способы оплаты) создаются с небольшим или отсутствующим кодом.
Дельфи не хватает (как сказано выше) привязки данных для объектов, и большинство элементов управления либо являются данными, либо полностью игнорируют его.
Я вижу, что в этой области есть несколько новых инициатив.
Stefan Glienke написал сообщение о MVVM и библиотеке delphi под названием DSharp в декабре 2011 года.
Теперь кажется, что они пытаются реализовать нечто похожее на Calibrun.Micro для Delphi, что звучит очень интересно.