C# - pattern matching - many discards
использую лямбды в инициализаторе объекта
А давайте глянем на это немного "сверху".
У нас есть объект который нифига не умеет, а всё поведение мы задаем ему сами.
Обычно делают так:
https://medium.com/@kevinkuan_26362/back-to-basic-designin...
Но нам это нафиг не нужно, сделаем все сами, чтобы можно было закинуть всё что угодно, в любой комбинации и без тестов
Делегаты там в принципе используются везде
Не имею понятия, для себя не пользую, вот нашел какой то примерчик. Покажите плиз...
https://github.com/SeanLeitzinger/Entity-Framework-Core-Ex...
в одном месте тебе нужно изменить дату рождения человеку, в другом имя, в третьем адрес.
Так реализовывать в принципе не буду, всё должно быть в одном месте, а объект всегда иметь определенное состояние.
где то так - "Aggregates are the basic element of transfer of data storage — you request to load or save whole aggregates." MF
Хотя в зависимости от конкретики возможны варианты.
Вот рекомендации например:
https://learn.microsoft.com/en-us/aspnet/core/data/ef-mvc/...
Никаких извращений
А визуально может быть так как и описано.
Но если сильно хочется атомарности операций, нужно просто забыть об объекте "Покупатель".
Например, Вводим три "команды"
- изменить дату рождения
- изменить имя
- изменить адрес
Которые могут вызывать скрытую "команду": изменить поле в таблице.
Принцип известный и простой - функция должна делать одну операцию и делать ее хорошо. И ничего другого она делать не должна.
Которые могут вызывать скрытую "команду": изменить поле в таблице.
и как эта команда может выглядеть?
Принцип известный и простой - функция должна делать одну операцию и делать ее хорошо.
изменить дату рождения
это очень много операций, надо отдельно:
Изменить день
Изменить месяц
Изменить год
и как эта команда может выглядеть?
Совершенно не интересует на данный момент - это особенности реализации
Ну например так
https://www.w3schools.com/sql/sql_update.asp
UPDATE Customers SET ContactName = 'Alfred Schmidt' WHERE CustomerID = 1;
это очень много операций, надо отдельно:
согласно подобным желаниям нужно не так как написано, а так:
Изменить 1й бит в дне,
Изменить 2й бит в дне,
...
и т.п. для месяца и года 
А вообще, это задача для объекта "дата"
Фу-фу-фу. Плюнуть в спину, когда ничего возразить не можешь... Не уподобляйся ололёшеньке.
Я на твой вопрос ответить не могу. Не понимаю проблемы, подозреваю что слишком конкретная, шарпистикая, я с шарпом практически не работал, EF не знаю.
Чисто теоретически - в любом ОО-языке без ссылок на методы в любом месте, где нужна была бы ссылка на метод, можно использовать интерфейс.
есть энтити класс Person, хочу функцию, которой я мог бы апдейтить любое свойство объекта Person в базе данных, доступ к объектам по айди
Я не когда-то очень давно делал один пример с EF просто ради ознакомления, но что-то мне подсказывает, что все эти делегаты - просто надстройка над EF. Ну типа как Linq - надстройка над коллекциями.
В случае с Linq все это работает по одной простой причине - Linq - это просто коллекция статических функций. Там нет, ни состояния, ни взаимодействия между компонентами.
Подозреваю, что в EF тоже самое - коллекция статических функций.
Делегат как входной параметр у статической функции вполне допустим. Другое дело, что сами по себе статические функции - зачастую головная боль. Но в виде расширения какого-либо интерфейса вполне допустимо.
Как я уже говорил, я не
могу придумать пример, когда использование делегатов было бы оправдано. Как исключение можно тут указать только расширения существующих интерфейсов (типа Linq). Оспользование делегатов для уведомления других объектов - no go. Т.к. для этого надо использовать эвенты.
