Здравствуй, Хабрасообщество. Пишу в личном блоге, так как этот топик является вопросом. Итак, совсем недавно я озаботился использованием вменяемых шаблонов проектирования в своих похапешных приложениях и мне встретился первый вопрос, который я не смог нагуглить.
Суть такова: допустим у нас есть доменные объекты «компания», «пользователь», «виртуальный файл», «виртуальная папка». Здесь более-менее все понятно — создаем фабрики, data mapper и хранилища. Но создатель файла может назначить права доступа к файлам для сотрудников, и тогда приходится делать проверку прав доступа. Первая мысль — передавать объект «Пользователь» в метод поиска хранилища, дабы этот метод провел проверку прав доступа, но по мне это выглядит варварством. Что если другая часть приложения захочет заполучить какой-то файл? Делать аргумент типа «Пользователь» необязательным?
Пересмотрел Фаулера, наткнулся на Service Layer. Он проксирует доступ клиентом к объектам домена. Но не сумел нагуглить ничего внятного.
Является ли акл частью бизнес-логики? Следует ли разграничивать акл и ему подобное от доменных объектов и их хранилищ?
Суть такова: допустим у нас есть доменные объекты «компания», «пользователь», «виртуальный файл», «виртуальная папка». Здесь более-менее все понятно — создаем фабрики, data mapper и хранилища. Но создатель файла может назначить права доступа к файлам для сотрудников, и тогда приходится делать проверку прав доступа. Первая мысль — передавать объект «Пользователь» в метод поиска хранилища, дабы этот метод провел проверку прав доступа, но по мне это выглядит варварством. Что если другая часть приложения захочет заполучить какой-то файл? Делать аргумент типа «Пользователь» необязательным?
Пересмотрел Фаулера, наткнулся на Service Layer. Он проксирует доступ клиентом к объектам домена. Но не сумел нагуглить ничего внятного.
Является ли акл частью бизнес-логики? Следует ли разграничивать акл и ему подобное от доменных объектов и их хранилищ?