Всем привет. Несколько месяцев назад меня мучил вопрос о том, как правильно спроектировать свое приложение, чтобы потом не было противно смотреть в свой код. Тогда я решил покопаться в этом вопросе и после целого дня поиска я всё осознал. Решил наконец, поделиться своими знаниями, возможно они помогут кому-то, а может и нет. В общем читайте.
• Слой доступа к данным или DAL
Получает или изменяет данные напрямую из БД или посредством ORM. Данные фильтруются, но никак не обрабатываются. Также возможно получение данных из других источников, например через парсинг страниц.
• Бизнес слой или BLL
Работает с данными посредством DAL. Данные обрабатываются и приводятся к нужному виду. Это самый интересный слой. Здесь происходит вся логика приложения.
• Слой сервисов или SL
Этот слой встречается только в крупных приложениях. По сути это API интерфейс для доступа к приложению с других приложений. Этот слой не будет описываться, из-за моей крайней неосведомленности в этой области.
• Слой представления или PL
Собственно слой представления данных. Перерабатывает данные из BLL в нужные для представления сущности.
Как мы уже знаем — слой представления используется для преобразования данных, в формат необходимый для отображения. Приложение с одинаковой логикой может иметь разные форматы. Обычный софт, то есть оконное приложение, имеет другие классы, для отображения, чем веб или консольный проект. Для каждого вида приложения должен быть пакет классов из PL. В случае MVC проекта, это набор контроллеров. В веб проектах контроллеры также имеют право управлять маршрутизацией, хотя на первый взгляд это может показаться логикой ненадлежащей для контроллеров, в BLL слой это помещать недопустимо.
Бизнес слой нужен для сокрытия всей бизнес логики текущего приложения, причем, как платформа приложения может быть любого вида, так и данные приложения могут быть с любого источника. Этот слой преобразует логически связанные сущности в одну концепцию. Допустим, есть задача сделать форум и нужно вывести все сообщения пользователя в его кабинете, причем неважно ответ это или тема. Эти сущности преобразовываются в сущность сообщение. Преобразование сущностей БД в логические сущности приложения – это одна из главных обязанностей бизнес слоя.
DAL слой это слой выборок из БД, XML файлов, API сервисов и пр. Для каждого источника данных компании должна быть отдельная библиотека DAL слоя, но чаще всего в роли источника выступает только БД.
Все вышеизложенное помогает в первую очередь для крупных проектов, которые могут иметь разные режимы представлений, разные источники данных и разные приложения с общими данными. И обычному разработчику может показаться излишеством, ведь ему нужно написать небольшую программу, под одну платформу с малым объемом данных, но это только так кажется. На самом деле, разделение на слои дает огромные преимущества почти любому проекту. Главные плюсы: код выглядит красиво, читаемо, не перепутываются концепции и его легко расширять. Облегчается рефакторинг, что очень важно для красивого приложения. Пренебрегать этими правилами можно только в маленьких проектах и то, если не предполагается дальнейшее улучшение.
Кажется всё. Если что-то непонятно или неправильно изложено, пишите в комментариях, постараюсь исправить. Спасибо за внимание.
Всякие аббревиатурки
• Слой доступа к данным или DAL
Получает или изменяет данные напрямую из БД или посредством ORM. Данные фильтруются, но никак не обрабатываются. Также возможно получение данных из других источников, например через парсинг страниц.
• Бизнес слой или BLL
Работает с данными посредством DAL. Данные обрабатываются и приводятся к нужному виду. Это самый интересный слой. Здесь происходит вся логика приложения.
• Слой сервисов или SL
Этот слой встречается только в крупных приложениях. По сути это API интерфейс для доступа к приложению с других приложений. Этот слой не будет описываться, из-за моей крайней неосведомленности в этой области.
• Слой представления или PL
Собственно слой представления данных. Перерабатывает данные из BLL в нужные для представления сущности.
Подробный разбор
Как мы уже знаем — слой представления используется для преобразования данных, в формат необходимый для отображения. Приложение с одинаковой логикой может иметь разные форматы. Обычный софт, то есть оконное приложение, имеет другие классы, для отображения, чем веб или консольный проект. Для каждого вида приложения должен быть пакет классов из PL. В случае MVC проекта, это набор контроллеров. В веб проектах контроллеры также имеют право управлять маршрутизацией, хотя на первый взгляд это может показаться логикой ненадлежащей для контроллеров, в BLL слой это помещать недопустимо.
Бизнес слой нужен для сокрытия всей бизнес логики текущего приложения, причем, как платформа приложения может быть любого вида, так и данные приложения могут быть с любого источника. Этот слой преобразует логически связанные сущности в одну концепцию. Допустим, есть задача сделать форум и нужно вывести все сообщения пользователя в его кабинете, причем неважно ответ это или тема. Эти сущности преобразовываются в сущность сообщение. Преобразование сущностей БД в логические сущности приложения – это одна из главных обязанностей бизнес слоя.
DAL слой это слой выборок из БД, XML файлов, API сервисов и пр. Для каждого источника данных компании должна быть отдельная библиотека DAL слоя, но чаще всего в роли источника выступает только БД.
Все вышеизложенное помогает в первую очередь для крупных проектов, которые могут иметь разные режимы представлений, разные источники данных и разные приложения с общими данными. И обычному разработчику может показаться излишеством, ведь ему нужно написать небольшую программу, под одну платформу с малым объемом данных, но это только так кажется. На самом деле, разделение на слои дает огромные преимущества почти любому проекту. Главные плюсы: код выглядит красиво, читаемо, не перепутываются концепции и его легко расширять. Облегчается рефакторинг, что очень важно для красивого приложения. Пренебрегать этими правилами можно только в маленьких проектах и то, если не предполагается дальнейшее улучшение.
Кажется всё. Если что-то непонятно или неправильно изложено, пишите в комментариях, постараюсь исправить. Спасибо за внимание.
