Внедряване на логиката на дизайна

Философии на подхода за внедряване

водопад подход

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

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

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

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

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

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

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

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

Основният недостатък на водопадния подход е, че в среда, където всичко е организирано по много формален начин, гъвкавостта за реагиране на промените намалява. Дори придвижването трябва да бъде организирано. Много малко компании изглежда правят това ефективно, което често води до значително увеличение на режийните разходи. За да управляват разходите по даден проект, някои компании дори забавят всички промени в изискванията до първоначалното доставяне на приложението, като ефективно доставят приложение, което не отговаря на нуждите на крайния потребител.

гъвкаво развитие

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

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

Основното предимство на гъвкавото разработване на софтуер е гъвкавостта при справяне с промените, като винаги се стремим да доставяме според нуждите на бизнеса. Недостатъкът, разбира се, е увеличаването на сложността на управлението на обхвата, планирането и бюджетирането. Друг често срещан риск е ограниченото внимание към (техническата) документация.

Постепенно развитие

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

Предимството е, че формалностите остават в сила, но управлението на промените става по-лесно. Разходите за тестване и внедряване на приложение многократно ще бъдат по-големи, отколкото да го направите само веднъж.

Контрол на потока на програмата

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

Код на организатора

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

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

Създаване на проекта

слоеве

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

слоеве срещу слоеве

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

Фигура 8-1: Основна тристепенна организация

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

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

Физически слоеве

В корпоративно приложение бихте очаквали да имате множество клиенти за една и съща логика. Всъщност това, което прави едно приложение корпоративно приложение е, че то ще бъде разгърнато на три слоя: клиент, сървър на приложения и сървър на база данни. Приложението Microsoft Office Access, създадено от търговския отдел на вашата компания, макар и много важно за търговския отдел, не е корпоративно приложение.

Имайте предвид, че логиката на приложението и слоевете за достъп до данни често се разполагат заедно на сървъра на приложения. Част от проектирането на проекта е изборът дали да получите достъп до сървъра на приложения чрез отдалечени .NET или уеб услуги. Който и да изберете, ще добавите някакъв код за лесен достъп до отдалечени услуги в презентационния слой. Ако използвате уеб услуги за достъп до услугите на вашия сървър на приложения, Visual Studio .NET ще свърши работата вместо вас и ще генерира прокси кода, автоматично предоставяйки имплементация на шаблона за отдалечен прокси.

Добавяне на модели към слоеве

Трите основни слоя осигуряват общ преглед на високо ниво. Нека добавим някои структурни модели, за да създадем стабилна корпоративна архитектура. Резултатът е показан на фигура 8-2.

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

поток от решения

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

Има два подхода за организиране на вашите услуги:

• ориентирани към действие
• управлявани от държавата

Подход, ориентиран към действие

Като организирате услуги въз основа на действията на потребителите, вие внедрявате логиката на приложението, като предлагате услуги, всяка от които обработва конкретна заявка от презентационния слой. Това също е известно като модел на транзакционен скрипт. Този подход е популярен, защото е прост и изглежда много естествено. Примери за методи, които следват този подход, са BookStoreService.AddNewOrder(Order order) и BookStoreService.CancelOrder(int orderId).

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

Държавен подход

Също така е възможно да се приложи потокът на решения на приложението по много по-ориентиран към състоянието начин. Услугите, предлагани от сървъра на приложения, са по-генерични по природа, например BookStoreService.SaveOrder(Поръчка за поръчка). Този метод ще провери състоянието на поръчката и ще реши дали да добави нова поръчка или да отмени съществуваща поръчка.

Проекти за структура на данни

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

• Услугите предлагат данни; данните са отражение на релационната база данни.
• Данните трябва да бъдат съпоставени с обекти и услугите осигуряват достъп до обекти.
• Данните, предлагани от услугите, трябва да са базирани на схема.

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

Избор на машина за съхранение на данни

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

• Записвайте
• app.config файл
• xml файлове
• обикновени текстови файлове
• База данни
• опашка за съобщения

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

