1. напрямок
2. Історія про JavaScript
3. Front-End
4. Back-End
5. Концепція web-додатки
6. Варіант архітектури для Web-додатки
7. висновок

ru-RU | створено: 13.05.2015 | опубліковано: 13.05.2015 | оновлено: 02.01.2018 | переглядів за весь час: 9626

Так вийшло, що в мене є певний досвід по розробки додатків. Початку відліку 2001 рік, тобто коли C # .NET був біля витоків. На сьогоднішній день, на мою адресу звучать безліч питань: Які технології актуальні? Яку архітектуру з яких технологій побудувати? Перспективи розвитку тієї чи іншої технології? Загалом, в цій статті поговоримо про вибір технології.

напрямок

Ні для кого не секрет, що в світі IT існує безліч технологій. Навіть якщо говорити тільки про клієнтської (front-end) частини, то можна, навскидку, згадати такі як: AngularJS , KnockoutJS , EmberJS , BreezeJS , DurandalJS та інші. Якщо ж говорити про серверної (back-end) частини ПО, тут в останні час з'явилося теж дуже багато можливостей, як то: Web API, OData, ASP.NET MVC, WCF-services. Хоча Microsoft і планує об'єднати перші три в одне ціле під назвою MVC 6, технології все одно різні.

Так вже вийшло, що я маю досвід роботи c платформою .NET. А якщо конкретно, то ASP.NET на C # (хоча досвід є і на Windows Mobile, Windows Phone, WPF, WCF і інші платформи). Колись я починав з ASP.NET WebForms, пізніше перейшов на ASP.NET MVC (про що не шкодую ні секунди). І в зв'язку з цим, розповідь буде йти щодо NET. А також ми поговоримо про JavaScript.

Історія про JavaScript

У стародавні часи, коли .NET ще не було і в думках, була така платформа ASP. Я звернув на неї увагу тільки починаючи з версії 3.0. У ті далекі часи, мова JavaScript (JS) був всього лише доповненням до основного мови ASP 3.0 (серверна розмітка в HTML). JS - виконував допоміжні функції для вирішення завдань на клієнтській стороні, тому що JavaScript виконуватися в браузері на клієнті. Дрібні функції, прості розрахунки і інші невимогливі операції: відобразити повідомлення про помилку, перевірити введення користувача, підставити значення за замовчуванням і інші функції - ось для чого в основному програмісти використовували JS.

На даний момент, ось уже на протязі 3-5 років JS переріс у щось більше, ніж просто допоміжний мову. Він придбав статус самостійного основного мови для розробки по web. Мова може тепер працювати безпосередньо з http-сервером (node.js), що ставить його на один рівень з іншими мовами.

Front-End

Вибір клієнтської частини від основної архітектури додатку слід почати з визначення, "що є що". Перед тим як почати вибирати, наведу схему архітектури сучасного web-додатки.

Отже, давайте розглянемо частину "Клієнт", адже саме це і є Front-End. Жовта зона, що складається з чотирьох підзон є прості поняття:

• базові операції - визначення namespace'ов, утиліти, налаштування програми, хелпери, допоміжні функції і класи та інші узагальнені збірки корисних речей. Це свого роду "Кладовочка", в якій повно різного інструменту і витратного матеріалу на вибір. Тут лежать базові визначення для програми.
• Widgets - контроли і компоненти сторонніх розробників, наприклад, jQuery UI, Bootstrap і інші корисні компоненти (контроли) і UI-фреймворки.
• MV * frameworks - фреймворки на JavaScript, які відповідають деяким вимогам, тобто "знають" про маршрутизації (router), прив'язка даних (data-binding), шаблонні уявлення (template / views), моделі (models) та доступ до даних (data access). MV * - являє собою сімейство патернів MVC, MVP, MVVM. Прикладами таких фреймворків можуть послужити: backbone.js, knockoutjs, maria.js.
• JavaScript-бібліотеки - збірки сторонніх розробників, саме ті, що є допоміжними інструментами або базовими основами. Наприклад, jQuery, underscore.js, moment.js і інші.

Все, що об'єднано в нижньому блоці розділу "Клієнт" можна назвати "App framework". Реалізації в конкретному додатку може значно відрізнятися в залежності від обраних технологій і інших сторонніх фреймворків, які перераховані у верхній (жовтій) частини розділу "Клієнт". Детальний опис цих компонентів системи ми відкладемо як теми для майбутніх статей, але порівняльну таблицю я все-таки наведу:

Back-End

Настав час розглянути частину "Сервер", тому що навряд чи знайдеться скільки-небудь корисний проект (сайт, додаток), який не був би жодним чином пов'язаний з даними (БД). Про наскрізну інтеграцію говорити особливо нічого, єдине, що можна згадати, що, так чи інакше, в будь-якому проекті є базові операції, як то: читання налаштувань, запис налаштувань, файлові операція читання / запису і інші подібного роду узагальнені операції. Модулі та сервіси які керують цими операціями носять ім'я - "управління операціями".

Що стосується "безпеки", то тут існує величезна кількість варіантів реалізації: авторизація та аутентифікація на основі ASP.NET SimpleMembership, Microsoft Identity , Open Auth і навіть власна реалізація механізмів.

