Кратко ръководство и полезни съвети за това как да разработим своя практически проект

Кратко ръководство и полезни съвети за това как да разработим своя практически проект

Общи съвети

БЕЗ ПАНИКА ! ! !

Проектите са малки по обем и с малка сложност. Тъй като на много от вас този проект ще бъде първият в програмисткия ви живот, ГОРЕЩО ви препоръчваме да го започнете максимално рано. Работата по проектите не е много, но все пак отнема време и е много неприятно да се окаже, че поради липса на опит, сте си отделили 2 дни преди предаването, а се нуждаете от поне 4. Започнете работата веднага – много по-лесно е да работите по 1-2 часа на ден, отколкото 2-3 нощи в края. Помислете и за това, че създаването на един проект е мисловен труд и изисква нужното адекватно състояние. Човек, който не е спал 1-2 нощи по някакви причини и е имал натоварен ден, не е в състояние да взема най-добрите решения и да решава възникналите проблеми с лекота.

Ако нямате нужните знания и опит се консултирайте с колеги и преподаватели.

Използвайте код конвенция. Това е множество от правила, които можете и сами да измислите. Те дефинират как да бъде писан кода ви. Дефинират именуването на таблици, класове, полета, свойства, методи, създаването на променливи и много други аспекти на вашия код. След като веднъж сте си дефинирали или избрали такава конвенция я спазвайте през целия проект. Ако една конвенция обхваща достатъчно голям аспект от дейностите ви по кода и я използвате НАВСЯКЪДЕ в своя код това значително улеснява четивността и улеснява не само вас, но и проверяващите да се ориентират в кода. НИКОГА не използвайте повече от една конвенция в един проект – иначе идеята си губи смисъла.

Четене на спецификацията

Прочетете спецификацията веднъж за да се запознаете с нея. След това втори път я четете задълбочено и на лист рисувайте компонентите и класовете на системата и връзките между тях. Препрочитайте местата, които ви трябват по няколко пъти за да имате ясна представа какво се иска от вас.

По време на четенето трябва да набележите основните обекти, с които ще работи системата. Това обикновено са най-често срещаните съществителни в документа. След това направете списък с операциите, които те имат и взаимовръзките между тях.

Правете визуални схеми и диаграми, които да ви улеснят.

След като сте набелязали основните обекти и действията с тях, вие имате цялостна представа за изискванията на системата. Това е моментът, в който трябва да направите план и график за изпълнението на отделните подзадачи. Разпределяйте времето си внимателно. Задължително си оставете няколко дни преди предаването на проекта свободни за да имате възможност да оправите възникнали в последния момент проблеми или закъснения. Никога не си мислете, че имате този резерв и тази мисъл да ви дава спокойствието да не работите или пък да изоставате от графика. По-добре да свършите проекта си и да почивате вместо да се изцедите от нерви и недоспиване в последните 2 дни.

Не тръгвайте да работите по спецификацията парче по парче без да сте я прочели внимателно цялата.

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

Архитектурен дизайн

В случая с практическия проект вие сте доста ограничени откъм решения свързани с архитектурата поради изискванията към проектите – MS SQL Server2000, .NET Framework, ADO.NET и Windows Forms.

Дизайн на базата данни

Направете таблица за всеки от основните обекти на системата. Ако е нужно раздробете един обект на няколко подобекта и за всеки от тях направете специална таблица.

Моделирайте връзките между обектите със средствата, който базата данни предлага. Така ще смъкнете от плещите си един доста голям товар – поддържането на базата данни в консистентно състояние.

Използвайте Identity полета за записите във всяка таблица. Така ще можете да идентифицирате всеки един ред от таблицата си. В някои случаи това поле е излишно, но тези случаи са малко и строго специфични. Ако все пак сложите такова поле не се притеснявайте – то няма да ви пречи. Задължително ползвате опциите за AutoIncrement на Identity полетата (първичните ключове). Не си мислете, че е лесна задача, вие на ръка да давате уникална стойност на това поле. Оставете максимално работа на самия SQL сървър.

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

"Разговорен" тип	SQL тип	.NET Framework тип
Текст, имена, ЕГН, тел. номера …	nvarchar	string
Цели числа	int, byte	int, byte
Дробни числа	float	double, float
Дата, дата с час	datetime	DateTime
ДА/НЕ (булеви)	bit	bool
Снимки	binary	Image, Bitmap

