Delphi: хорошая модель / стратегия для представления <-> синхронизация модели

Я перешел на C # и модель MVVM (WPF).

Помимо шуток, начните с просмотра форума Объектно-ориентированный дизайн на Embarcadero.

Вы можете взглянуть на tiOpf , поскольку я вижу, что у них есть некоторые компоненты для создания графического интерфейса . Существует также InstantObjects , но я не знаю, разрабатывается ли он до сих пор.

Основная проблема с компонентами VCL заключается в том, что он не поддерживает привязку к объектам / спискам. Таким образом, решение состоит в использовании виртуального набора данных, такого как EzSepcials , и компонентов, поддерживающих данные, или в использовании компонентов, не поддерживающих данные, и посредников записи для отдельных компонентов. Я должен упомянуть Virtual TreeView .

Я думаю, что типичный MVC не подходит для приложений delphi. Я видел реализации, которые добавляли столько шаблонного кода, что это было страшно. У них было больше работы над собой, чем с проблемой, которую они пытались решить.

Я написал фреймворк MVC для delphi, но пока я использую его только в своих собственных проектах. Я пока не нахожу его материала для изготовления. Он основан на модели и средстве просмотра, контроллер является лишь связующим звеном между ними.

Модель содержит или обрабатывает бизнес-логику, а средство просмотра предназначено строго для просмотра (GUI). Таким образом, последовательность действий выглядит так:

1. В окне просмотра что-то происходит (нажата кнопка).
2. Представление отправляет команду со связанными данными в модель
3. Модель вносит изменения в бизнес-данные и подготавливает новые данные для представления.
4. Представление обновляется новыми данными (только определенный раздел представления)

Я автоматизировал это так, что когда команда вызывается из представления, автоматически вызывается соответствующий метод обработчика команд в модели. Когда модель завершает изменения, вид обновляется. Если существует метод, соответствующий имени команды в представлении, этот метод вызывается, в противном случае вызывается общий метод «UpdateView». Передаются только те данные, которые были изменены, и обновляются только соответствующие части представления. Если для модели существует несколько видов, обновляются все. Средой для передачи данных туда и обратно на данный момент является XML, потому что он гибкий, поэтому нет проблем с передачей любых данных. Да, в крайних случаях производительность может пострадать, но в целом подход работает. Мне просто нужно очистить его, чтобы было как можно меньше шаблонов и накладных расходов.

Может быть, если есть интерес, я могу написать о решении в блоге и очистить его для качества продукции.

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

Я не эксперт, но в прошлом меня обжигали эти немногие вещи:

1. Попытка поставить все явные ссылки на доступ к БД и компоненты доступа к БД внутри модуля данных. Не имеет большого значения, если вы ошибетесь на стороне слишком большого количества модулей данных, но будьте осторожны, чтобы не помещать слишком много не связанных элементов доступа к БД в один и тот же модуль данных (объединение кода намного проще, чем разделение кода).

2. Хотя очень удобно подключить все компоненты вашей БД к основному соединению / компонент сеанса во время разработки (и это одна из сильных сторон Delphi), также очень полезно иметь возможность явно устанавливать connectionString, или сеанс, или ссылку на соединение динамически во время выполнения, особенно когда кто-то хочет использовать модуль данных в другом проекте, без необходимости добавлять в исходный проект модуль подключения к БД, если он существует.

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

Пункт (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 действительно впечатляет. Любая часть модели, представления или контроллера, зависящей от реализации, может быть заменена другой системой без (значительного) влияния на две другие. Несомненно, в других фреймворках есть аналогичные подходы, но я не могу их комментировать.

Я просто проведу рефакторинг позже; конечно, вы знаете, что это ложь, потому что позже никогда не приходит .

Пункт (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 действительно впечатляет. Любая часть модели, представления или контроллера, зависящей от реализации, может быть заменена другой системой без (значительного) влияния на две другие. Несомненно, в других фреймворках есть аналогичные подходы, но я не могу их комментировать.

Я просто проведу рефакторинг позже; конечно, вы знаете, что это ложь, потому что позже никогда не приходит .

Пункт (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 действительно впечатляет. Любая часть модели, представления или контроллера, зависящей от реализации, может быть заменена другой системой без (значительного) влияния на две другие. Несомненно, в других фреймворках есть аналогичные подходы, но я не могу их комментировать.

Существует огромная разница в ясности и удобстве обслуживания между следующими двумя фрагментами, хотя это может быть неочевидно, если рассматривать их изолированно, как здесь:

// "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 действительно впечатляет. Любая часть модели, представления или контроллера, зависящей от реализации, может быть заменена другой системой без (значительного) влияния на две другие. Несомненно, в других фреймворках есть аналогичные подходы, но я не могу их комментировать.

Существует огромная разница в ясности и удобстве обслуживания между следующими двумя фрагментами, хотя это может быть неочевидно, если рассматривать их изолированно, как здесь:

// "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 действительно впечатляет. Любая часть модели, представления или контроллера, зависящей от реализации, может быть заменена другой системой без (значительного) влияния на две другие. Несомненно, в других фреймворках есть аналогичные подходы, но я не могу их комментировать.

view или controller могут быть заменены другой системой без (значительного) влияния на два других. Несомненно, в других фреймворках есть аналогичные подходы, но я не могу их комментировать.

view или controller могут быть заменены другой системой без (значительного) влияния на два других. Несомненно, в других фреймворках есть аналогичные подходы, но я не могу их комментировать.

ИМХО, часть контроллера в шаблоне модель-представление-контроллер часто является своего рода накладными расходами для приложений Delphi из-за того, что такие приложения основаны на событиях. Разделение модели и представления работает так же, как и в любом другом языке программирования.