Здравствуйте, Cyberax, Вы писали:

C>Ну вот пусть эти блокировки будут в отдельной таблице, хотя бы. Которая просто недоступна через обычный REST, аналогично с паролями. Ну а номера карт вообще должны быть в отдельной БД по правилам PCIDSS.
Я не знаю последних веяний, но раньше требовалось только шифрование. Самое главное, что оно абсолютно бесполезно по факту. Мне на сайте это тоже в шифрованном виде вводить? Какая тайна из номера карты? Это был и есть полным дибилизмом, и мне даже удивительно от тебя слышать аппеляции к PCIDSS, ведь ты человек достаточно опытен и критически мыслящий. Хотя я на это смотрю по старой памяти через призму попытки применения к не-визе этого гадкого набора рекомендаций.

Здравствуйте, Stalker., Вы писали:

Вы начали с DTO, а закончили конечными контрактами конечных сервисов/API. Имхо, именно поэтому DTO и не нужен, т.к. каждый слой, который имеет внешний/публичнвый контракт — это не DTO, а осмысленные структуры (должны быть).

PS:
Меня лично парят префиксы и суффиксы в именах, и меня парит то, что когда они есть — они пролазят везде. Более смышленные девелоперы не уподобляются хомякам, и не делают этих суффиксов/префиксов — но все равно их лепят, и пролазит это везде во всех реинкарнациях.
Если речь о слоеной вверх/низходящей архитектуре то там по определению тока контракты. Какие DTO? Что этими DTO делать? Гвозди забивать?
Если приложение простое, то можно ограничится одним наборов объектов, моделирующих ПО, но, банально расшарить транзацкию у которой есть юзерский комментарий — это уже вызовет кучу проблем.
Как вы не называйте объекты — они появляются исходя из выполняемых операций в системе. Платежная транзакция кстати очень хороший пример — ее ID в процессинге всегда не равен в клиент-банке, и выполняемые действия разные.
А ее уникальность на стороне процессинга... ну. Не такая.
Самое главное, что все отлично ложится на любые задачи, если не пытаться изобретать то, что не нужно. Нужно именно DTO — юзайте. Не нужно? Не юзайте.

Здравствуйте, Stalker., Вы писали:

G>>Это наверное зависит от инструмента. В ASP.NET можно одним атрибутом сказать что можно мапить, а что нельзя. Это гораздо проще, чем создавать DTO, которое потом еще и валидировать надо отдельно.
S>маппить поле блокировки можно (и нужно), но только для админа

Маппить ничего не надо. Код сервиса или имеет право выполняться или нет. Аутентификация с помощью xxx это не все. Ещё нужно делать *авторизацию*, которая глагол. И это работа никак ни для REST-фасада.

Здравствуйте, Mystic Artifact, Вы писали:

C>>Ну вот пусть эти блокировки будут в отдельной таблице, хотя бы. Которая просто недоступна через обычный REST, аналогично с паролями. Ну а номера карт вообще должны быть в отдельной БД по правилам PCIDSS.
MA> Я не знаю последних веяний, но раньше требовалось только шифрование. Самое главное, что оно абсолютно бесполезно по факту. Мне на сайте это тоже в шифрованном виде вводить?
На сайте можно показывать только последние 4 цифры и первые 2. Целиком номер выводить нельзя. Вообще нигде ("rendered unobservable"). Т.е. ни в логах, ни в отладчике, ни в дампах БД.

MA> Какая тайна из номера карты?
Возможность украсть с неё деньги. А так да, ничего.

Здравствуйте, Stalker., Вы писали:

C>>Если их располагать всё в одном объекте, то при одной ошибке будем иметь очередной пресс-релиз: "Компания Рога&Копыта утекла данные 100500 пользователей из-за хакерской атаки".
S>номера карточек должны быть зашифрованы, а не вынесены в отдельную базу
В теории это возможно, но на практике крайне сложно, так как PCIDSS требует "need to know" уровень доступа и запрещает совмещать данные серверы уровней защиты.