Когато преобразувате дробни числа или дати към текст и обратно, задавайте култура или форматиращ шаблон за да записвате и четете всички данни по един и същ начин. В противен случай рискувате при пренасяне на приложението на друг компютър да имате нежелани изключения породени от това, че конфигурацията на културата на компютъра е различна от вашата и поради това се използват различни разделите за десетична част или пък са разменени местата на месеца и деня при записването на дати.

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

Поставяйте задължително изискване за всяко поле в базата данни дали искате да разрешавате полето да остава празно т.е. да има стойност NULL. Така при всеки опит да добавите нов ред с празно поле, за което има изискване да не е празно ще получавате изключение и ще бъдете уведомени. Въпреки че става дума за изключение, това е препоръчителната практика. Когато добавяте нова колона в таблица, в която вече има записи, оставяйте полето незадължително (тоест да приема NULL), докато попълните данни в полетата на съществуващите записи. След това вече спокойно можете да включите това изискване, ако ви е нужно.

Бъдете сигурни, че базата и полетата в нея могат да работят коректно с кирилица.

Дизайн на класовете за работа

След като имате създадена база данни можете да пристъпите към дизайн на самите класове на вашето приложение. Класовете ви най-вероятно ще повтарят дизайна на базата данни. Тук няма да имате нужда от двойка Първичен/Външен ключ за да направите връзките между обектите. За връзка едно-към-едно използвайте инстанция, която е поле на класа, а за много-към-много – масив или колекция от инстанции.

За имена на класове, методи и т.н. използвайте винаги английски език и латински букви. Изписвайте граматически правилно думите, от които се състои името. Не се оправдавайте, че не знаете как се превежда някоя дума – за това си има речници. Избягвайте използването на съкращения.

Именувайте класовете си максимално точно и максимално описателно. Не се притеснявайте да използвате, когато е нужно дълги имена – това подобрява качеството на вашия код, а самото изписване става лесно като използвате IntelliSense функционалността на Visual Studio. ( Разбира се ако всички имена в кода ви са по дълги от 100 символа няма да е много удобно )

Ако имате повтаряща се функционалност я изнасяйте максимално много в базови класове или класове-помощници (Helper или Utility класове). Така ще имате по-лесно четим код. Евентуалните проблеми ще са само на едно място и промените по логиката ще засягат само малка част от кода ви.

Направете си клас, който има задача да конвертира данни от текст към съответния тип и обратно. Това е така наречения Parser клас. В него създайте статични методи за всеки тип, който ви се налага да конвертирате. Примерни методи са:

public static DateTime ReadDate(string date) – чете дата от string

public static string DateToString(DateTime date) – връща дата в текстов вид

По аналогичен начин направете методи за останалите типове, които използвате. Когато използвате стойностни типове, възниква въпросът какво да правите, когато срещнете празна (NULL¹) стойност. Връщайте някаква невалидна стойност – например най-малката възможна дата (дефинирана е с константа в типа DateTime, както и във всички останали примитивни типове) или нещо, което смятате, че е подходящо за случая. Старайте се да използвате една и съща стойност винаги. Избягвайте хвърлянето на изключение тъй като операциите по конвертиране на текст в тип и обратно са често извиквани и ако се бавят заради изключения това се отразява сериозно върху производителността. В случаите, когато функциите ви обработват референтен тип подавайте null, ако не сте успели да го обработите коректно.

Изключения

Когато във вашите класове срещнете място, на което ще трябва за използвате обработка на изключение или да хвърлите изключение, е препоръчително да използвате свои собствени изключения, а не дефинираните в .NET Framework системни такива. Това повишава нивото на абстракция и подобрява архитектурата. За да създадете свои типове за изключение използвайте като базов типа ApplicationException, а не Exception за да отделите логически своите изключение от тези на системата. При хвърляне на дефинирано от вас изключение, което е предизвикано от друго системно такова, задължително добавяйте системното в полето InnerException на новото за да можете по-лесно да проследите грешката при дебъгване.

Създаване на слоевете на приложението

Едно добре структурирано приложение трябва да бъде разделено на слоеве. Всеки от тези слоеве трябва да има свое конкретно предназначение. Всеки слой може да комуникира единствено със своите съседни. Един слой обединява класове с логически свързана и подобна функционалност. Класическата архитектура на неголеми приложения е трислойната. В нея са разделени следните три слоя - Database Layer, Business Layer, Presentation Layer. Ако трябва да ги разпределим вертикално, то най-долният слой е Database Layer – достъпът до базата данни. След него е Business Layer – в него данните се обработват по специфичния за приложението начин и със бизнес правилата, които то дефинира. Най-отгоре стои Presentation Layer – визуалното представяне на данните и възможността потребителят да може да оперира с тях по максимално удобен и лесен начин.

