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

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

S>Если мне вдруг приезжает массив, где у каких-то объектов нет senderName, то это нарушает приведённую здесь спецификацию типа.

охо-хо, ну-ну. спецификацию типа

S>Можно, конечно, принудительно приписать вопросики ко всем свойствам этого интерфейса, и написать обработку в приложении на каждый такой случай, но это, скажем так, непрактично.

это, скажем так, реальность

S>А вот если мне приезжает массив, в котором не 100, а 10, или 0 элементов, инвариант сохранён. Я в любом случае не ожидаю, что мне вернётся ровно 100 элементов.

какая-то чушь

КЛ>>ну у нас так же, в чем поинт?
S>Не знаю, как "у вас", а у исходного оппонента, судя по всему, в JSON будет список не ссылок, а объектов, причём состав объектов произвольно зависит не от самих объектов или аргументов запроса, а от наличия в токене тех или иных пермиссий.

аа, понял. конечно будет список объектов с ссылками, который зависит от аргументов запроса и от наличия в токене тех или иных пермиссий (только не обязательно в токене , можно же и без jwt а в базе посмотреть или что-то иное).

кому нужен пустой список только с ссылками? на вебе его не покажешь. будут легкие объекты и ссылки если надо взять конкретный полный.

КЛ>>смешно
S>А вы всегда проектируете безопасность на основании описаний вроде "у нас есть пять типов отчётов, один из них внутренний, другой внешний". Вам сразу всё понятно, и можно бежать нарезать таблички в базе?

а вы всегда бегаете по форумам с заявлениями (цитирую) "Во-первых, в моём случае этого не надо, т.к. я против самой идеи разделять доступ "по-объектно"".
То есть вы проектируете так — "знаете, я выяснил требования и учел вероятные будущие изменения и я против".

S>Я раньше и сам выяснял подробности проекта на основании телепатии и ясновидения, но лет 15 тому мне их за неуплату отключили, поэтому я предпочитаю проектировать на основании установленных фактов, а также вероятных будущих изменений.

какой-то бред

КЛ>>да не, по сути он дает тебе query language к базе
S>По сути там вообще может не быть никакой базы.

а по факту в 99 случаев она там есть

КЛ>>отвечай!
S>Зависимость от контекста называется "модальностью" и является одним из признаков плохого проектирования. Такой зависимости нужно по возможности избегать.

то, что ту тут пишешь умные термины из преподавательской жизни лучше не делает. вернись в реальность

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

мне кажется я начинаю понимать, откуда такой казеный язык и нажим на систему типов — многолетнее преподавание и .net?

S>Успешная факторизация позволяет нам перейти от K*M тестов к K+M тестам. Всё.

ага, а на практике "я против самой идеи разделять доступ "по-объектно"", "недостаточно данных для проектирования", "проверим пермиссии в контроллере", "по таблице на инвойс".

КЛ>>ну начинается! отлыниваешь )
S>Если вы хотите конструктивного обсуждения, можно попытаться взять какую-нибудь практическую задачу и посмотреть, как её решать в стиле REST — как с помощью микросервисов, так и без оных.


мне неинтересны микросервисы. я тебе в другой ветке дал юзкейс, ты отказался по нему что-то комментировать


S>Можно попытаться понять, ради чего вообще может в голову прийти "выставлять наружу псевдо-бд", и как это делать правильно, и чем это отличается от неправильного решения.


да мне это все неинтересно, потмому что в 99 случаев я против выставления хоть правильно, хоть неправильно. да и в "правильно" я не верю
jfyi