YN
о, уже мнения разделились
Size: a a a
2020 April 12
DB
типа того, может ещё какую-то инфу
Ну так был же нормальный класс Creds, который ничего, кроме логина и пароля не нёс в себе.
YN
отлично, так зачем тогда флаг IsAuthenticated нужен?
DB
Используй функцию reply, чтобы было понятно, что именно "нет".
DB
отлично, так зачем тогда флаг IsAuthenticated нужен?
После того, как ушли от Creds появился.
Ладно, я понял, откатимся сейчас.
Ладно, я понял, откатимся сейчас.
YN
Ну, сегодня надо проверять права.
Завтра - делать раскраску, в зависимости от наличия роли.
Какая разница?
Завтра - делать раскраску, в зависимости от наличия роли.
Какая разница?
это как в алисе в стране чудес:
— Скажите, пожалуйста, куда мне отсюда идти?
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.
— только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долго идти.
— Скажите, пожалуйста, куда мне отсюда идти?
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.
— только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долго идти.
N
Используй функцию reply, чтобы было понятно, что именно "нет".
нет
DB
это как в алисе в стране чудес:
— Скажите, пожалуйста, куда мне отсюда идти?
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.
— только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долго идти.
— Скажите, пожалуйста, куда мне отсюда идти?
— А куда ты хочешь попасть? — ответил Кот.
— Мне все равно — сказала Алиса.
— Тогда все равно, куда и идти, — заметил Кот.
— только бы попасть куда-нибудь, — пояснила Алиса.
— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долго идти.
Ладно, давай конкретику.
У каждого департамента есть набор документов.
И есть разрешения на:
- просмотр документов: View
- создание, изменение, удаление: Edit
- назначение прав - привязка списка ролей к возможности выполнять действия: Admin
То есть, члены ролей, перечисленных во View разрешении, могут просматривать.
Перечисленные в Edit - изменять
В Admin - назначать.
Так нормально? Вот я хочу построить объектную модель, которая бы описывала такое.
При чём, достаточно детально, чтобы понять, где храним в объекте айдишники связанных объектов, а где - экземпляры. И так далее.
У каждого департамента есть набор документов.
И есть разрешения на:
- просмотр документов: View
- создание, изменение, удаление: Edit
- назначение прав - привязка списка ролей к возможности выполнять действия: Admin
То есть, члены ролей, перечисленных во View разрешении, могут просматривать.
Перечисленные в Edit - изменять
В Admin - назначать.
Так нормально? Вот я хочу построить объектную модель, которая бы описывала такое.
При чём, достаточно детально, чтобы понять, где храним в объекте айдишники связанных объектов, а где - экземпляры. И так далее.
DB
Простая задача.
Как сделать её с DTO и сервисами, которые умеют в бизнес-логику - я знаю.
Как сделать её с классами, которые сами управляют своими данными - не очень, поскольку большинство данных - это связи с другими классами.
Как сделать её с DTO и сервисами, которые умеют в бизнес-логику - я знаю.
Как сделать её с классами, которые сами управляют своими данными - не очень, поскольку большинство данных - это связи с другими классами.
DB
Именно с этого всё началось. Что DTO и сервисы - говно. А вот нормально - это объекты, которые сами управляют своим состоянием. Ну ок. Я же не против. Но покажите, как?
YN
Ладно, давай конкретику.
У каждого департамента есть набор документов.
И есть разрешения на:
- просмотр документов: View
- создание, изменение, удаление: Edit
- назначение прав - привязка списка ролей к возможности выполнять действия: Admin
То есть, члены ролей, перечисленных во View разрешении, могут просматривать.
Перечисленные в Edit - изменять
В Admin - назначать.
Так нормально? Вот я хочу построить объектную модель, которая бы описывала такое.
При чём, достаточно детально, чтобы понять, где храним в объекте айдишники связанных объектов, а где - экземпляры. И так далее.
У каждого департамента есть набор документов.
И есть разрешения на:
- просмотр документов: View
- создание, изменение, удаление: Edit
- назначение прав - привязка списка ролей к возможности выполнять действия: Admin
То есть, члены ролей, перечисленных во View разрешении, могут просматривать.
Перечисленные в Edit - изменять
В Admin - назначать.
Так нормально? Вот я хочу построить объектную модель, которая бы описывала такое.
При чём, достаточно детально, чтобы понять, где храним в объекте айдишники связанных объектов, а где - экземпляры. И так далее.
прикольно, хз как такое строить навскидку, надо сидеть и думать 🤷♂️
DB
Ну тогда я пошёл дальше пилить ангуляровский фронт
YN
удачи!
NK
Подробная статья, в которой рассказывается как с минимальными затратами создать новую версию продукта и запустить ее в работу.
https://www.kamilgrzybek.com/design/strangling-net-framework-app-to-net-core/
#Big #Bang #Rewrite #Strangler #Pattern
https://www.kamilgrzybek.com/design/strangling-net-framework-app-to-net-core/
#Big #Bang #Rewrite #Strangler #Pattern
OT
Ребят, такой вопрос, мы в EF Core можем сопоставлять CUD-операции с хранимыми процедурами, как в EF 6?
B
Ребят, такой вопрос, мы в EF Core можем сопоставлять CUD-операции с хранимыми процедурами, как в EF 6?
Хз насчет автоматического подстанова круд операций, ты хочешь чтобы при вызове SaveChangesAdync дергало процедуру? Звучит как ересь, надюсь что нельзя.
А просто дергать хранимки можно, точно должен быть способ
А просто дергать хранимки можно, точно должен быть способ
OT
Скажу, так есть некоторая дополнительная логика при вставке, обновлении, удалении, которую бы хотелось вытащить в БД
OT
Без лишнего гемора, в EF 6 так было можно
OD
триггеры?
OT
Та наверное придется их заюзать)