Мені було цікаво, чи може хтось порівняти / порівняти різницю між інтерфейсом, серверною базою та проміжним програмним забезпеченням ("середній рівень"?) Стисло.
Чи бувають випадки, коли вони збігаються? Чи бувають випадки, коли вони ПОВИННІ збігатися, а інтерфейс / серверну частину не можна розділити? Що стосується вузьких місць, який кінець пов’язаний із яким типом вузьких місць?
Відповіді:
Ось одна поломка:
Фронт-енд рівень -> Рівень інтерфейсу користувача, який зазвичай складається з поєднання HTML, Javascript, CSS, Flash та різних кодів на стороні сервера, таких як ASP.Net, класичний ASP, PHP тощо. Подумайте про це як про найближче до користувача з точки зору коду.
Проміжне програмне забезпечення, середній рівень -> Один рівень назад, зазвичай називається "водопровідною" частиною системи. Java та C # є загальноприйнятими мовами для написання цієї частини, яку можна розглядати як зв'язок між користувальницьким інтерфейсом та даними, а можуть бути веб-службами, компонентами WCF або іншими компонентами SOA.
Фоновий рівень -> Бази даних та інші сховища даних, як правило, на цьому рівні. Oracle, MS-SQL, MySQL, SAP та різні готові програми приходять на розум для цього програмного забезпечення, яке є остаточною обробкою даних.
Між будь-яким із них може існувати перекриття, оскільки ви могли б все перелити в один шар, наприклад веб-сайт ASP.Net, який використовує вбудовану функціональність AJAX, яка генерує Javascript, тоді як код ззаду може містити команди бази даних, що робить код позаду як середнім так і зворотним -кінцеві яруси. Як варіант, можна використовувати VBScript, щоб діяти як усі шари, використовуючи об’єкти ADO та об’єднуючи всі три рівні в один.
Подібним чином, в деяких випадках можна поєднувати проміжне програмне забезпечення та фронт-або задній інтерфейс.
Вузькі місця, як правило, мають кілька різних рівнів:
1) Обробка бази даних або внутрішня обробка -> Це може варіюватися від заробітної плати чи продажів чи інших завдань, коли пропускна здатність до бази даних заважає.
2) Вузькі місця проміжного програмного забезпечення -> Це може бути місце, де деякі веб-служби можуть втратити пропускну здатність, але передній і задній кінці мають пропускну здатність для обробки більшої кількості трафіку. Крім того, може бути якийсь сервер, який є частиною системи, яка не є цілком частиною інтерфейсу користувача, або вихідні дані, які можуть бути вузьким місцем, використовуючи щось на зразок Biztalk або MSMQ.
3) Фронтальні вузькі місця -> Це може спричинити проблеми з клієнтом або сервером. Наприклад, якщо ви взяли ПК низького класу і завантажили веб-сторінку, яка складалася з великої кількості даних, що завантажуються, клієнт міг би опинитися там, де є вузьке місце. Подібним чином, сервер може робити чергу запитів, якщо його забивають запитами, такими як Amazon.com або інші веб-сайти з високим трафіком можуть отримувати часом.
Дещо з цього підлягає інтерпретації, тому воно не є ідеальним будь-якими способами та YMMV.
РЕДАГУВАТИ: Щось, що слід врахувати, це те, що деякі системи можуть мати декілька інтерфейсів або фонів. Наприклад, система управління вмістом, швидше за все, матиме можливість відвідувачами сайту переглядати вміст, який є інтерфейсним, але як щодо того, як редактори вмісту можуть змінювати дані на сайті? Можливість отримання цих даних може розглядатися як інтерфейс, оскільки це компонент інтерфейсу користувача, або як інтерфейс, оскільки вона використовується внутрішніми користувачами, а не загальною публікою, яка переглядає сайт. Отже, тут є що сказати для контексту.
Взагалі кажучи, люди відносять рівень презентації програми як її передній кінець , його рівень стійкості (як правило, базу даних) як задній кінець , а будь-що середнє - як середній рівень . Цей набір ідей часто називають 3-рівневою архітектурою. Вони дозволяють розділити вашу заявку на більш зрозумілі (і перевіряються!) Фрагменти; Ви також можете повторно використовувати код нижчого рівня на більш високих рівнях.
Який код є частиною якого рівня, є дещо суб’єктивним; графічні дизайнери схильні сприймати все, що не є презентацією, як задній кінець, люди, що працюють над базою даних, думають про все, що знаходиться перед базою даних, як про зовнішній вигляд тощо.
Однак не всі програми потрібно відокремлювати таким чином. Напевно, більше роботи є 3 окремими підпроектами, ніж просто відкрити index.php і отримати злом; залежно від (1), як довго ви плануєте підтримувати програму (2) наскільки складним ви очікуєте, що додаток отримає, ви можете відмовитися від складності.
Фактично у вашому запитанні є 3 запитання:
Те, що описав JB King, є правильним, але це конкретна, проста версія, де насправді він перетворив фронт, середній та bacn на рівень MVC. Він наніс карту M на задню, V на передню і C на середню.
Для багатьох людей це чудово, оскільки вони походять з потворного світу, де навіть MVC не застосовувався, і ви можете мати прямі дзвінки в БД.
Однак у реальних, складних веб-додатках у вас дійсно є два-три різних шари, які називаються передній, середній і задній. Кожен з них може мати відповідну базу даних і контролер.
Кінцевий користувач бачитиме інтерфейс. Його не слід плутати з фронт-офісом, який є інтерфейсом користувача для параметрів та адміністрування фронту. Фронт-енд зазвичай представляє собою якусь систему управління вмістом або платформу електронної комерції (Magento тощо)
Середній кінець не є обов’язковим і є місцем ділової логіки. Він базуватиметься на PIM, інструменті MDM або на якійсь власній базі даних, де ви збагачуєте свої товари чи статті (для CMS). Це також буде місце, де ви кодуєте ділові функції, які потрібно спільно використовувати між різними інтерфейсами (наприклад, між інтерфейсом ПК та мобільним додатком на основі API). Іноді ESB або такий інструмент, як ActiveMQ, буде вашим середнім класом
Бек-енд буде 3-м шаром, що оточує вашу вихідну базу даних або вашу ERP. Це може бути jsut API, що переписується та читає з вашого ERP. Це може бути ваша база даних постачальника, якщо ви займаєтесь електронною комерцією. Насправді це насправді залежить від веб-проектів, але це завжди центральне сховище. Доступ до нього можна отримати або через виклик БД, через API, або рівень Hibernate, або повнофункціональний фоновий додаток
Цей опис означає, що відповісти на інші 2 питання неможливо в цій темі, оскільки вузькі місця дійсно залежать від того, що містять ваші 3 кінці: те, що написав JB King, залишається вірним для простих архітектур MVC
на той час, коли було задано питання (5 років тому), можливо, модель MVC ще не була так широко прийнята. Зараз немає абсолютно жодної причини, чому шаблон MVC не дотримувався б, а погляд був би прив'язаний до викликів БД. Якщо ви прочитаєте питання "Чи бувають випадки, коли вони ПОВИННІ збігатися, і інтерфейс / серверну частину не можна розділити?" в більш широкому розумінні, з 3-ма різними компонентами, тоді бувають випадки, коли архітектура з 3 шарами марна, звичайно. Подумайте про простий особистий блог, вам не потрібно буде збирати зовнішні дані або опитувати черги RabbitMQ.
Ось реальний приклад, який показує передній / середній / задній кінець.
Можливе перекриття інтерфейсу та бекенда. Зазвичай це призводить до довгострокових проблем із обслуговуванням додатків та масштабованістю. Досить поширений у застарілих додатках.
Більшість сучасних технологічних стеків спонукають розробників до чіткого розділення. Наприклад, на малюнку ви бачите, що серверний сервіс першої системи має веб-службу відпочинку, яка є чіткою лінією розділення.
Більшість вузьких місць в основному спричинені базою даних / мережею. Бази даних знаходяться у внутрішній системі. Що стосується мережевих проблем, кожне з'єднання проходить через netowrk, тому кожне з'єднання може бути повільним. При гарному дизайні додатків цих проблем можна уникнути в значній мірі.
Що стосується мережі та безпеки, то бекенд є на сьогоднішній день найбільш безпечним (повинен бути) вузлом.
Частина середнього класу, як правило, веб-сервер, буде дещо дикою і багато в чому відрізаною від мережі компанії. Вузол середнього класу зазвичай розміщується в DMZ і сегментується від мережі за допомогою налаштувань брандмауера. Більша частина аналізу веб-сторінок коду на стороні сервера обробляється на веб-сервері середнього рівня.
Потрапити до серверної бази означає пройти середній кінець, який має ретельно розроблений набір правил, що дозволяють / забороняють доступ до життєво важливих цифрових модулів, які зберігаються на сервері бази даних (серверних даних).
Frontend посилається на сторону клієнта, тоді як серверна частина - на сторону сервера програми. І те, і інше має вирішальне значення для веб-розробки, але їх ролі, обов'язки та середовище, в якому вони працюють, абсолютно різні. Frontend - це в основному те, що бачать користувачі, тоді як бекенд - це те, як все працює