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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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