Как отделить логику приложения от пользовательского интерфейса, если компоненты пользовательского интерфейса имеют встроенную функциональность?

Я знаю, что важно отделять код пользовательского интерфейса от кода предметной области — приложение легче понять, поддерживать, изменять и (иногда) изолировать ошибки. Но вот мой ментальный блок...

Delphi поставляется с компонентами с методами, которые делают то, что я хочу, например, компонент RichText Memo позволяет мне работать с форматированным текстом. Другие компоненты, такие как сетка строк TMS, не только делают то, что я хочу, но я доплачиваю за функциональность. Эти функции помещают R в RAD.

Кажется нелогичным писать свои собственные классы, чтобы делать то, что кто-то уже сделал за меня. Это заново изобретать колесо [когда-нибудь пробовали работать напрямую с форматированным текстом? :-) ] Но если я буду использовать функциональность, встроенную в подобные компоненты, то в конечном итоге я получу много перемешанного пользовательского интерфейса и доменного кода — у меня будет форма, большая часть кода которой встроена в обработчики событий.

Как вы решаете эту проблему? ... Или, если я хочу продолжать использовать код, который другие уже написали для меня, как бы вы предложили мне решить эту проблему?


oop delphi separation-of-concerns
person Al C    schedule 20.04.2010    source источник
comment
Не обманывайтесь тем, что визуальные аспекты образуют букву R в RAD. Rapid происходит от «минимального планирования в пользу быстрого прототипирования» и применяется ко всем уровням, даже для быстрого прототипирования веб-сервисов (у которых явно нет пользовательского интерфейса).   -  person Jeroen Wiert Pluimers    schedule 21.04.2010
comment
@Jeroen: конечно, но я думаю, что он спрашивает, /как/не быть заманенным в это, или как кодировать, используя среду RAD, но не попасть в эту ловушку.   -  person David    schedule 21.04.2010
comment
@David: Спасибо за эту точку зрения. Я не думал об этом. Но это действительно интересная перспектива.   -  person Jeroen Wiert Pluimers    schedule 23.04.2010

Ответы (2)


arrow_upward
6
arrow_downward

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

Логика предметной области Delphi и элементы управления Delphi UI взаимодействуют друг с другом в основном через обработчики событий. Но это не означает, что вам нужно поместить свою доменную логику в сами обработчики событий. Вместо этого попробуйте написать модули, содержащие код для конкретных задач, которые вам нужно выполнить, и пусть обработчики событий вызывают эти модули.

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

person Mason Wheeler    schedule 20.04.2010

arrow_upward
1
arrow_downward

Вы можете создать довольно четкое разделение, используя модули данных с clientDataSets, чтобы содержать вашу бизнес-логику и объекты данных. Вы даже можете пойти дальше и отделить бизнес-логику от данных. Очевидно, что форма содержит пользовательский интерфейс. Почти каждый используемый вами компонент может быть привязан к данным, что упрощает их привязку к вашим clientDataSet.

Просто помните, что в Delphi есть способ делать вещи, которые не всегда соответствуют лучшим практикам Java или .Net. Ваша цель должна состоять в том, чтобы сделать что-то, что кажется правильным и работает для Delphi.

person Preston    schedule 20.04.2010