Проектиране на потока от данни

Поток от данни с помощта на ADO.NET

Като внедрите услуги, ориентирани към данни, в логическия слой на приложението, вие ще проектирате своя поток от данни с помощта на ADO.NET. Библиотеката с класове на .NET Framework предоставя обширен интерфейс за програмиране на приложения (API) за манипулиране на данни в управляван код. Наричан като ADO.NET, API може да бъде намерен в пространството на имената System.Data. Пълното разделяне на носители на данни и хранилища на данни е важна конструктивна характеристика на ADO.NET. Класове като DataSet, DataTable и DataRow са предназначени да съхраняват данни, но не запазват информация откъде идват данните. Те се считат за агностик на източника на данни. Отделен набор от класове, като SqlConnection, SqlDataAdapter и SqlCommand, се грижи за свързването към източник на данни, извличането на данни и попълването на DataSet, DataTable и DataRow. Тези класове се намират в подпространства от имена като System.Data.Sql, System.Data.OleDB, System.Data.Oracle и т.н. В зависимост от източника на данни, към който искате да се свържете, можете да използвате класове в правилното пространство от имена и в зависимост от обхвата на продукта, който използвате, ще откриете, че тези класове предлагат повече или по-малко функционалност.

Тъй като DataSet не е свързан с източника на данни, той може да се използва доста успешно за управление на потока от данни в приложение. Фигура 8-5 показва потока от данни, когато правите това.

Нека да разгледаме този проект и да си представим, че някой е влязъл във вашата книжарница и е поръчал три книги. Презентационният слой управлява състоянието на пазарската количка. Клиентът е готов да направи поръчката и е предоставил всички необходими данни. Той избира да изпрати поръчка. Уеб страницата трансформира всички данни в набор от данни, съдържащ две таблици с данни, една за поръчка и една за поръчка; вмъква DataRow за поръчката; и вмъква три DataRows за редовете за поръчка. След това уеб страницата отново показва тези данни обратно на потребителя, като обвързва контролите на данните с DataSet и пита Сигурни ли сте? Потребителят потвърждава заявката и тя се изпраща на логическия слой на приложението. Логическият слой на приложението проверява DataSet, за да види дали всички задължителни полета имат стойност и извършва проверка, за да види дали потребителят има повече от 1000 US$. 00 за неплатени сметки. Ако всичко върви добре, DataSet се предава на слоя за достъп до данни, който се свързва с базата данни и генерира изрази за вмъкване от информацията за DataSet.

Използването на DataSet по този начин е бърз и ефективен начин за изграждане на приложение и използване на силата на Framework Class Library и способността на ASP.NET да обвързва данни с различни контроли, като GridView срещу DataSet. Вместо да използвате прости обекти DataSet, можете да използвате Typed DataSet обекти и да подобрите изживяването при кодиране чрез внедряване на код в презентационния слой, както и в слоя на логиката на приложението. Предимството на този подход е и недостатъкът на подхода. Малките промени в модела на данни не водят непременно до много методи, които трябва да променят своите подписи. Така че по отношение на поддръжката, това работи наистина добре. Ако си спомняте, че презентационният слой не е непременно потребителски интерфейс, той може да бъде и уеб услуга. И ако промените дефиницията на DataSet, може би защото преименувате поле в базата данни, тогава вие променяте договора, за който се абонира уеб услугата. Както можете да си представите, това може да доведе до някои значителни проблеми. Този сценарий работи добре, ако презентационният слой е само потребителски интерфейс, но за интерфейси към външни системи или компоненти ще искате да скриете вътрешната работа на вашето приложение и да трансформирате данните в нещо различно от директен клонинг на вашия модел на данни и ще искате да създадете обекти за прехвърляне на данни (DTO).

Поток от данни с помощта на обектно релационно картографиране

