Трехуровневая архитектура доступа к данным
Я занимаюсь разработкой приложения для социальной сети для устройства Android и буду использовать веб-сервис RESTful, который находится на логическом уровне многоуровневой архитектуры.
Теперь меня немного смущает уровень данных и уровень логики. Я вижу правила для логического уровня, которые говорят: "Не должен содержать презентацию или код доступа к данным". Я получаю часть кода презентации, но, конечно, если бы мой веб-сервис был, например, PHP, MySQL и Apache, у меня должно было бы быть что-то вроде
$result = mysql_query("SELECT entry, name, level, description FROM
users ORDER BY name") or die(mysql_error());
(Не обращайте внимания на тот факт, что это не использует mysqli) Разве это не относится к бизнес-логике, и должен ли на компьютере существовать второй веб-сервис, содержащий базу данных, которая будет выполнять этот код на основе информации из логического уровня?
2 ответа
В приложениях N-уровня хорошей идеей будет отделить ваш средний уровень от вашего от деталей или внутренней работы вашего хранилища данных. В некоторых проектах это может быть излишним.
Эта абстракция позволяет вам выключать RDMS или подключаться к нескольким RDMS без переписывания логики бизнес-уровня. Ваш код также выиграет от модульности.
Одним из способов достижения этого является инкапсуляция всех таблиц вашей базы данных с помощью CRUD (ORM mappers делают это легко). С тех пор эти классы станут вашим уровнем данных.
Например, на самом высоком уровне вашего уровня данных у вас может быть функция, которая возвращает список пользователей по идентификатору пользователя, здесь пользователь - это определенный класс, который имеет свойства, соответствующие вашим полям данных. Таким образом, вместо того, чтобы возвращать какой-либо объект таблицы системных данных, вы возвращаете список определенных вами пользовательских объектов.
Затем на вашем бизнес-уровне вы подключаетесь или предоставляете класс доступа к данным, от которого вы можете получить список пользователей (см. Внедрение зависимости). Вам не нужно знать, и вам все равно, откуда пришли данные. Список пользователей мог прийти из MySQL, простого файла или удаленного веб-сервиса. Вот почему разделение может быть хорошей вещью.
Некоторые из недостатков этого подхода заключаются в том, что приходится полагаться на сторонние средства отображения ORM (они ускоряют разработку), необходимость в классах перевода для межграничного взаимодействия, более тщательное планирование даже для самых мелких изменений. Однако последний пункт менее вероятен, если у вас есть CRUDS для каждой сущности. Твики будут нужны только при изменении атрибутов базовых данных.
Изменить: я забыл упомянуть, что функции Get/Update/Insert/Delete вашего пользовательского репозитория обычно доступны через API, подключенный к удаленному веб-сервису или что-то подобное.
Ваш слой доступа к данным содержит запросы, которые извлекают данные из источника данных. Эти запросы обычно находятся за каким-то интерфейсом репозитория, который позволяет другим уровням свободно взаимодействовать со слоем доступа к данным.
Ваш логический (бизнес-уровень) уровень содержит рабочие процессы, необходимые для выполнения операций, вызываемых уровнем представления. В многоуровневой архитектуре этот уровень не должен содержать необработанные запросы доступа к данным, но вместо этого он должен использовать уровень доступа к данным для запроса данных через интерфейс репозитория, о котором я упоминал выше. Я думаю, что это то, что пытается сказать это правило.