Разница между frontend, backend и middleware в веб-разработке
Мне было интересно, может ли кто-нибудь сравнить/сравнить различия между frontend, backend и middleware ("middle-end"?) кратко.
есть ли случаи, когда они перекрываются? Есть ли случаи, когда они должны перекрываться, и интерфейс/бэкэнд не могут быть разделены? Что касается узких мест, то какой конец связан с каким типом узких мест?
5 ответов:
вот одна разбивка:
интерфейсный уровень- > уровень пользовательского интерфейса обычно состоит из смеси HTML, Javascript, CSS, Flash и различного кода на стороне сервера, такого как ASP.Net, классический ASP, PHP и др. Думайте об этом как о самом близком к пользователю с точки зрения кода.
Middleware, средний уровень - > один уровень назад, обычно называемый "сантехнической" частью системы. Java и C# являются общими языками для написания этой части, которые можно рассматривать как клей между пользовательским интерфейсом и данные и могут быть веб-сервисами или компонентами WCF или другими компонентами SOA, возможно.
внутренний уровень - > базы данных и другие хранилища данных, как правило, находятся на этом уровне. Oracle, MS-SQL, MySQL, SAP и различные готовые части программного обеспечения приходят на ум для этой части программного обеспечения, которая является окончательной обработкой данных.
перекрытие может существовать между любым из них, поскольку вы могли бы все вылить в один слой, как ASP.Net сайт, который использует встроенный AJAX функциональность, которая генерирует Javascript, в то время как код позади может содержать команды базы данных, делающие код позади содержат как средний, так и внутренний уровни. Кроме того, можно использовать VBScript, чтобы действовать как все слои, используя объекты ADO и объединяя все три уровня в один.
аналогично, в некоторых случаях можно комбинировать промежуточное программное обеспечение и переднюю или заднюю часть.
узкие места обычно имеют несколько разных уровней для них:
1) база данных или серверная часть обработка - > это может варьироваться от заработной платы или продаж или других задач, где пропускная способность к базе данных увязает вещи вниз.
2) узкие места промежуточного программного обеспечения - > это было бы, где некоторые веб-службы могут поражать емкость, но передние и задние концы имеют пропускную способность для обработки большего трафика. Кроме того, может быть какой-то сервер, который является частью системы, которая не совсем часть пользовательского интерфейса или необработанные данные, которые могут быть узким местом, используя что-то вроде Biztalk или MSMQ.
3) Узкие места переднего плана - > это может привести к проблемам на стороне клиента или сервера. Например, если вы взяли компьютер низкого класса и загрузили веб-страницу, которая состояла из большого количества загружаемых данных, клиент может быть там, где узкое место. Точно так же сервер может стоять в очереди запросов, если он получает забитые запросы, как то, что Amazon.com или другие сайты с высоким трафиком могут получить время от времени.
некоторые из них подлежат интерпретации, поэтому они никоим образом не совершенны и МММ.
EDIT: следует учитывать, что некоторые системы могут иметь несколько передних или задних концов. Например, система управления контентом, скорее всего, будет иметь способ для посетителей сайта просматривать контент, который является интерфейсным, но как насчет того, как редакторы контента могут изменять данные на сайте? Возможность извлечения этих данных можно рассматривать как внешний интерфейс, поскольку это компонент пользовательского интерфейса, или его можно рассматривать как внутренний интерфейс, поскольку он используется внутренними пользователями, а не широкая публика просматривает сайт. Таким образом, здесь есть что сказать для контекста.
вообще говоря, люди ссылаются на уровень представления приложения как его передний конец, его уровень сохраняемости (база данных, как правило) как конец, и что между средний уровень. Этот набор идей часто называют трехуровневой архитектурой. Они позволяют разделить ваше приложение на более понятные (и тестируемые!) куски; вы также можете более легко использовать код нижнего уровня на более высоких уровнях.
какой код часть этого уровня несколько субъективна; графические дизайнеры склонны думать обо всем, что не является представлением, как о заднем конце, люди базы данных думают обо всем перед базой данных как о переднем конце и так далее.
Не все приложения должны быть разделены таким образом,. Это, конечно, больше работы, чтобы иметь 3 отдельных подпроектов, чем просто открыть индекс.php и получить трещины; в зависимости от (1) Как долго вы ожидаете, чтобы поддерживать приложение (2), как сложно вы ожидайте, что приложение получит, вы можете отказаться от сложности.
есть на самом деле 3 вопроса в вашем вопросе :
- определить интерфейс, середину и заднюю часть
- как и когда они пересекаются ?
- связанные с ними обычно проблемы.
то, что описал JB King, верно, но это конкретная, простая версия, где на самом деле он сопоставил фронт, середину и bacn со слоем MVC. Он сопоставляется м на спине, в передней, и с середины.
для многих людей, это просто хорошо, так как они приходят из уродливого мира, где даже MVC не был применен, и вы могли бы иметь прямые вызовы DB в представлении.
однако в реальных, сложных веб-приложениях у вас действительно есть два или три разных слоя, называемых передним, средним и задним. Каждый из них может иметь связанную базу данных и контроллер.
интерфейс будет виден конечным пользователем. Его не следует путать с фронт-офисом, который является пользовательским интерфейсом для параметров и администрирования фронта. Фронт-энд обычно будет какой-то CMS или платформой электронной коммерции (Magento и т. д.)
средний конец не является обязательным и там, где бизнес-логика. Он будет основан на PIM, инструменте MDM или какой-то пользовательской базе данных, где вы обогащаете свои продукты или свои статьи (для CMS). Это также будет место, где вы будете кодировать бизнес-функции, которые должны быть разделены между различными интерфейсами (например, между интерфейсом ПК и мобильным приложением на основе API). Иногда ESB или инструмент, такой как ActiveMQ, будет вашим средним концом
back-end будет 3-м слоем, окружающим вашу исходную базу данных или ERP. Это может быть просто написать любое по API и чтения из вашей ERP. Это может быть ваш поставщик БД, если вы занимаетесь электронной коммерцией. На самом деле, это действительно зависит от веб-проектов, но это всегда центральное хранилище. Это будет получить доступ через БД вызов, через API, или гибернации яруса, или полнофункциональный бэк-конец применение
Это описание означает, что ответ на другие 2 вопроса невозможен в этом потоке, поскольку узкие места действительно зависят от того, что содержат ваши 3 конца : то, что написал JB King, остается верным для простых архитектур MVC
в то время, когда был задан вопрос (5 лет назад), возможно, шаблон MVC еще не был так широко принят. Теперь нет абсолютно никакой причины, по которой шаблон MVC не будет следовать, и представление будет привязано к вызовам DB. Если Вы читаете вопрос "существуют ли случаи, когда они должны перекрываться, а интерфейс/бэкэнд не могут быть разделены?"в более широком смысле, с 3 различными компонентами, то есть время, когда архитектура 3 слоев бесполезна, конечно. Подумайте о простом личном блоге, вам не нужно будет вытаскивать внешние данные или опрашивать очереди RabbitMQ.
вот пример реального мира, который показывает передний / средний / задний конец.
общее описание:
- интерфейс отвечает за представление данных пользователю. Обратите внимание на интересную причуду, что у вас может быть два разных передних конца, связанных с одним backend
- модуль бизнес-логики и хранения данных.
- Middleware (activemq на картинке) отвечает за систему к системе. интеграции между серверными системами. Обычно это устанавливается как отдельное приложение
перекрытие:
можно иметь перекрытие между frontend и backend. Это обычно приводит к долгосрочным проблемам с обслуживанием приложений и масштабируемостью. Довольно часто встречается в устаревших приложениях.
большинство современных стеков технологий, поощрять разработчиков, чтобы иметь строгое разделение. Например, на рисунке вы можете видеть, что бэкэнд первой системы имеет веб-службу rest что является четкой разделительной линией.
узких мест
большинство узких мест в больших вызваны базой данных / сетью. Базы данных находятся в серверной. Что касается сетевых проблем, каждое соединение проходит через netowrk, поэтому каждое соединение может быть медленным. При хорошем дизайне приложений эти проблемы можно избежать в значительной степени.
с точки зрения сети и безопасности, бэкэнд на сегодняшний день является самым (должен быть) безопасным узлом.
средняя часть, обычно являющаяся веб-сервером, будет несколько в дикой природе и во многих отношениях отрезана от сети компании. Средний узел обычно размещается в DMZ и сегментируется от сети с настройками брандмауэра. Большая часть анализа кода на стороне сервера веб-страниц обрабатывается на среднем веб-сервере.
добраться до серверной средства переход через средний конец, который имеет тщательно разработанный набор правил, разрешающих/запрещающих доступ к жизненно важным номерам, которые хранятся на сервере базы данных (бэкэнд).