Всеки то тези слоеве си има особености затова ще ги разгледаме един по един.

Препоръчителната практика е те да се отделят в отделни проекти в рамките на един solution.

Database Layer

Капсулира достъпа до базата данни. От тук трябва да се изпълняват всички заявки към сървъра на базата. Като входяща информация този слой получава сурови данни във вид на таблици или резултати от заявки, а като изход предоставя за работа на следващото ниво обекти от по-високо ниво на абстракция – дефинирани от потребителя обекти, колекции и др.

Тъй като в този слой най-вероятно вие за пръв път ще използвате своите класове за основните обекти, то те трябва да се намират или в същия проект както Database Layer-а или в отделен предназначен само за тях проект, към който Database Layer-а има референция.

Тук ще е единственото място, от което трябва да отваряте и затваряте връзките си към базата. Както знаете за да отворите връзка ви трябва ConnectiongString, който описва името на сървъра, базата която ни интересува и така нататък. За да съхраните тази настройка използвайте конфигурационен файл, дори и той да е plain text format. Никога не забивайте в кода си този ConnectiongString. Това е груба грешка.

Винаги затваряйте връзката си към базата, когато сте приключили работата си с нея. За да сте сигурни, че при възникване на изключение връзката ще бъде затворена, използвайте try, catch, finally.

Препоръчително е използването на константи за имената на таблици и колони от базата данни. Въобще всяка стойност, която има някакъв определен смисъл е добре да бъде изнесена на константа с подходящо име. Така промените по кода се правят по-лесно и навсякъде се използват едни и същи стойности. Използването на константи за string-гове ви улеснява и при самото изписване на кода – можете да се възползвате от IntelliSense-а на Visual Studio.

Business Layer

В този слой на приложението е съсредоточена неговата програмна логика за решаване на специфичния поставен проблем. Тук се работи основно с дефинираните по рано типове и техните операции. Входните данни са инстанции на тези типове или колекции. Изходните данни са пак такива.

В този слой не трябва да има код, който работи със самия SQL Server.

Добра практика е при нужда да се разделя на модули според предназначението на класовете вътре и тяхната функционалност.

Тук е мястото, където трябва да се прави валидация на данните – т.е. дали те са това, което ние очакваме и дали са в нужния формат и т.н.

Presentation Layer

В този слой трябва да оставите единствено класовете и функционалността, която се грижи данните да се показват коректно на потребителя и той да има възможност да оперира с тях. Работи се с данни от бизнес нивото.

Постарайте се да организирате потребителския интерфейс в логически свързани групи и да го направите максимално опростен.

Давайте добри имена на всеки контрол във вашия интерфейс. Препоръчително е да имате конвенция поне за именуването на различните типове контроли. Примерна конвенция е даден в края на това ръководство.

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

Писане на код

Писането на код е най-времеотнемащата част от разработването на проекта. Кодът се пише, дебъгва, пренаписва, тества, пренаписва и така, докато не си свършите работата. Точно затова е важно да пишете качествен код.

За целта на тези проекти ще можем да конструираме качествен код ако:

• 
  даваме описателни имена
  
• 
  всеки от класовете и методите ни имат една специфична задача, която да изпълняват
  
• 
  класовете ни да са максимално логически и функционално отделени един от друг
  
• 
  да нямаме дублиране на код
  
• 
  да слагаме коментари на местата с по-особен код
  

Когато работи с обекти, които изискват специално отношение при приключване на работа с тях, внимавайте да ги затворите и унищожите правилно. Най-често програмистите забравят да затворят потоци и връзки към базата данни.

Правете проверки дали операциите са се изпълнили коректно – става дума за резултат от методи, които връщат null при някакъв проблем, обезопасено преобразуване на типове (чрез ключовата дума as).

Проверявайте дали в масива, от които искате да вземете обект по индекс има достатъчно елементи, така че индексът, който подаваме, да е валиден.

Използвайте правилно try, catch, finally, там където е нужно. В случаите, когато се налага, създавайте ново изключение в catch блока и го хвърляйте за обработка по-нагоре с throw.