За інших складових "кубика" "Web-сервер" пройдемося від низу до верху. Рівень доступу до даних (DAL) має в собі визначення "Компоненти доступу до даних". Під цим великим поняттям криються компоненти типу ORM (наприклад, MS EntityFramework або LLBLGen). А також компоненти "прямого" доступу до БД (наприклад, SQLDataReader, SqlCommand або кастомниє реалізації на їх основі).

"Програми" мають на увазі під собою допоміжні засоби для роботи з БД. Наприклад, генератори схем БД або генератори коду за типом таблиці, в загальному різного роду помічники для роботи з БД і її компонентами.

До "Сервісів" можна віднести такі компоненти як SQL Report Service або послуги з синхронізації даних, сервіси розподіляють навантаження або іншого типу сервіси, які працюють безпосередньо з БД.

"Рівень бізнес-логіки" - це є "додаток", як раз те, чим визначаються завдання і функції програми (web-додатки). Бізнес-логіка програми містить прищепила управління даними проходять через програму. Рівень бізнес-логіки покликаний вирішувати прикладні завдання.

"Рівень уявлення" - найпростіший для розуміння розділ архітектури, тому що він лежить на "поверхні" і його можна "помацати мишкою" :) Уявлення генеруючі серверною частиною програми є актуальними і на сьогоднішній день, але позиції такого роду підходу стрімко падають на користь HTML5 . Мені доводилося зустрічати додатки досить потужні і багатофункціональні, які були зроблені практично без використання JavaScript, але ера таких web-додатків практично зійшла нанівець.

Концепція web-додатки

Сучасні web-додатки "прагнуть" до виду Desktop-додатків, але специфіка роботи Web стандартів, тобто асинхронна модель поведінки, коли на будь-який Request доводиться чекати Response від сервера, накладає ряд обмежень на дизайн і, відповідно, на архітектуру програми. Прикладом може бути наприклад, обов'язкова вимога (в описі Web 2.0) повідомлення користувача про процес запиту. Тобто, якщо користувач клікнув кнопку "відправити повідомлення", то програміст повинен повідомити користувача про перебіг процесу, показавши на час очікування відповіді від сервера про результат операції картинку анімації, або висновок динамічного повідомлення. Зрозуміло, що подібного роду інтерфейс може бути і в Desktop-додатках, але для Web-платформи це ключове поняття (особливо якщо врахувати, що на Request не завжди приходить Response).

Варіант архітектури для Web-додатки

Напевно, прийшов час розповісти, які переваги і чому обираю я. Треба відзначити, що з часом були перепробувані маси різних технологій і фреймворків. Історію цих проб і помилок можна простежити за статтями мого блогу. Для простоти я приведу технології, на використанні яких я зупинився, одним списком, але список буде з коментарями.

Front-End:

• KnockoutJS - як фреймворк для зв'язування даних JavaScript-моделей з HTML. У відповідь на дуже часте питання "чому саме knockout" відповідаю. Принцип зв'язування даних у KnockoutJS побудований на моделі MVVM, що відповідає принципу в WPF і Silverlight, а значить мені не потрібно переосмислювати базові поняття, принципи і патерни. До речі сказати, AngularJS реалізує принцип MVC, що не може не вплинути я внутрішні концепції при реалізації програм з його використанням. OpenSource
• Для доступу до web-сервісів я використовую jQuery.ajax (), іноді AmplifyJS, і зовсім рідко - виклики безпосередньо через XMLHttpRequest. OpenSource
• Bootstrap - фреймворк для побудови UI. Даний фреймворк створює адаптивну HTML-розмітку, яка однаково добре виглядає як на різних браузерах, так і на різних дозволах екрану. OpenSource
• SiteJs - це набір скриптів для побудови web-додатки за принципами SPA (і не тільки).

Back-End:

• Web API - сучасні рішення для побудови сервісів на основі RESTful. OpenSource
• EntityFramework - швидко розвивається ORM від компанії Microsoft, який недавно став OpenSource.
• ASP.NET MVC - як web-платформа для web-додатків. OpenSource. Альтернативою може бути node.js або Web API self-host. По суті, абсолютно не важливо яку web-платформу ви використовуєте. Ключовий момент полягає в тому, що HTML5 може працювати на будь-який, а сервіс надає дані для вашої програми, може бути як платформі ASP.NET, так і на інших сучасних платформах, аж до сторонніх сервісів.

висновок

На цьому напевно, все. Єдине, що варто відзначити, так це те, що кожен з вас має право обирати будь-яку зручну і близьку по духу конфігурацію архітектури додатку. У цій статті я озвучив лише базові поняття та основні принципи побудови сучасного web-додатки (сайту). З іншого боку, у кожного з обраного компонента архітектури є свої плюси і мінуси. Вміючи вправно добирати "правильні кубики" дозволить в подальшому: а) уникнути необхідність "переробки" додатка або його частин; б) з легкістю підтримувати додаток, оновлюючи збірки і фреймворки на нові більш продуктивні версії; в) йти в ногу з часом, застосовуючи нові стандарти в програмуванні і дизайні.

посилання