C>>4. Хм. А почему бы тогда и не выделить SensitiveUserData в отдельный объект?
S>и это называется "нехрупкий" подход?
Да. Всё очень просто и понятно — чувствительные объекты сразу видны, API легко выделяется и может специально мониториться (например, ставим alert на количество прочитанных объектов в секунду/за запрос).

S>Есть миллион разных вариантов того кто, что и при каких обстоятельствах может править, они еще и меняться могут по ходу работы в виде добавления новых ролей и прочего, заложить это в структуре базы просто недостижимо
Могут. Потому надо делать всё как можно проще, чтобы в случае необходимости можно было легко переписать. И как только требования появятся — смотреть что лучшее для них подходит, а не пессимизировать заранее.

И вариант с отдельным API для чувствительных данных — самый простой из тех, которые я знаю.

C>>Зачем? Пусть REST-сервис сразу проверяет на нужный формат (7343456787). Frontend'у никто не мешает телефон отформатировать заранее — он и так это обязан будет делать хотя бы для отображения, так как перевод "7343456787" в "+7 (343) 456 987" кто-то должен делать.
S>тогда знание о валидации и нормализации бизнес обьектов тонким слоем расползется по всем клиентам плюс будет продублировано в бизнес логике.
В REST-слое только валидация. Но она будет и в frontend'е. Тут как раз пример того, что проще всего разделять модель между фронтэндом и backend'ом.

REST тут как раз помогает — для того же Swagger'а можно достаточно богатую валидацию запихать в схему API.

C>>Аутентификация — это как раз один из примеров, где REST-интерфейс один фиг не подходит.
S>авторизация, не аутентификация. И делается она именно что в REST интерфейсе, а никак не в бизнес логике
Авторизация может делаться вообще везде. В том числе и в БЛ. Которым, кстати, может быть и REST-интерфейс напрямую.

Здравствуйте, Cyberax, Вы писали:

S>>номера карточек должны быть зашифрованы, а не вынесены в отдельную базу
C>В теории это возможно, но на практике крайне сложно, так как PCIDSS требует "need to know" уровень доступа и запрещает совмещать данные серверы уровней защиты.

не понятно что именно сложно, шифрование? Шифрование в любом случае требуется, а отдельная база никак на безопасность не повлияет (юзеры находятся в отдельной базе по другим соображениям т.к. ихний аутентификационный сервис это просто отдельный сервер)

Здравствуйте, Stalker., Вы писали:

S>>>номера карточек должны быть зашифрованы, а не вынесены в отдельную базу
C>>В теории это возможно, но на практике крайне сложно, так как PCIDSS требует "need to know" уровень доступа и запрещает совмещать данные серверы уровней защиты.
S>не понятно что именно сложно, шифрование?
Даже зашифрованные карты нельзя просто так складировать.

Но проблема в другом. Даже при шифровании ключ для расшифровки будет в сервере приложений или веб-сервере. Иначе сервер не сможет использовать эти данные, однако. Это само по себе уже может быть нарушением запрета на множественные роли. Но ещё и у любого инженера, имеющего доступ к серверу, будет возможность данные расшифровать.

PCIDSS требует ограничивать такой доступ до "need to know". Так что реально получается необходимость внешней базы/сервиса.

Здравствуйте, Cyberax, Вы писали:

C>Даже зашифрованные карты нельзя просто так складировать.

C>Но проблема в другом. Даже при шифровании ключ для расшифровки будет в сервере приложений или веб-сервере. Иначе сервер не сможет использовать эти данные, однако. Это само по себе уже может быть нарушением запрета на множественные роли. Но ещё и у любого инженера, имеющего доступ к серверу, будет возможность данные расшифровать.

C>PCIDSS требует ограничивать такой доступ до "need to know". Так что реально получается необходимость внешней базы/сервиса.

