Удаление пользователя легко запретить, наследуя конкретный IUserRepostory не от IGenericRepository<User>, а от ICanRead<User>, ICanUpdate<User>, GenericRepository<User>, но не ICanDelete<User>, и где GenericRepository<> - скрытый от потребителя тип.
Но согласен с тем, что это лишняя абстракция. DbSet - это уже репозиторий, отвязанный от конкретной БД. Смысл иметь два?
В нашей подмосковской деревеньке мосэнергосбыт везде позаменял старые счётчики на новые, умные, серии МИРТЕК-32-РУ.
К ним в комплекте нам выдали пультики, которые довольно шустро подключаются к самим счётчикам, и считывают все нужные показания, стоит лишь вбить в пульт нужный ID-шник счётчика на опоре ЛЭП.
Как следствие, последний шаг в полном автоматизации — это чтение такой инфы не пультом, а умным домом, а отсюда вопрос: что там за протокол связи, и где его можно почитать?
Эх, генералы - моя юность. Иногда накатывает сильное желание переписать мультиплеер нуб часть и интерфейс на юнити, сервером хостинге, защитой от читов и наконец нормальным неткодом.
Можно пойти еще дальше, и избавиться от xxxApi-класса.
Будет просто await IOtherService.UpdateUser(...., cancellationToken);
Но вместо ручной имплементации IOtherService, маппинг метода на URL, само обращение, ретраи, логирование, метрики, получение зависимостей, и т.д. — всё это можно сделать кодогенерацией и/или AOP
Правда, теперь это напоминает WCF, а ему уже сколько лет-то. Может, есть что готовенькое и поновее?
Рассмотрим пример на C#, демонстрирующий преимущества функционального программирования для качества кода:
Вижу обычный, стандартный шарповый код.
А есть какой-то пример, который являлся бы, по-вашему, не функциональным, но выполнял бы все те же самые действия? Лишенный, так сказать, "всех преимуществ".
Тестирование на товары с отрицательными ценами. Ожидаемый результат: игнорировать такие товары и вернуть сумму только положительных цен.
Но ведь проверять отрицательность цены должны другие тесты (валидаторы?), а не все подряд, кто имеет хоть какую-то возможность эту цену прочитать. Наличие отрицательных цен - это совершенно отдельный вопрос к бизнесу (возможно/не возможно), и его постоянное "учитывание", как в тестах, так и в остальной логике, лишь усложняет разработку.
Удаление пользователя легко запретить, наследуя конкретный
IUserRepostoryне отIGenericRepository<User>, а отICanRead<User>, ICanUpdate<User>, GenericRepository<User>, но неICanDelete<User>, и где GenericRepository<> - скрытый от потребителя тип.Но согласен с тем, что это лишняя абстракция. DbSet - это уже репозиторий, отвязанный от конкретной БД. Смысл иметь два?
что ж, забыли про мотивацию, сами виноваты
Тогда почему у него ответ такой же получится?
Да они и за сеньоров не готовы платить. Мне вот альфа на 100к больше тинька предложила, выбор в принципе стал очевиден.
Почему не создаётся? Там пулинг по дженерику?
А, все,понял, акцент на слове ef.
Да поныть-то мы всегда могем.
Родители тоже бывают разные. Некоторым из них ребёнок, в целом-то, особо и не нужен :)
Поэтому они не против, чтобы он "гулял где и как хочет"
О, этот неостановимый злой прогресс, когда в конце концов ты будешь всегда находить сразу всё, что тебе действительно нужно.
В нашей подмосковской деревеньке мосэнергосбыт везде позаменял старые счётчики на новые, умные, серии МИРТЕК-32-РУ.
К ним в комплекте нам выдали пультики, которые довольно шустро подключаются к самим счётчикам, и считывают все нужные показания, стоит лишь вбить в пульт нужный ID-шник счётчика на опоре ЛЭП.
Как следствие, последний шаг в полном автоматизации — это чтение такой инфы не пультом, а умным домом, а отсюда вопрос: что там за протокол связи, и где его можно почитать?
Кто-то знает?
А как насчёт
new () { Bars = [new (){...}, new (){...}] };?Эх, генералы - моя юность. Иногда накатывает сильное желание переписать мультиплеер нуб часть и интерфейс на юнити, сервером хостинге, защитой от читов и наконец нормальным неткодом.
прикольно. вот бы любой самолёт так умел
Так в Турции уже есть рабочий вариант letim, не? Правда, с 3-6% коммиссией.
Можно пойти еще дальше, и избавиться от
xxxApi-класса.Будет просто
await IOtherService.UpdateUser(...., cancellationToken);Но вместо ручной имплементации
IOtherService, маппинг метода на URL, само обращение, ретраи, логирование, метрики, получение зависимостей, и т.д. — всё это можно сделать кодогенерацией и/или AOPПравда, теперь это напоминает WCF, а ему уже сколько лет-то. Может, есть что готовенькое и поновее?
Вижу обычный, стандартный шарповый код.
А есть какой-то пример, который являлся бы, по-вашему, не функциональным, но выполнял бы все те же самые действия? Лишенный, так сказать, "всех преимуществ".
Просто "concurrent" даже в топ-6 гуглопереводов не переводится как "конкуретный" :)
мне уже кажется, что джуна-мидла натаскивать на неё будет проще и быстрее
Но ведь проверять отрицательность цены должны другие тесты (валидаторы?), а не все подряд, кто имеет хоть какую-то возможность эту цену прочитать. Наличие отрицательных цен - это совершенно отдельный вопрос к бизнесу (возможно/не возможно), и его постоянное "учитывание", как в тестах, так и в остальной логике, лишь усложняет разработку.
А если ваш Васян за свои деньги купил себе УльтраГайковёрт3000 и крутит их в 3 раза быстрее, вы ему тоже побольше работы накидаете?