Польза от трехуровневой структуры бизнесслоя
Сегодня до меня дошло, в чем выгода от нашей трехуровневой структуры бизнесслоя. Толковых разъяснений от коллег я либо не получил, либо не понял. Но вот сегодня сам обнаружил эту выгоду, про которую мне сказали "делай так, потом поймешь почему". Структура у нас собственно состоит из трех "слоев": менеджеры, контроллеры, мапперы.
Для каждого условного модуля программы создаются все три слоя. Слой мапперов содержит функции получающие информацию из базы и сохраняющие ее в классы-контейнеры, в которых преимущественно отсутствует всякая логика, т.е. в классе есть только поля. Условно выше маппера действует контроллер, который получает вызовом маппера объекты-контейнеры и из них образует более сложные объекты, которые уже должны быть готовы для передачи фронтенду. Однако, есть еще слой менеджеров, в котором объекты полученные в контроллере могут быть закешированы, либо может происходить проверка прав пользователя на получение объекта. Так вот для меня до сих пор оставалось загадкой, почему бы не поместить логику контроллера в менеджер и использовать тем самым двухуровневую структуру. С мапперами вроде все ясно. Польза маппера в том, что он является интерфейсом для одной хранимой процедуры. Затем комбинации таких интерфейсов можно использовать для сборки различных объектов. А вот польза от выделения контроллера от меня как-то тупо ускользала. Однако, теперь мне все кажется весьма просто. Польза от выделения контроллера как раз в отделении кеширования и проверки прав доступа. Дело в том, что если мне в новом методе менеджера понадобится получить объект, который можно получить другим уже готовым методом менеджера, то может возникнуть ситуация, когда нужна другая проверка прав, либо отсутствие кеширования. И обойти в этом случае уже существующую проверку прав в уже готовом методе менеджера можно выделением всей его логики, не связанной с проверкой прав, в контроллер. И вызывать уже соответственно один контроллер в двух методах менеджера с разными проверками и разным кешированием. Все.
П.С.: Однако, хочется заметить, что выделить логику менеджера в контроллер можно и после ее создания в менеджере. Так что можно этот рефракториг и отложить, чтобы не усложнять себе сразу задачу.
Для каждого условного модуля программы создаются все три слоя. Слой мапперов содержит функции получающие информацию из базы и сохраняющие ее в классы-контейнеры, в которых преимущественно отсутствует всякая логика, т.е. в классе есть только поля. Условно выше маппера действует контроллер, который получает вызовом маппера объекты-контейнеры и из них образует более сложные объекты, которые уже должны быть готовы для передачи фронтенду. Однако, есть еще слой менеджеров, в котором объекты полученные в контроллере могут быть закешированы, либо может происходить проверка прав пользователя на получение объекта. Так вот для меня до сих пор оставалось загадкой, почему бы не поместить логику контроллера в менеджер и использовать тем самым двухуровневую структуру. С мапперами вроде все ясно. Польза маппера в том, что он является интерфейсом для одной хранимой процедуры. Затем комбинации таких интерфейсов можно использовать для сборки различных объектов. А вот польза от выделения контроллера от меня как-то тупо ускользала. Однако, теперь мне все кажется весьма просто. Польза от выделения контроллера как раз в отделении кеширования и проверки прав доступа. Дело в том, что если мне в новом методе менеджера понадобится получить объект, который можно получить другим уже готовым методом менеджера, то может возникнуть ситуация, когда нужна другая проверка прав, либо отсутствие кеширования. И обойти в этом случае уже существующую проверку прав в уже готовом методе менеджера можно выделением всей его логики, не связанной с проверкой прав, в контроллер. И вызывать уже соответственно один контроллер в двух методах менеджера с разными проверками и разным кешированием. Все.
П.С.: Однако, хочется заметить, что выделить логику менеджера в контроллер можно и после ее создания в менеджере. Так что можно этот рефракториг и отложить, чтобы не усложнять себе сразу задачу.
