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

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

Delphi идва с компоненти с методи, които правят това, което искам, например RichText Memo компонент ми позволява да работя с обогатен текст. Други компоненти, като решетката с низове на TMS, не само правят това, което искам, но и платих допълнително за функционалността. Тези характеристики поставят R в RAD.

Изглежда нелогично да пиша свои собствени класове, за да правя неща, които някой друг вече е направил за мен. Това е преоткриване на колелото [опитвали ли сте някога да работите директно с форматиран текст? :-) ] Но ако използвам функционалността, вградена в компоненти като тези, тогава ще се окажа с много смесени потребителски интерфейс и код на домейн - ще имам формуляр с повечето от моя код, вграден в неговите манипулатори на събития.

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


oop delphi separation-of-concerns
person Al C    schedule 20.04.2010    source източник
comment
Не се подлъгвайте, че визуалните аспекти формират R в RAD. Rapid идва от „минимално планиране в полза на бързо създаване на прототипи“ и се прилага за всички слоеве, дори за бързо създаване на прототипи на уеб услуги (които очевидно нямат UI).   -  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, за да съдържате вашата бизнес логика и обекти с данни. Можете дори да направите крачка напред и да отделите бизнес логиката от данните. Очевидно формулярът съдържа потребителския интерфейс. Почти всеки компонент, който използвате, може да бъде обвързан с данни, което улеснява свързването им с вашите clientDataSets.

Само не забравяйте, че Delphi има начин да прави неща, които не винаги отговарят на най-добрите практики, които Java или .Net имат. Вашата цел трябва да бъде да направите нещо, което се чувства правилно и работи за Delphi.

person Preston    schedule 20.04.2010