Тестване и подобряване на качеството на кода

Тестване

Проверявайте методите си с максимално широк диапазон от входни стойности – както с валидни така и с невалидни. Второто е по-важната част, тъй като повечето проблеми идват точно от начина, по който се справяте с невалидните данни. Това обаче не значи, че не трябва да тествате и със съвсем нормални валидни данни.

Тествайте различни последователности при извикването на определени операции.

За финално тестване е добре да използвате друг компютър за да сте сигурни, че приложението ви ще работи коректно навсякъде. Въпреки, че тестването на друг компютър не ви дава 100% сигурност, че всичко работи добре, все пак е задължително да го направите преди да представите проекта си за оценяване. Проекти, които не са тествани на друга машина ще бъдат санкционирани!

Дебъгване

След като откриете грешка в кода си, много рядко знаете точно какво я е предизвикало. Затова започвате да изпълнявате кода си стъпка по стъпка и да преглеждате програмната си логика ред по ред.

Този процес изисква много внимание, енергия и упоритост. Не го правете късно вечер или след много натоварен ден.

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

Ако зациклите на едно място повече от 30 минути (времето може да варира според това колко бързо се справяте с проблемите), спрете и го оставете за няколко часа или дори за следващия ден. Точно затова горещо ви препоръчваме да не пишете проекта си последните 2-3 нощи преди крайния срок. След тази почивка най-вероятно ще решите проблема си след 5 минути  (това правило е доказано многократно в практиката – ако не вярвате попитайте по-опитни колеги!)

Когато избирате от къде да започнете дебъгване, първо изберете място, което е максимално близко до възникването на вашия проблем – използвайте свойството StackTrace на изключенията, ако са възникнали такива. Никога не започвайте да дебъгвате приложението си от неговата входна точка, освен ако проблемът не е там.

Когато намерите грешката, не бързайте да я оправите с кръпка. Под кръпка се разбира код, който решава проблема само временно. Пример е следният случай: имате метод, която изчислява някаква функция. Дефиниционното множество на функцията е обхваща всички възможни стойности. За съжаление методът ви гърми, когато стойността на дадена променлива стане 5. Кръпка е решение от вида: ако променливата е равна на 5 то резултатът е 45. Не го правете! Така не решавате нищо! Обмислете как да поправите функцията си, така че да работи коректно с всички възможни валидни стойности.

Използвайте възможностите за наблюдение на променливи на Visual Studio 2003 – Watch, Quick Watch, Locals, Autos и CallStack, за да имате представа какво се случва във вашето приложение.

Refactoring

След като сте намерили код, който не ви харесва, трябва да го пренапишете. Този процес се нарича Refactoring. Основната му цел да получите качествен работещ код. Основните действия които включва са:

• 
  Преименуване на променлива, клас, метод и т.н.
  
• 
  Извличане на метод от кода на друг метод – ако имате дълъг метод който извършва различни операции от ниско ниво в сравнение с предназначението си, трябва да го разделите на по-малки под-методи, които заедно да извършват цялата работа на големия. Големият метод се запазва, но кодът му се променя, така че да извиква под-методите.
  
• 
  Извличане на клас от друг клас – аналогично на извличането на метод, но като резултат получаваме нов клас.
  
• 
  Извличане на базов клас, интерфейс
  
• 
  Преобразуване на локална променлива във входен параметър
  
• 
  Смяна на реда на параметрите на метод
  
• 
  Скъсяване на разстоянието между декларирането и използването на променливи
  

Кога и дали да прилагате тези методи зависи изцяло от вас. Препоръчваме ги, защото са изпитани и утвърдени от практиката и наистина дават добър резултат, когато се прилагат правилно. За да ви улесним ви предлагаме следните сигнали за код, който има нужда от Refactoring:

Сигнали за лош код

• 
  Кодът се чете трудно
  
• 
  Не се разбира какво е основното му предназначение
  
• 
  Има множество вложени цикли или условни оператори
  
• 
  Има неизползвани променливи
  
• 
  Променливите имат лоши имена
  

Сигнали за недобър клас

• 
  Има лошо име
  
• 
  Има повече от една задача, които изпълнява (изключваме Helper и Utility класовете)
  
• 
  Зависи много от друг клас
  
• 
  Полетата му са достъпни отвън и нямат обвиващи ги свойства
  
• 
  Има неизползвани или неинициализирани полета, неизползвани свойства или методи
  