первый раз слышу что шифрованные карты нельзя складировать, а что с ними еще сделать-то нужно?
Шифрование в базе данных сейчас легко автоматизируется, на sql server просто включается always encrypted для требуемых полей и дб сервер сам рулит шифрованием, для клиентских систем это все прозрачно (за исключением невозможности юзать конструкции типа like). Ключ шифрования складывается в key vault, доступ только у приложений, никакие инженеры или дб админы ничего не расшифруют т.к. доступа к ключу нет

Но даже в твоем примере просто вынос куда-то (причем все равно непонятно чего — самих шифрованных номеров что-ли?) в другую базу никаких дополнительных бенефиров не даст — на другом сервере будут точно такие-же проблемы

Здравствуйте, Stalker., Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Это наверное зависит от инструмента. В ASP.NET можно одним атрибутом сказать что можно мапить, а что нельзя. Это гораздо проще, чем создавать DTO, которое потом еще и валидировать надо отдельно.
S>маппить поле блокировки можно (и нужно), но только для админа
Это проблема?
В конце концов можно вручную вызвать мапинг формы на модель, для этого в asp.net mvc есть TryUpdateModel(Async)
В любом случае создание DTO только для мапинга выглядит сегодня как плохая шуктка.

Здравствуйте, Stalker., Вы писали:

S>не понятно что именно сложно, шифрование? Шифрование в любом случае требуется, а отдельная база никак на безопасность не повлияет (юзеры находятся в отдельной базе по другим соображениям т.к. ихний аутентификационный сервис это просто отдельный сервер)

А вот вопрос про отдельную бд -- в микросервисной парадигме у нас изоляция по хранилищу -- 1 сервис, 1 база. И вот мне в некоем сервисе надо сохранить какие-то данные для пользователя,
я просто сохраню id пользователя полученный из другой базы? Т.е. один сервис\база отвечает за сущ. А, второй за сущ. B, соотв. инф-ия в сервисе B о сущ. А будет храниться
как некий, не факт что валидный, идентификатор? Т.е. fk constraints у нас при микросервисах идут лесом?

Здравствуйте, Ikemefula, Вы писали:

I>Когда и чем плохи DTO ?
If you regularly copy to/from DTO<=>DbEntity and the set of fields is pretty much the same in both models, then you're doing something wrong.

Здравствуйте, gandjustas, Вы писали:

G>Это проблема?
G>В конце концов можно вручную вызвать мапинг формы на модель, для этого в asp.net mvc есть TryUpdateModel(Async)
G>В любом случае создание DTO только для мапинга выглядит сегодня как плохая шуктка.
не проблема, но DTO это-ж не только маппинг

Здравствуйте, Sharov, Вы писали:

S>А вот вопрос про отдельную бд -- в микросервисной парадигме у нас изоляция по хранилищу -- 1 сервис, 1 база. И вот мне в некоем сервисе надо сохранить какие-то данные для пользователя,
S>я просто сохраню id пользователя полученный из другой базы? Т.е. один сервис\база отвечает за сущ. А, второй за сущ. B, соотв. инф-ия в сервисе B о сущ. А будет храниться
S>как некий, не факт что валидный, идентификатор? Т.е. fk constraints у нас при микросервисах идут лесом?

в микросервисах будет eventual consistency т.е. да, fk constraints, а заодно и классические транзакции действительно идут лесом. У майкрософа есть очень хорошая бесплатная книжка про имплементацию микросервисов под Azure, там все концепции и подходы описаны очень хорошо
Но в данном примере пользователи будут в другой дб и без всяких микросервисов, особенно в облаках, типа Azue, где хранилища пользователей уже есть (b2c) и писать свой велосипед нет смысла, а главное не надежно

