архитектура, идейни пластове и условията за тяхната употреба

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

примерни споразумения

Нека разгледаме например добре познатата рамка ASP.NET MVC. Ако сте работили с тази система, вие вероятно сте забелязали, че проектът, който е създаден от Visual Studio в модели на папките по подразбиране. Гледки. Контролери. Това е първото споразумение, че всеки тип файл (клас) се намира в своя собствена папка.

В първата версия на рамката ASP.NET MVC контролери може да се намират само в папката контролери. По-късно това ограничение.

Esli при разработването на всеки метод контролера, който се опита да се създаде метод и да го отворите без да се създава изглед (View) на този метод, системата ще ви даде съобщение за грешка:

Имайте предвид, че когато системата се е опитал да открие "загубени" представяне преди да издаде съобщение. Това поведение се обуславя и от споразуменията на рамката. В този случай, правилото е, че ако изгледа (Изглед) не се намират в папката Home контролер. трябва да се търсят първо в споделената папка. След това всичко е едно и също, но с различно разширение за друг ядро ​​(ако свързване на няколко маркиране рендиране двигатели). В действителност, на споразуменията от този вид в ASP.NET MVC много голям брой. И толкова повече ще се срещнем с тях, отколкото ще по-дълбоко в "дебрите" на рамката.

ASP.NET MVC рамка като всички рамки, поне в по-голямата си част, са базирани на парадигмата "за konfigruratsii споразумение" (конфигурация над конвенция).

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

Същността на тази статия е да покаже, че употребата на посочения по-горе парадигма във връзка с колективното развитие може значително да се ускори (и опростяване) процеса на разработване на приложение, особено ако развитието на стоки и услуги на голям брой разработчици. "Конвенция над конфигурация" може да реши въпроси, които често се губят ценни минути, часове или дори дни и седмици. Например, често възниква въпросът, как да се обадите на вашия клас, собственост метод, проектиране, променлива (разтвор)? Как много фирми, толкова много възможности, ако не и предварително съгласувани с правилата за именуване. И ако новият разработчик дойде в отбора, а след това тя може да започне да пише правилно код, без да знаят за правилата, на които се писмени този код? Разбира се, има огромен брой допълнителни инструменти (например StyleCop), които улесняват задачата, но те са безсилни в някои случаи.

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

Малко история

В възхода на пример kachechestve на сложност, ще доведе до развитието на бизнес-логика модели, които описват как и къде необичайно и би трябвало да relizovana бизнес логика. Модели за организиране на бизнес слой (бизнес логика) с течение на времето е претърпял значителни промени, от прости до сложни. Нещо повече, тази еволюция не е спряло.

Всеки от тях е описано подробно от Мартин Фаулър. така че аз няма да се спирам на тях в детайли. Evolution казва, че системата за програмиране, който манипулира данните става все по-трудно. Трябва да се разбере, че използването на шаблони за дизайн за изграждане на сложни системи архитектура значително опростява допълнително система за подпомагане (поддръжка) и въвеждането на нова функционалност, но развитието е много по-сложно. За да се улесни това развитие най-много, предлагам да се използват правилата на споразумението, което е "Конфигурация на споразумението", но по отношение на процеса на писане на код.

Какво мога да кажа, ако не само за разработчици, но и сред клиентите все по-често чуваме такива думи и фрази: ORM. Хранилище. Бизнес Layer. Абстракция и зависимостта на инжектиране, MVVM и др.

Сред разработчиците отидете на дългогодишни дебати дали да се използва допълнителен "слой" на ORM като между бази данни и DAL. Например, на sql.ru или habrahabr.ru често повдигнати теми. Лайтмотивът в такива спорове идеята звучи ". За сложни проекти с използване на ORM значително намалява рутина.".

Така се случи, че за известно време спрях да споделят проекти в сложна и проста, базирани на използването на ORM за проекти с всякаква сложност. Особено това, че подходът на ORM CodeFirst позволява използването (по-специално, EntityFramework).

Бих предполагат, че вече сте запознати с моделите на дизайна. и по-специално, с модели и Хранилище UnitOfWork. тя се основава на тях, и Аз ще говоря за условията за изграждане на достъп до данни слой (слой данни Access). Да приемем също, че имате представа за инжектирането на зависимост.

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

Основни правила и условия за именуване

Аз не се уморяват да повтарят фразата "всичко е измислено за нас", и това се повтаря в този контекст. В развиващия се свят вече има споразумения за именуване, например, Microsoft или тези, друг вариант в Уикипедия. Като основа за своите правила, взех споразумението от Microsoft. Така че нека да започнем.

Правила пространство от имена именуване на компанията за проекта:

Името на всеки проект трябва да започва с CompanyName>. Това правило важи и за развитие на компанията.

След първите думи CompanyName> чрез точката трябва да се даде име на проекта.

За името на проекта, трябва задължително да следва името на платформата.

След тази платформа част от вътрешната архитектура на проекта.

X Не използвайте черти, тирета и други символи.

X Не използвайте съкращения и акроними общоизвестни

X Не използвайте номера на именуване.

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

Наименуване променливи:

Използвайте разбираеми имена на идентификатори. Например, собственост с име HorizontalAlignment е по-интуитивно, отколкото AlignmentHorizontal.

X Не използвайте черти, тирета и други символи.

X Не използвайте унгарската нотация.

X НЕ използвайте имена на идентификатори които са в противоречие с ключови думи, които обикновено се използват езици за програмиране.

X Не използвайте съкращения или намаляване, като част от името на идентификатор. Например, вместо да се използва GetWindow GetWin.

X Не използвайте съкращения, които не се приемат, а дори и да са те, само когато е необходимо.

Използвайте семантично смислени имена вместо езикови запазени думи за видовете имена. Например GetLength име по-добро GetInt.

Използвайте името на универсалната вида на CLR, а не името на конкретен език, в редки случаи, когато идентификаторът не е семантичен смисъл отвъд неговия вид. Например, методът на превръщане, трябва да бъде извикана Int64 ToInt64. вместо ToLong (както Int64 - е името на CLR за C # -psevdonim дълго). Таблицата по-долу дава някои основни типове данни с използване на имена на CLR типове околната среда (и съответните видове имена за C #, Visual Basic и C ++).

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

Примери, които не трябва да се използват, когато именуване именни пространства:

Примери пространство от имена за именуване и проекти:

Името на разтвор (разтвор):

Имената на проекти (проекти) от вида, принадлежащи към нивото на абстракция:

Резюме ниво Layer достъп до данни

Така че, в своите проекти, аз използвам следните нива на абстракция до нивото на бизнес логика:

Това са основните понятия за повечето проекти, но трябва да призная, че има проекти, които е трябвало да се добави по-високи нива на нивото на мениджър. Първите Сега първите неща. Да вземем за по-голяма яснота, специфичния характер и ще направи за тях от класовете на обвивки за нивото на бизнес. Да предположим, че имаме в проекта е по същество Категория. Post. Tag. Коментар. Тя изглежда като характер за прилагане на блог? Така е.

хранилище

Надявам се да прочетете описанието на снимката за хранилище, но аз ще ви обясни, че основните операции са: четене списък база данни, четене от база данни единен субект по идентификатора, поставете нов запис в базата данни, да редактирате съществуващите записи в базата, премахване на записите. Някои хранилището може да има допълнителни методи, например, Clear метод за LogRepository хранилище. Така че, за всеки един от тези субекти се създаде хранилище: CategoryRepository. PostRepository. TagRepository. CommentRepository.

Правила за именуване на хранилището: името на същността в единствено число, преди думата хранилище.

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

Следваща в йерархията на нивата на бизнес логика, достъп до данни е доставчик. Говорейки за това, ще дам един пример за връзката между лица Tag и пост. Да предположим, че се изисква етикета (таг), свързани с влизането на блог (пост) на "много-към-много" и маркер за записите в блог. Така се оказва, че когато добавяте публикация в блог, че ще трябва по някакъв начин да се справят с етикетите (тагове). Тази функционалност е обект на модел единица работа. който централно управлява множество лица. По този начин, PostProvider частично реализира модел единица работа.

именуване правило Доставчик на: име на лицето, посочено в единствено число, преди думата Доставчика.

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

Член Зависимост инжектиране: Конструкторът на Доставчика клас могат да се присъединят зависимости хранилище обекти.

Забравих да спомена, че в хранилището класове трябва да се присъединят към DbContext (EntityFramework) или представител на резюмето.

Член Зависимост инжектиране: хранилището класовете могат да се присъединят DbContext (EntityFramework) или абстракция за този клас.

Член Зависимост инжектиране: Управителят може да се присъедини към класа на зависимостите Доставчик на обекти.

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

контрольор

Говорейки за ASP.NET MVC да не говорим за контролери, които са в основата на рамката, около които се гради цялата инфраструктура. В MVC-контролер (API-контролер и) може да се излива видове в зависимост Repository. Доставчик. Manager.

Член Зависимост инжектиране: Управителят също могат да се присъединят към класа на зависимостите хранилище обекти.

Бих искала да отбележа, че в bolshestve случаи операциите, които ще бъдат наречени от контролера трябва nahoditcya на доставчик и нивото на мениджър. тъй като тези две нива, изпълнявани съвместно единица работа. и експлоатацията на хранилището често не участват в бизнес процесите на "голям" приложения.

именуване правило за Controller: име на лице, посочено в множествено число на думата Controller.

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

Член Зависимост инжектиране: хранилището класове, доставчик, ръководител служба могат да се присъединят обекти.

заключение

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

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

ASP.NET MVC: Оптимизиране на линкове на уеб сайта или SEO приятелски MVC

ап WPF MVVM за използването на PRISM 6 и Autofac