• 
  Наследява даден клас, но логически не трябва да бъде наследник
  

Сигнали за недобър метод

• 
  Има лошо име
  
• 
  Изпълнява повече от една основна задача
  
• 
  Коректното му изпълнение зависи от това дали друг метод се е изпълнил преди това (не винаги е лошо – много зависи от случая!)
  
• 
  Има неизползвани параметри или променливи
  
• 
  Не върши това, за което е предвиден
  
• 
  Предефинира базов метод и променя логиката му в разрез с идеята на базовия
  

Разпространяване на приложението

След като вече имате готово приложение, идва ред на пренасянето на приложението от машината, на която е било написано до мястото, където ще се използва. Приложенията написани на .NET могат да се пренасят чрез просто копиране в повечето случаи. Това страхотно ви улеснява, тъй като единственото, което ще трябва да направите, е да архивирате и/или копирате папката на своя проект заедно с изпълнимите файлове и да ги поставите на диска на новата машина. Освен кода и изпълнимите файлове ще ви се наложи да пренесете и базата данни, с която приложението работи.

Разпространяване на базата данни

За да пренесете базата данни за приложението си можете да използвате няколко различни подхода:

• 
  Откачане, Copy, Paste и закачане на базата данни
  
• 
  Възстановяване от backup
  
• 
  Създаване и пълнене на базата чрез SQL скриптове
  

Първите два начина са почти еднакви. По-добрата практика е възстановяването от backup, тъй като има по-голямо практическо приложение. Третият начин е най-професионалният, но и изискващ най-много внимание и работа. За най-лесно и безпроблемно решаване на проблема ползвайте възстановяване от backup.

Преди да тръгнете да разпространявате базата си, бъдете сигурни че тя е консистентна и данните в нея няма да ви направят лош номер при демонстрирането на приложението ви. Махнете всички записи,които сте направили по време на тестове пълни с глупости от рода: "асдаскйлас", "na baba adresa", "ne6to drugo", "test 5" и подобни.

Бъдете сигурни, че сте копирали както .mdf файла на базата, така и .ldf файла на лога, ако разпространявате базата си чрез откачане/закачане.

Разпространяване на самото приложение

След като вече сте подготвили базата си за разпространение, трябва да обърнете малко внимание и на своето приложение. Както казахме вече, ще го разпространявате (в почти всички случаи) чрез Copy/Paste. Затова внимавайте да включите всички нужни файлове в архива на приложението. Това включва и всички конфигурационни файлове и външни библиотеки.

Направете в конфигурационен файл тези настройки на приложението си, които трябва да могат да се променят лесно. Едно от полетата, които трябва да присъстват в него, е ConnectionString-а за връзване към базата данни. Ако се нуждаете от допълнителни конфигурационни настройки – извадете ги в конфигурационен файл и не ги „забивайте” в кода!

Код-конвенции

За да пишете добър и лесно четим код ви е нужна код-конвенция, която дефинира правила за извършване на определени действия над вашия код. Една конвенция обхваща:

• 
  Именуването на класове, методи, свойства, полета, променливи
  
• 
  Структурирането на кода в класовете и методите
  
• 
  Изписването на самия код и неговите конструкции
  
• 
  Документирането на кода
  

На този адрес можете да намерите препоръчителната код-конвенция създадена от Microsoft :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp

1 Правете разлика между null в .NET Framework и NULL в MS SQL Server 2000. Тези две стойности имат един и същ смисъл, но ако през вашия код проверите дали едно поле от таблица в базата е равно на null, ще имате проблеми. За да разберете дали то е празно (NULL в SQL-а) използвайте метода IsDbNull() и съответния клас DbNull.

Каталог: dotnetcourse -> Projects
Projects -> За управление на малък магазин за хранителни стоки. Системата трябва да поддържа продукти, разделени по категории и да следи наличностите и продажбите
dotnetcourse -> Асемблита и разпространение
dotnetcourse -> Управление на паметта и ресурсите
dotnetcourse -> Уеб услуги с asp. Net
Projects -> Въпрос: Кога е нужно да слагам в класовете си свойства, и кога мога да слагам публични полета? Не е ли вторият вариант по-удобен, особено когато едно поле не се валидира по никакъв начин? Отговор
dotnetcourse -> Отдалечени извиквания с. Net remoting
dotnetcourse -> Сериализация на данни

Изтегляне 154.05 Kb.

Сподели с приятели: