К вопросу о наименовании методов типа FindUser. Префикс Try* принято добавлять к методу, если он возвращает bool: TryParse, TryGetValue. Если же метод может вернуть null, то это принято обозначать суффиксом *OrDefault: FirstOrDefault, GetValueOrDefault.
Хороший доклад. Но есть вопрос: если у нас бизнес-логика вынесена в отдельный проект и соответственно существует два этапа валидации (в веб-сервисе мы проверяем, что поля не пустые, а уже в "бизнесе" проверяем корректность данных по форме, а например в DAL проверяем, что они ещё и корректны по сути)... То как быть с ValidationException и всем этим наследованием? не пробрасывать же HTTP Code аж с DAL.
К вопросу о наименовании методов типа FindUser. Префикс Try* принято добавлять к методу, если он возвращает bool: TryParse, TryGetValue. Если же метод может вернуть null, то это принято обозначать суффиксом *OrDefault: FirstOrDefault, GetValueOrDefault.
Это просто прекрасно!! Практика великое дело, не с книжки академизмы зачитывает, спасибо Роман
Отличный доклад, спасибо!
Интересно. Погрело душу.
Отличный доклад, спасибо!
Хороший доклад. Но есть вопрос: если у нас бизнес-логика вынесена в отдельный проект и соответственно существует два этапа валидации (в веб-сервисе мы проверяем, что поля не пустые, а уже в "бизнесе" проверяем корректность данных по форме, а например в DAL проверяем, что они ещё и корректны по сути)... То как быть с ValidationException и всем этим наследованием? не пробрасывать же HTTP Code аж с DAL.
Правильно ли я понимаю, что использование парадигмы ФП подразумевает частичный отказ от паттерна Состояние?
Отличный доклад
!обисапс ,далкод йынчилтО
Переходи на функциональную сторону, у нас функции
Автор талантлив, речист, начитан - но необразован, к сожалению. Немножно ни в это самое, ни в красную армию. Чатгпт напоминает.