Сообщение Re[11]: Фаулер. Архитектура от 30.07.2019 16:35
Изменено 30.07.2019 17:25 Cyberax
Re[11]: Фаулер. Архитектура
Здравствуйте, Stalker., Вы писали:
C>>И вот не надо так делать, по возможности. Очень это хрупко.
S>везде так делается, блокировка пользователя/карт/счетов, пароли и масса всего другого. Нет в этом ничего хрупкого, все как раз наоборот, по другому собственно и не получится, уровни доступа и сами данные это разные вещи
Ну вот пусть эти блокировки будут в отдельной таблице, хотя бы. Которая просто недоступна через обычный REST, аналогично с паролями. Ну а номера карт вообще должны быть в отдельной БД по правилам PCIDSS.
Если их располагать всё в одном объекте, то при одной ошибке будем иметь очередной пресс-релиз: "Компания Рога&Копыта утекла данные 100500 пользователей из-за хакерской атаки".
C>>Вот как раз единая валидация для бизнес-логики и REST-интерфейса — это залог умственного здоровья при сопровождении. Если у объекта есть какой-то инвариант, то что мешает его проверять одинаково везде?
S>то, что фильтрация мусора и нормализация ввода не имеет отношения к бизнес логике, номер телефона +7 (343) 456 987, так-же как и 7343 45 69 87 допустимы на входе в сервис
Зачем? Пусть REST-сервис сразу проверяет на нужный формат (7343456787). Frontend'у никто не мешает телефон отформатировать заранее — он и так это обязан будет делать хотя бы для отображения, так как перевод "7343456787" в "+7 (343) 456 987" кто-то должен делать.
Если нормализацию делать ещё и в REST-слое, то будем иметь мёртвый код, который не будет использоваться и будет бомбой замедленного действия.
S>но в бизнес-логику и базу пойдет 7343456787 с ограничением на длину и допустимые символы. То-же самое с авторизацией, ну не может пользователь сам себя разблокировать или сбросить пароль, к формату хранения авторизация не может иметь отношения
Аутентификация — это как раз один из примеров, где REST-интерфейс один фиг не подходит.
C>>И вот не надо так делать, по возможности. Очень это хрупко.
S>везде так делается, блокировка пользователя/карт/счетов, пароли и масса всего другого. Нет в этом ничего хрупкого, все как раз наоборот, по другому собственно и не получится, уровни доступа и сами данные это разные вещи
Ну вот пусть эти блокировки будут в отдельной таблице, хотя бы. Которая просто недоступна через обычный REST, аналогично с паролями. Ну а номера карт вообще должны быть в отдельной БД по правилам PCIDSS.
Если их располагать всё в одном объекте, то при одной ошибке будем иметь очередной пресс-релиз: "Компания Рога&Копыта утекла данные 100500 пользователей из-за хакерской атаки".
C>>Вот как раз единая валидация для бизнес-логики и REST-интерфейса — это залог умственного здоровья при сопровождении. Если у объекта есть какой-то инвариант, то что мешает его проверять одинаково везде?
S>то, что фильтрация мусора и нормализация ввода не имеет отношения к бизнес логике, номер телефона +7 (343) 456 987, так-же как и 7343 45 69 87 допустимы на входе в сервис
Зачем? Пусть REST-сервис сразу проверяет на нужный формат (7343456787). Frontend'у никто не мешает телефон отформатировать заранее — он и так это обязан будет делать хотя бы для отображения, так как перевод "7343456787" в "+7 (343) 456 987" кто-то должен делать.
Если нормализацию делать ещё и в REST-слое, то будем иметь мёртвый код, который не будет использоваться и будет бомбой замедленного действия.
S>но в бизнес-логику и базу пойдет 7343456787 с ограничением на длину и допустимые символы. То-же самое с авторизацией, ну не может пользователь сам себя разблокировать или сбросить пароль, к формату хранения авторизация не может иметь отношения
Аутентификация — это как раз один из примеров, где REST-интерфейс один фиг не подходит.
Re[11]: Фаулер. Архитектура
Здравствуйте, Stalker., Вы писали:
C>>И вот не надо так делать, по возможности. Очень это хрупко.
S>везде так делается, блокировка пользователя/карт/счетов, пароли и масса всего другого. Нет в этом ничего хрупкого, все как раз наоборот, по другому собственно и не получится, уровни доступа и сами данные это разные вещи
Ну вот пусть эти блокировки будут в отдельной таблице, хотя бы. Которая просто недоступна через обычный REST, аналогично с паролями. Ну а номера карт вообще должны быть в отдельной БД по правилам PCIDSS.
Если их располагать всё в одном объекте, то при одной ошибке будем иметь очередной пресс-релиз: "Компания Рога&Копыта утекла данные 100500 пользователей из-за хакерской атаки".
Ну и цепочка размышлений такая:
1. Если делать интерфейс типа "setUserData(UserDTO userData)", то надо проверять, что только администратор может редактировать определённые поля.
2. Но это очень плохо, так как слишком хрупко и неудобно.
3. Почему бы тогда не выделить отдельный метод "setSensitiveUserData(SensitiveUserDTO userData)", который будет доступен только администраторам?
4. Хм. А почему бы тогда и не выделить SensitiveUserData в отдельный объект?
C>>Вот как раз единая валидация для бизнес-логики и REST-интерфейса — это залог умственного здоровья при сопровождении. Если у объекта есть какой-то инвариант, то что мешает его проверять одинаково везде?
S>то, что фильтрация мусора и нормализация ввода не имеет отношения к бизнес логике, номер телефона +7 (343) 456 987, так-же как и 7343 45 69 87 допустимы на входе в сервис
Зачем? Пусть REST-сервис сразу проверяет на нужный формат (7343456787). Frontend'у никто не мешает телефон отформатировать заранее — он и так это обязан будет делать хотя бы для отображения, так как перевод "7343456787" в "+7 (343) 456 987" кто-то должен делать.
Если нормализацию делать ещё и в REST-слое, то будем иметь мёртвый код, который не будет использоваться и будет бомбой замедленного действия.
S>но в бизнес-логику и базу пойдет 7343456787 с ограничением на длину и допустимые символы. То-же самое с авторизацией, ну не может пользователь сам себя разблокировать или сбросить пароль, к формату хранения авторизация не может иметь отношения
Аутентификация — это как раз один из примеров, где REST-интерфейс один фиг не подходит.
C>>И вот не надо так делать, по возможности. Очень это хрупко.
S>везде так делается, блокировка пользователя/карт/счетов, пароли и масса всего другого. Нет в этом ничего хрупкого, все как раз наоборот, по другому собственно и не получится, уровни доступа и сами данные это разные вещи
Ну вот пусть эти блокировки будут в отдельной таблице, хотя бы. Которая просто недоступна через обычный REST, аналогично с паролями. Ну а номера карт вообще должны быть в отдельной БД по правилам PCIDSS.
Если их располагать всё в одном объекте, то при одной ошибке будем иметь очередной пресс-релиз: "Компания Рога&Копыта утекла данные 100500 пользователей из-за хакерской атаки".
Ну и цепочка размышлений такая:
1. Если делать интерфейс типа "setUserData(UserDTO userData)", то надо проверять, что только администратор может редактировать определённые поля.
2. Но это очень плохо, так как слишком хрупко и неудобно.
3. Почему бы тогда не выделить отдельный метод "setSensitiveUserData(SensitiveUserDTO userData)", который будет доступен только администраторам?
4. Хм. А почему бы тогда и не выделить SensitiveUserData в отдельный объект?
C>>Вот как раз единая валидация для бизнес-логики и REST-интерфейса — это залог умственного здоровья при сопровождении. Если у объекта есть какой-то инвариант, то что мешает его проверять одинаково везде?
S>то, что фильтрация мусора и нормализация ввода не имеет отношения к бизнес логике, номер телефона +7 (343) 456 987, так-же как и 7343 45 69 87 допустимы на входе в сервис
Зачем? Пусть REST-сервис сразу проверяет на нужный формат (7343456787). Frontend'у никто не мешает телефон отформатировать заранее — он и так это обязан будет делать хотя бы для отображения, так как перевод "7343456787" в "+7 (343) 456 987" кто-то должен делать.
Если нормализацию делать ещё и в REST-слое, то будем иметь мёртвый код, который не будет использоваться и будет бомбой замедленного действия.
S>но в бизнес-логику и базу пойдет 7343456787 с ограничением на длину и допустимые символы. То-же самое с авторизацией, ну не может пользователь сам себя разблокировать или сбросить пароль, к формату хранения авторизация не может иметь отношения
Аутентификация — это как раз один из примеров, где REST-интерфейс один фиг не подходит.