Част 2. Нека поговорим малко за софтуерната архитектура

Този материал е част от поредицата "Въведение в развитието на предприятието" . Първата част, за работата в мрежа, е тук . Софтуерната архитектура се отнася до структурата, създадена в рамките на едно приложение, т.е. модулите и компонентите на цялата програма и How те си взаимодействат. Програмистите работят върху добри архитектури от много дълго време, така че не е изненадващо, че сме чували за много архитектурни модели. Трябва да ги разберете: когато пишете уеб приложение, е изключително важно да излезете с добра архитектура, тъй като уеб приложението има повече компоненти и модули от обикновеното приложение. Архитектурен образеце интелигентен начин за решаване на проблем с дизайна на софтуера. Вероятно сте попадали на шаблони за проектиране като фабричен метод, абстрактна фабрика, конструктор, прототип, сингълтън и евентуално други. Използваме ги, когато пишем code, създаваме класове и планираме How ще си взаимодействат класовете. Архитектурните модели се използват на по-високо ниво на абстракция, когато се планира взаимодействието на потребителя със сървъри, данни и други компоненти. Нека да разгледаме набързо някои модели и How да ги използваме.

Архитектура клиент-сървър

Името създава впечатлението, че всичко в този модел е просто и ясно. Но нека изясним някои моменти, така че когато започнете да изучавате Spring, да разберете за Howво говорим. Да приемем, че сте написали приложение за чат и вие и ваш приятел започнете да го използвате. Бихте могли да приемете много прост подход, като изпращате съобщения един на друг директно през интернет, като използвате известни IP addressи: Отначало всичко изглежда добре, докато друг ваш приятел не поиска да се присъедини към чата. Така че, когато решите да добавите ваш общ приятел към чата, се сблъсквате с архитектурен проблем: за всеки участник в чата трябва да предоставите актуална информация за броя на потребителите и IP address на новите потребители. И когато се изпрати съобщение, то трябва да бъде доставено до всички участници. Това са най-очевидните проблеми, които ще възникнат. Още един куп проблеми ще се крият в самия code. За да ги избегнете, трябва да използвате сървър, който ще съхранява цялата информация за потребителите, включително техните addressи. Съобщенията трябва да се изпращат само до сървъра. Той от своя страна изпраща съобщения до всеки един от получателите. Когато решите да добавите сървърна част към вашето приложение за чат, вие започвате да изграждате архитектура клиент-сървър.

Компоненти на архитектурата клиент-сървър

Да видим за Howво става дума. Архитектурата клиент-сървър е модел на проектиране, използван за създаване на уеб applications. Тази архитектура се състои от три компонента:

1. Клиент — От името му можем да разберем, че този компонент използва няHowва услуга (уеб приложението), свързвайки се със сървър, за да поиска няHowва информация.

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

3. Мрежа — Тази част е проста. Улеснява обмена на информация между клиент и сървър.

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

• клиентски модул — съдържа графичен интерфейс за влизане и изпращане/получаване на съобщения

• сървърен модул — уеб приложение, което се хоства на сървър и получава съобщения от потребители, обработва ги и след това ги изпраща на получатели

Когато искаме да разгледаме полезна (or не особено полезна) информация в Интернет, ние отваряме браузър, въвеждаме заявка в лентата за търсене и получаваме информация от търсачката в отговор. В тази верига браузърът е клиент. Той изпраща заявка с информация Howво търсим към сървъра. Сървърът обработва заявката, намира най-подходящите резултати, пакетира ги във формат, който браузърът (клиентът) може да разбере и ги изпраща обратно. Комплексните услуги като търсачките могат да имат много сървъри. Например сървър за оторизация, сървър за намиране на информация, сървър за генериране на отговор и т.н. Но клиентът не знае и не се интересува от нищо от това: за клиента сървърът е единна единица. Клиентът знае само за входната точка, т.е. address на сървъра, към който трябва да се изпращат заявките. Спомнете си приложението, което разгледахмепредишната част от тази серия . Той беше за наблюдение на средната температура на въздуха във всички страни в реално време. Архитектурата му изглежда по следния начин: Нашето приложение се намира на сървъра. Да кажем, че на всеки пет секунди той изпраща заявки до сървъри, управлявани от местни метеорологични станции, получава информация за температурата за определена страна от сървърите и съхранява тази информация. Когато клиентът ни помоли да „видим текущата температура на въздуха в света“, ние връщаме най-скоро съхранената информация, сортирана по държави. По този начин нашето приложение действа и като сървър (когато обработва потребителски заявки) и като клиент (когато получава информация от други сървъри). Проста архитектура клиент-сървър се използва много рядко и само за много прости applications. За наистина големи и сложни проекти използваме различни архитектури, с които ще се срещнете в бъдеще. Сега нека да разгледаме модел, който е много подобен на архитектурата клиент-сървър.

Тристепенна архитектура

Това е архитектурен модел, който въвежда трети модул — съхранение на данни . В този модел трите нива обикновено се наричат ​​слоеве or нива:

1. Клиентският слой е потребителският интерфейс, наричан още ниво на представяне. Това може да бъде уеб браузър, който получава HTML страници, or графичен потребителски интерфейс, написан с помощта на JavaFX. Основното е, че този слой позволява на потребителя да изпраща заявки до сървъра и да обработва неговите отговори.

2. Логическият слой е сървърът, който обработва заявки/отговори. Често се нарича още сървърен слой. Това е и мястото, където се извършват всички логически операции: математически изчисления, операции с данни, повиквания към други услуги or хранorща на данни и др.

3. Слоят на данните е сървърът на базата данни: нашият сървър взаимодейства с него. Този слой съхранява цялата информация, необходима за работата на приложението.

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

Предимства на тристепенната архитектура

Архитектура като тази ни дава много предимства, включително:

1. Възможността за защита срещу SQL инжектиране (това е атака срещу сървър; включва изпращане на SQL code, който, когато бъде изпълнен, позволява на атакуващ да повлияе на нашата база данни).

2. Разделяне на данните, до които искаме да контролираме потребителския достъп.

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

4. Мащабируемост (възможността да разширим нашето приложение до множество сървъри, които ще използват една и съща база данни.

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

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

Ако сте запознати, да речем, с шаблона за проектиране на фабричен метод , вероятно сте се чудor кога да го използвате. Понякога е трудно да решите Howво да направите: да създадете обект, като използвате оператора new or като използвате фабричен метод. Но с времето разбирането идва. Нещата са малко по-различни, когато става въпрос за архитектурни модели. Корпоративните рамки са предназначени да позволят на програмист да създаде проект въз основа на няHowъв общоприет модел. Съответно, преди да научите Spring Framework, определено трябва да разберете архитектурата клиент-сървър, тристепенната архитектура и MVC архитектурата. Не се притеснявайте: тепърва ще говорим за MVC архитектурата. Част 3. HTTP/HTTPS Част 4. Основите на Maven Част 5. Сървлети и Java Servlet API. Писане на просто уеб приложение Част 6. Контейнери на сервлети Част 7. Представяне на модела MVC (Model-View-Controller)