Хорошо ли сделать Data Access Layer отдельным слоем от сервисного уровня
У меня вопрос об архитектуре, с которой я работаю.
у нас есть бэкэнд-сервис restful, уровень данных (который реализован в python eve, а также restful-сервис) и база данных. Уровень данных (доступа) сам по себе является независимым API отдыха.
В нашем сервисном приложении у нас есть настраиваемый репозиторий Python Eve, который выполняет вызовы уровня данных (доступа), а затем уровень данных будет запрашивать все, что запрашивается вызовом из базы данных.
Причина, по которой он разделен, одна из них заключается в том, что мы хотим изолировать логику данных (логику запросов) от нашей бизнес-логики (бэкэнд-сервис).
Стоимость очевидна, еще один уровень, еще один раунд ввода-вывода для каждого запроса.
Может кто-нибудь с опытом архитектуры сказать мне, является ли этот отдельный уровень доступа к данным хорошей практикой или нет и почему?
1 ответ
Если посмотреть на обсуждаемую архитектуру, ваш проект должен быть достаточно большим, чтобы оправдать затраты на его разработку. Для небольших проектов эта архитектура будет излишней.
Предполагая, что ваш проект достаточно большой, да; всегда хорошо разделять уровни DAL, BLL и Application. Отослать это и это.
Преимущество заключается в чистом разделении, которое улучшает понимание, дает вам контроль над каждой частью и снижает затраты на техническое обслуживание.
С другой стороны, как вы сказали, стоимость очевидна (еще один уровень, еще один раунд ввода-вывода). Да; Вот почему мой первый абзац обсуждает размер проекта. В крупных проектах это компромисс; вы выбираете одно над другим.
В крупных проектах основной задачей должна быть ремонтопригодность ИМО. Поймите, что преждевременная оптимизация - корень всего зла. Итак, вы начинаете с хорошей обслуживаемой архитектуры. Каждая технология рекомендует основные правила для улучшения производительности; реализовать их изначально. Если вы обнаружите какие-либо проблемы с производительностью с течением времени, найдите и исправьте их. Фактически, благодаря разделенным слоям, легко найти узкое место.
Есть и другие преимущества. Вы можете тестировать каждый слой отдельно. Вы можете работать на каждом уровне независимо друг от друга, например, для улучшения производительности, изменения технологии и т. Д. Отладка будет слишком простой.
В принципе, разработка микросервисной архитектуры хороша для больших проектов, иначе это будет пустой тратой ресурсов. Но вам нужно учесть некоторые вещи, прежде чем создавать отдельный микросервис, поскольку существуют сложности, такие как накладные расходы IPC, распределенные данные, распространение не является бесплатным, изменение данных уже не является простым делом, поскольку это требует координации между различными сервисами, которые являются этим микросервисом (в уровень доступа к данным вашего дела). Поскольку количество IPC может быть настолько большим, что это может привести к большим накладным расходам времени. Таким образом, API необходимо разрабатывать так, чтобы он не увеличивал значительно время на обработку. Данные распределены по сервисам, поэтому о них нужно позаботиться должным образом.
И да, это хорошая практика, причина проста, что вы делаете абстракцию сервисов. При этом они могут разрабатываться независимо, поскольку эти службы слабо связаны. И даже если требования к базе данных будут изменены, другие службы не должны беспокоиться об этом. Это означает, что даже если весь проект переходит с MySQL на Cassandra или Hadoop, необходимо изменить только DAA(уровень организации доступа к данным), остальные службы останутся прежними. Кроме того, эти сервисы намного проще отлаживать и тестировать.
Таким образом, всегда будет компромисс при выборе микросервисной архитектуры (одна с несколькими службами для разделения бизнес-логики и данных) или монолитной архитектуры (одна служба, содержащая всю логику). В общем, если проект большой и вы используете монолитную архитектуру, это может привести вас в монолитный ад. Поскольку приложение становится чрезвычайно большим, как большой ком с грязью, из-за чего быстрая, частая и надежная доставка становится невозможной, а стек технологий становится все более устаревшим, а перезапись также становится невозможной.