После GatewayAPI можно выделить слой «бизнес-сервисов» описывающих логику сущностей по примеру предложенных в статье, а за ними можно выделить слой микро-сервисов, реализующих конкретную задачу. Но это так, чисто для примера развития…
Так дело не в реанимации, люди и до сих пор пишут софт под него в том числе и игровой, хотя в основном демки конечно. Да и демо-пати до сих пор проводятся, этот конкурс скорее просто эдакий вариант демо-пати в котором принимают участие не демки а игры.
По поводу звука, попробуйте Covox ))
мне очень интересно, сколько можно выжать из данного проца в настоящее время, + ZX Evo/ZX Next/Pentagon дали большой толчок в эволюции ZX
логично что «документооборот» это сервис, который предоставляет «информационная система». И в пределах этого сервиса (или сразу нескольких сервисов), бизнес реализует свою проектную деятельность. Например проект «внедрение учёта рабочего времени», можете сами прикинуть сколько сервисов заденет при реализации.
Всё же «информационная система» это совокупность программных (внутренних и/или внешних сервисов) и физических средств (серверов, устройств,...) с помощью которых реализуются бизнес-проекты (наборы бизнес задач, группированные по тематике).
Как бы да, но я склонялся в ответе к тому, что MVC это всё же Presentation layer, а не Domain или Data source. Для простоты наверное в этом фрейме AR поселили в M…
Давай-те не будем путать алгоритм аутентификации и алгоритмом восстановления пароля. вещи таки разные (не смотря на то, что сделаны у многих рукожопо).
Владелец сайта при создании/внедрении алгоритма восстановления пароля должен учитывать что почта может быть взломана (привет «Секретные вопросы» например)
Вы не избавляетесь от пароля, вы перекладываете «сервис аутентификации» на сторонний ресурс (в статье это почта, некоторые еще используют sms). Из плюсов:
— Вы перекладываете написание/сопровождение аутентификатора на сторонний сервис
— Вашим пользователям не нужны пароли у них есть почта/sms
Из минусов:
— Для входа на ваш ресурс необходимо войти/проследовать в зависимый сервис
— В случае, если почта вашего клиента взломана, взломщик может проследовать во все привязанные ресурсы
Относительного последнего пункта есть оговорка, пользователь может для каждого аккаунта заводить отдельный ящик,…
но как бы проще тогда уже просто, регистрация с логином паролем и все счастливы…
Послесловие: я не считаю данный подход ущербным, но напоминаю что убирать пароль совсем, это тоже плохая идея, оставляйте хотя-бы на тот случай если у пользователя будет утерян доступ к почте/смс (забыл пароль/потерял телефон).
По поводу звука, попробуйте Covox ))
мне очень интересно, сколько можно выжать из данного проца в настоящее время, + ZX Evo/ZX Next/Pentagon дали большой толчок в эволюции ZX
А зачем её там вообще хранить?
Владелец сайта при создании/внедрении алгоритма восстановления пароля должен учитывать что почта может быть взломана (привет «Секретные вопросы» например)
— Вы перекладываете написание/сопровождение аутентификатора на сторонний сервис
— Вашим пользователям не нужны пароли у них есть почта/sms
Из минусов:
— Для входа на ваш ресурс необходимо войти/проследовать в зависимый сервис
— В случае, если почта вашего клиента взломана, взломщик может проследовать во все привязанные ресурсы
Относительного последнего пункта есть оговорка, пользователь может для каждого аккаунта заводить отдельный ящик,…
но как бы проще тогда уже просто, регистрация с логином паролем и все счастливы…
Послесловие: я не считаю данный подход ущербным, но напоминаю что убирать пароль совсем, это тоже плохая идея, оставляйте хотя-бы на тот случай если у пользователя будет утерян доступ к почте/смс (забыл пароль/потерял телефон).
Спасибо за внимание…