Здравствуйте, Stalker., Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Это проблема?
G>>В конце концов можно вручную вызвать мапинг формы на модель, для этого в asp.net mvc есть TryUpdateModel(Async)
G>>В любом случае создание DTO только для мапинга выглядит сегодня как плохая шуктка.
S>не проблема, но DTO это-ж не только маппинг
А что еще?

Здравствуйте, gandjustas, Вы писали:

G>А что еще?
то, про что тут уже писали — чистка/валидация данных, отвязка от структуры бизнес обьектов, аггрегированные данные отправляемые на клиента и прочее.

Здравствуйте, alexanderfedin, Вы писали:

I>>Когда и чем плохи DTO ?
A>If you regularly copy to/from DTO<=>DbEntity and the set of fields is pretty much the same in both models, then you're doing something wrong.

Подробнее — когда и чем wrong, какие проблемы и тд ?

Здравствуйте, Stalker., Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>А что еще?
S>то, про что тут уже писали —
S>- чистка/валидация данных
Простите, я по привычке валидацию входных данных и мапинг считаю одним действием. В любом случае для валидации DTO не сильно нужны.
Если мы говорим об инвариантах, то тут надо запросы в базу делать, не DTO.

S> — отвязка от структуры бизнес объектов
А зачем эта отвязка нужна? Наоборот удобнее когда приложение по-максимуму оперирует бизнес-объектами, вся идея DDD на этом построена.


S> — аггрегированные данные отправляемые на клиента и прочее.
Тут согласен, отдельные классы для viewmodel это хорошо и, зачастую полезно. Но они формируются только в слое представления и не участвуют в БЛ вообще.
REST API я бы еще и OData делал, чтобы клиент сам определял что ему надо тянуть.

Здравствуйте, BlackEric, Вы писали:

BE>Книга Фаулера, как по мне, уже местами устарела. Там нет ничего про мобильные клиенты и выбора xml vs json как минимум. Есть ли что-нибудь по-новее?

А что ты хочешь прочитать, интересно, про выбор xml vs json? XML ужасен, тошнотворен и переусложнен, json просто тошнотворен. По-моему, выбор очевиден

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Stalker., Вы писали:

S>>не понятно что именно сложно, шифрование? Шифрование в любом случае требуется, а отдельная база никак на безопасность не повлияет (юзеры находятся в отдельной базе по другим соображениям т.к. ихний аутентификационный сервис это просто отдельный сервер)

S>А вот вопрос про отдельную бд -- в микросервисной парадигме у нас изоляция по хранилищу -- 1 сервис, 1 база. И вот мне в некоем сервисе надо сохранить какие-то данные для пользователя,
S>я просто сохраню id пользователя полученный из другой базы? Т.е. один сервис\база отвечает за сущ. А, второй за сущ. B, соотв. инф-ия в сервисе B о сущ. А будет храниться
S>как некий, не факт что валидный, идентификатор? Т.е. fk constraints у нас при микросервисах идут лесом?


Какие ид-шники? сыдка на чужой datasource это плевок в священные идеалы микросервисной архитектуры
микросервисы должны быть полностью независимы — у каждого своя модель и свой датасорс. В терминах DDD — BoundedContext.
В итоге в интернет маеазине UserProfile microservice user и Order microservice user теперь живут отдельно и бользще транзакционно не апдейтятся. Теперь при попытке забанить юзера надо в одном сервисе банить а в другой бросать integration message который может обработается а может нет.

А еще там join-ы очень прикольно делать между сущностями в разных сервисах. Для reporting-a например

Одним словом — микросервисная архитектура — это психическое расстройство

Здравствуйте, BlackEric, Вы писали:

BE>Книга Фаулера, как по мне, уже местами устарела. Там нет ничего про мобильные клиенты и выбора xml vs json как минимум. Есть ли что-нибудь по-новее?


Дарагие ученые! В вашем учебнике по матанализу нечего не рассказываеца как считать лайки. Ни магли бы вы абнавить учебник Фихтенгольца по мат анализу и включит туда главу про лайки?