Използването на рамки, за да напише "правилното" заявление
Аз не знам за вас, но аз веднъж се срещна често със следната ситуация. В развитието на доста голям брой проекти формира с течение на времето да расте. И колкото по-далеч, по-лошо. Но дори и това не е голям проблем, докато аз се работи - все още може да бъде себе си самодисциплинирани - да се възползва Uniform наименуване форми, методи, променливи. Но след като започнах да работят в екип, проблемът се превърна в цял ръст - рефакториране стана често се свежда до "презаписване на всички", тъй като всеки програмист тяхното разбиране за "правилното изписване на кода" .След като се замисли малко, реших да се създаде един вид "двигател" което ще улесни писането доста големи проекти. В основата на този двигател, сложих на следните принципи:
1. Без изключение, всички обекти за работа с базата данни трябва да са в блокове данни, както и броя на обектите в базата данни не трябва да надвишава определена критична граница (за мен - до 50 обекти) - след това престава трудно да се движите;
2. Всички операции с данните от базата данни трябва да бъдат описани в модули с данни в съответните събития или ActionList;
3. Основната форма не трябва да съдържа код, който да работи с режимите, само в режим на разговор и призив резюмето на общи за всички методи, които имат преимущество във всеки съответен режим.
4. потребителски интерфейс на всички режими трябва да бъде напълно еднаквост.
5. Режимът трябва да има "право" да промени основния прозорец.
6. режим не трябва да знае за съществуването на други режими и други форми на общи, режимът трябва да бъде на разположение само на основната форма и модули за данни.
7. модули за данни не знаят за съществуването на режими.
8. профили трябва да се създават динамично, така че да не заемат твърде много памет.
Повечето подходящи рамки, за да изпълни задачата. Използването на рамки, успяхме да създадем единен интерфейс, тъй като имахме една основна форма, която просто се промени картини - "рамки". Въпреки това, първото изпълнение е бил неуспешен, защото да се работи с конкретни функции принудени да вършат всичките рамките на основната форма и да превключвате между тях с помощта на имота Видима.
Освен това, основната форма кодът е претоварен с функции, които определят кой режим в момента се зарежда, и поради това призовава режима на метод.
Затова беше решено да се премине от "тежката наследство" :) процедурно програмиране и използване на основните принципи на ООП.
Всъщност се оказа, че всички рамки е възможно (в действителност, трябва да) правят наследниците на основната рамка. Кодът е дадена по-долу основната рамка.
Както се вижда, много от функциите на основната рамка се връща TFunctionResult стойност тип. Тази структура е определен в UnitConstTypes_etc модул, в който за в бъдеще ще бъдат добавени към други видове константи. Функции върнат на работа знаме приключи успешно, и случай на грешка - съобщението за грешка.
Това, разбира се, на шаблона. В моите текущи приложения по-горе характеристики са повече от достатъчно. Все пак, ако имате нужда да добавите малко специфичен метод, в който ясно е никаква трудност.
Освен това, в рамките на процедура, наречена метод за износ мрежа В кадър данни SaveToHTML. Този метод е определен в MyDBGrid модул.
Ние се пристъпи към дисплея на рамки на основната форма на приложение.
Основната Формулярът за кандидатстване имам нещо като това: в лявата - меню дърво в долната част на приложението дневник, от върха - в лентата с инструменти, останалите пространство е празна, това отнема панел, на който са показани кадри.
На първо място, да създадете свой стил
Сега трябва да се създаде правилно работещ форма у дома. Използването на цели добавите UnitFrameBase модул, ще направи публично раздела на TFrameBase на обект клас мейнфрейм. Сега трябва да се напише функция, която ще покаже правилната рамка, когато отваряте желания режим.
Как да наричаме тази функция? Създаване на допълнително съобщение - покана за процедури за филтриране.
PARAM1 и PARAM2 използва за генериране на необходимите разследвания, в един и същи вид на кадъра. Сега трябва да се напиши манипулатор FILTER_EVENT мнения.
Ние се пристъпи към дисплея на рамката на менюто. Като XML файл източник, можете да използвате структурата на менюто съхранение дърво (това е полезно, ако заявлението не използва база данни), използваната таблица в базата данни за приложение или пази системата директно в заявлението (много удобно да го направя в dxTreeList от DevExpress, но тези компоненти са платени) , Тъй като всички бази данни, използвани моите приложения (Oracle или Firebird СУБД най-вече), аз избрах втория вариант. Създайте таблица на следната структура
В допълнение, за да се гарантира целостта на дървото, няколко спусъците и ограниченията, свързани с масата. Напълно структурата на таблицата и текстове ограничения можете да pomotret в базата данни източник.
От тази релационна таблица е доста лесно да се създаде едно дърво с помощта на рекурсивни процедура, текстът на който можете да видите базата данни на изходния код. Имайте предвид, че принципите на тази процедура са взети от книгата "Светът на InterBase".
Без да навлизаме в подробности за изграждането на дървото на сървъра Нека отбележим, че в приложението на клиента, може да се изгради едно дърво с едно минаване на масива от данни.
посочен по-долу процедура Tree картографиране. На първо място, ние определяме структурата на елементите от менюто
Естествено, структурата на елемента от менюто съвпада с тази на масата за база данни. Нека създадем следните функции от менюто
Процесор точка промяна в менюто ще изглежда по следния начин
По същия начин за другия. Освен това, основната форма трябва също така да се създадат общи елементи за филтриране. Това могат да бъдат елементи за филтриране по дата, по разплащателната сметка и т.н. Въпреки това, промените на процесора на тези елементи е необходимо да изпращат само CX_FILTER съобщение. Как да се обработи съобщението, получено, ще реши даден кадър.
Освен горепосочен, основната форма ще трябва да се регистрират всички видове рамки. Това се прави с функция RegisterClasses на раздел за инициализация.
Сега трябва да се създаде рамки. Рамката трябва да наследи от абстрактен създал над TFrameBase на рамката. След това, което трябва да замени желания режим.
В най-простия случай е необходимо да се замени конструктора конструкция на рамката, където описанието на замяна, причинявайки SetDesc набор от данни и определяне на текущия блок, задейства SetFrameCurrentDataSet. Ако рамката е с решетка, е необходимо да се предефинира функцията GetMainGrid да се върне в правилното.
По този начин, за да добавите нов режим в най-простия случай, трябва да се регистрирате само 9 реда код!
Въпреки това, неговата промяна (подобрение) на рамката абсолютно не води до каквото и Edit основната форма. характеристики на данни причиняват само съответната методи набор от данни. В манипулатор, който може да доведе до допълнително модална форма или диалогов прозорец.
Тест кода на приложението, demonstrirueschego описано работа с рамки nahodetsya тук.
Свързани статии