Comments 20
Ну, это решение в лоб, ничего вообще-то нового :)
Я делаю на клиенте так-же, а на сервере без каких-либо объектов простой switch($nameFunction) и вызовы фактических функций.
Я делаю на клиенте так-же, а на сервере без каких-либо объектов простой switch($nameFunction) и вызовы фактических функций.
Вот этот switch($nameFunction) — как раз и есть уровень конфигурации сервиса, который хочется упразднить.
Дописав новую функцию в сервис, ещё нужно не забыть внести изменения в switch.
Так что, это ещё вопрос, какое решение более лобовое).
Дописав новую функцию в сервис, ещё нужно не забыть внести изменения в switch.
Так что, это ещё вопрос, какое решение более лобовое).
Избавиться от этого switch очень просто.
Имеем вызов '?method=user.login&data=...'
Собираем входные параметры и смотрим method.
Сплит по точке — даст 2 имени.
Вызов всего этого добра:
modulesMap отдельно можно описать отдельно, даже подгружать json файл.
Имеем вызов '?method=user.login&data=...'
Собираем входные параметры и смотрим method.
Сплит по точке — даст 2 имени.
moduleName = splitted[0];methodName = splitted[1];Вызов всего этого добра:
modulesMap[moduleName][methodName](params, callback)modulesMap отдельно можно описать отдельно, даже подгружать json файл.
не туда
Простите, я наверное туплю, но никак не могу понять в чем разница в сравнении со стандартными подходами (spring mvc, jax rs)?
Если в двух словах — меньше кода.
Разве там много кода? ну, кроме нужной логики.
Продемонстрируйте свою реализацию, и тогда можно будет сравнить.
Что то вроде такого
@RequestMapping("/reports")
@Controller
public class ReportsController {
@RequestMapping(value = "execute", method = RequestMethod.GET)
@PreAuthorize("hasRole('REPORT_BUTTON')")
@ResponseBody
public Report executeReport(@RequestParam("reportId") Long reportId){
return reportsRepository.findOne(reportId);
}
}
В таком подходе, есть, как минимум, три недостатка:
1. Бизнес-логика реализована в контроллере, т.е.слои контроллеров и бизнес-логики — смешаны.
Почему это плохо:
До тех пор, пока мы вызываем смешанный с контроллером сервис каким-то одним способом,
например из браузерного скрипта, через ajax, это будет работать.
Но, как только мы захотим вызывать сервисные методы как api, из ява-клиента, например,
или заменить транспорт с http на вебсокеты, нам придётся переписать заново
все методы в смешанном слое.
В подходе предлагаемом мной, в этом случае, будет нужно внести изменения
всего в один класс — CommonServiceController, а вся бизнес-логика, вынесенная
в классы сервисов, останется абсолютно без изменений.
2. Предполагаю(поправьте, если ошибаюсь), что нет возможности передать в параметрах объект.
Т.е. получить объект репорт мы можем, а сохранить — нет.
3. Нет возможности передать код ошибки по отдельному каналу.
В случае, если метод бросит исключение, на клиенте получим статус ответа 400,
и сообщение переданное в конструкторе исключения.
Если использовать такое решение, то мы не сможем предупредить клиента,
о том что метод или сервис не найдены, или что роль пользователя не валидна для данного метода.
1. Бизнес-логика реализована в контроллере, т.е.слои контроллеров и бизнес-логики — смешаны.
Почему это плохо:
До тех пор, пока мы вызываем смешанный с контроллером сервис каким-то одним способом,
например из браузерного скрипта, через ajax, это будет работать.
Но, как только мы захотим вызывать сервисные методы как api, из ява-клиента, например,
или заменить транспорт с http на вебсокеты, нам придётся переписать заново
все методы в смешанном слое.
В подходе предлагаемом мной, в этом случае, будет нужно внести изменения
всего в один класс — CommonServiceController, а вся бизнес-логика, вынесенная
в классы сервисов, останется абсолютно без изменений.
2. Предполагаю(поправьте, если ошибаюсь), что нет возможности передать в параметрах объект.
Т.е. получить объект репорт мы можем, а сохранить — нет.
3. Нет возможности передать код ошибки по отдельному каналу.
В случае, если метод бросит исключение, на клиенте получим статус ответа 400,
и сообщение переданное в конструкторе исключения.
Если использовать такое решение, то мы не сможем предупредить клиента,
о том что метод или сервис не найдены, или что роль пользователя не валидна для данного метода.
Где должна быть реализована бизнес-логика? Что реализуют контроллеры?
Я уже мало помню о jax rs, поэтому буду говорить о спринге
1. Контроллеры находятся в spring контексте. Поэтому вызвать можно из любого места где он доступен.
2. Передать объект можно. Причем как json, так и автоматом замапить на какую нибудь сущность.
3. Вроде же можно вернуть статус ошибки вместе с сообщением, в которое можно всунуть код ошибки. Я на счет этого 100% не уверен, но могу поискать инфу.
1. Контроллеры находятся в spring контексте. Поэтому вызвать можно из любого места где он доступен.
2. Передать объект можно. Причем как json, так и автоматом замапить на какую нибудь сущность.
3. Вроде же можно вернуть статус ошибки вместе с сообщением, в которое можно всунуть код ошибки. Я на счет этого 100% не уверен, но могу поискать инфу.
Но в общем я вижу плюс, если есть большое желание отделить бизнес логику от контроллеров. На мой взгляд это может пригодиться только если требуется несколько разных внешних интерфейсов, если не хочется каждый из них описывать. У меня такой задачи пока не встречалось.
Вообще, эта статья — «подводящая», к статье об организации вебсокетного взаимодействия с сервером,
в которой преимущество отделения логики от контроллера будет очевидным, и без которого реализовать
такое взаимодействие — просто не получится.
в которой преимущество отделения логики от контроллера будет очевидным, и без которого реализовать
такое взаимодействие — просто не получится.
Код обновлён. Теперь, в сервисных методах можно указывать любое количество параметров,
любых типов (JSONObject в том числе), кроме массивов ( вместо массивов — нужно использовать списки).
Смотрите Update1 в конце статьи.
любых типов (JSONObject в том числе), кроме массивов ( вместо массивов — нужно использовать списки).
Смотрите Update1 в конце статьи.
Sign up to leave a comment.
Простой вызов удалённых сервисных методов в одностраничных приложениях