Как Вы разделяете прикладную логику от UI, когда компоненты UI имеют встроенную функциональность?
Я знаю, что важно сохранить код пользовательского интерфейса разделенным от доменного кода - приложение легче понять, поддержать, изменить, и (иногда) изолировать ошибки. Но вот мой провал в памяти...
Delphi идет с компонентами с методами, которые делают то, что я хочу, например, компонент Заметки RichText позволяет мне работать с обогащенным текстом. Другие компоненты, как строковая сетка TMS не только делают то, что я хочу, но и я заплатил дополнительный за функциональность. Эти функции помещают R в RAD.
Это кажется нелогичным для записи моих собственных классов, чтобы сделать вещи, которые кто-то еще уже сделал для меня. Это изобретает велосипед [когда-нибудь пытался работать непосредственно с обогащенным текстом? :-)], Но если я использую функциональность, встроенную в компоненты как они, затем я закончу с большим количеством смешиваемого UI и доменного кода - у меня будет форма с большей частью моего кода встроенной в его обработчики событий.
Как Вы занимаетесь этой проблемой?... Или, если бы я хочу продолжить использовать других кода, уже записали для меня, как Вы предложили бы, чтобы я занимался проблемой?
2 ответа
Прежде всего, помните, что «работа с форматированным текстом» - это не то, что должно делать ваше приложение. Предполагается, что ваше приложение позволяет пользователю выполнять определенную задачу, а код для решения этой задачи - это логика вашего домена. Если часть задачи, которую должна выполнить ваша программа, включает работу с форматированным текстом, вы можете делегировать эту часть компоненту форматированного текста. Сложность возникает, как вы упомянули, на стыке между этими библиотеками и логикой предметной области.
Логика домена Delphi и элементы управления пользовательского интерфейса Delphi взаимодействуют друг с другом в основном через обработчики событий. Но это не значит, что вам нужно поместить логику домена в сами обработчики событий. Вместо этого попробуйте написать модули, содержащие код для задач, зависящих от предметной области, которые вам нужно выполнить, и пусть обработчики событий вызывают эти модули.
Другими словами, не пишите классы, чтобы изобретать велосипед и делать то, что другие уже сделали для вас. Вы правы, это было бы нелогично. Но напишите специфические для приложения части, которые элементы управления и библиотеки, которые вы используете , не предоставили , как их собственные отдельные классы в их собственных отдельных модулях, и соедините их с помощью обработчиков событий и общедоступных методов или свойств в ваших формах, и вы получите достойное разделение проблем.
Вы можете создать довольно четкое разделение, используя модули данных с clientDataSets для хранения вашей бизнес-логики и объектов данных. Вы даже можете пойти дальше и отделить бизнес-логику от данных. Очевидно, что форма содержит пользовательский интерфейс. Почти каждый используемый вами компонент может быть привязан к данным, что упрощает привязку их к вашим clientDataSets.
Просто помните, что у Delphi есть способ делать вещи, которые не всегда соответствуют лучшим практикам Java или .Net. Ваша цель должна заключаться в том, чтобы сделать что-то, что кажется правильным и работает для Delphi.