Dataflow с помощта на ADO.NET е много ориентиран към данните подход за управление на потока от данни. Данните и логиката са дискретни. Другият край на спектъра възприема по-обектно-ориентиран подход. Тук се създават класове за групиране на данни и поведение. Целта е да се дефинират класове, които имитират данните и поведението, намерени в бизнес домейна, за който е създадено приложението. Резултатът често се нарича бизнес обект. Колекцията от бизнес обекти, които съставляват приложението, се нарича домейн модел. Някои разработчици твърдят, че богатият модел на домейн е по-добър за проектиране на по-сложна логика. Трудно е да се докаже или отхвърли подобно твърдение. Просто знайте, че имате избор и от вас зависи да го направите.

Фигура 8-6 показва поток от данни, подобен на Фигура 8-5, с изключение на това, че сега сте добавили слоя за релационно картографиране на обекти и сте заменили обектите DataSet с различни носители на данни.

Сега направете същото стъпка по стъпка както преди; представете си, че някой се е свързал с вашата книжарница и е поръчал три книги. Презентационният слой управлява състоянието на пазарската количка. Клиентът е готов да направи поръчката и е предоставил всички необходими данни. Той избира да изпрати поръчка. Уеб страницата превръща всички данни в DTO, съхранявайки данни за една поръчка и с три реда за поръчки, създавайки обектите според нуждите. Уеб страницата показва тези данни обратно на потребителя още веднъж, обвързването на данни контролира DTO с помощта на ObjectDataSource в ASP.NET 2.0 и пита Сигурни ли сте? Потребителят потвърждава избора и DTO се изпраща на логическия слой на приложението. Приложният логически слой трансформира DTO в бизнес обект от тип Order със свойството да съдържа три обекта OrderLine. Методът на поръчката. Validate() се извиква, за да потвърди поръчката и да провери дали всички задължителни полета имат стойност и се прави проверка, за да се установи дали потребителят има повече от R$ 1000,00 в чакащи фишове. За да направите това, поръчката ще извика Order.Customer.GetOutstandingBills(). Ако всичко е наред, методът Order.Save() се извиква. Заявката ще премине през слоя за релационно съпоставяне на обекта, където заявката и редовете на заявката се съпоставят с DataTable в DataSet, а DataSet се предава на слоя за достъп до данни, който се свързва с базата данни и генерира изрази за вмъкване от информацията в DataSet. Има, разбира се, много начини, по които може да се случи обектно-релационно картографиране, но не всички от тях ще включват трансформация в DataSet. Някои ще създадат оператора за вмъкване директно, но все пак ще използват слоя за достъп до данни, за да изпълнят този оператор.

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

Голямо предимство на работата с бизнес обекти е, че това наистина помага да организирате кода си. Ако погледнете назад към сложна логика, тя обикновено е много четлива, защото има много малко водопроводен код. Недостатъкът е, че повечето хранилища за данни все още са релационни и картографирането на бизнес обекти към релационни данни може да стане доста сложно.

услуги, базирани на схема

Току-що видяхте две противоположности, когато става въпрос за управление на потока от данни. Възможни са много вариации. Често срещан е вариантът, при който набор от данни се използва като основен носител на данни на потребителския интерфейс за съхраняване на данни, но отделни схеми (DTO) се използват за уеб услуги, извиквани от други системи. Приложният слой трансформира релационни данни в предварително дефинирана схема. Основното предимство на това е, че всяко приложение, което се позовава на услугата, не зависи от никакъв вид вътрешна реализация на компонента. Това позволява по-голяма гъвкавост при управление на версиите, обратна съвместимост на интерфейси и възможност за промяна на изпълнението на компонента, без да се променя интерфейсът на услугата.

Разбира се, можете да използвате бизнес обекти в уеб приложението и да заобиколите DTO трансформацията, но това обикновено работи добре само ако логиката на приложението е внедрена заедно с уеб приложението. Не забравяйте, че за да извикате Order.Save(), ще ви трябва връзка с база данни. Дали това е желателно зависи от вас и вероятно от вашия директор по сигурността.