Комментарии 34
Есть отличие: хендлер с двумя дженериками, поэтому можно все обвесить одним набором декораторов. С методами репозиториев и сервисов этот номер не пройдёт, потому что будут другие интерфейсы с другим набором параметров и методов. А то что у всех есть эта своя уютная инфраструктура, это да, есть. Если вам достался код ситхов, проще перейти на темную сторону, не находите?:)
- 2 года опыта (junior) — фигачим код в контроллер
- 3-5 лет опыта работы (middle) — используем чужой фреймворк
- 6-8 лет опыта работы (senior) — строим фреймворки типа описанного в статье
- >8 лет опыта работы (dzen) — фигачим код в контроллер
Я много пользовался фреймворком MediatR (после просмотра видео Clean Architecture with ASP.NET Core 2.1) и в статье вижу очень многие вещи, которые всплывали у меня при изучении. Тут даже главное не то, что я много примеров приложений испробовал (а их много было), а то, что я пытался повторить отдельные части фреймворка в своих приложениях и пробовал сделать шаг в сторону и посмотреть, что получится. В статье примерно такой же опыт, очень хорошо вербализованный. Хорошая статья, мне нравится. Надо будет перечитать ещё раз, более вдумчиво.
Ага, можно. Либо в middleware, либо в action filter. На Кодфесте я даже добавил несколько слайдов об этой альтернативе. В этом случае middleware / action filter будет выполнять функцию соответствующего декоратора, а тип результата выполнения pipeline будет всегда IActionResult. Основная идея остаётся прежней, но меняются детали реализации. Плюс — работает из коробки. Минус — жестко привязано к MVC. Спасибо, что упомянули. Попозже расширю пост контентом с Кодфеста.
В ближайшее время не будет.
А вот и ссылка. Обещанного, как говорится, три года ждут.
И ждём тепрь уже C# 8. Ну да, до этого ждали 7. Но и в восьмом всё равно не появилось долгожданных иммутабл рекордов. Measure типов с размерностью, как и алгебраических, мы не дождёмся уже никогда, а проблема с нуллами решена костыльно и некомпозабельно.
Так что же заставляет нас раз за разом выбирать для создания энтерпрайз системы такой неподходящий инструмент?
Я всерьёз призываю автора попробовать взять нормальный фреймворк и нормальный язык (да вот хотя бы giraffe и F#) и наваять то же самое на нём. Читабельность кода увеличится в разы, а объём бойлерплейта сократится просто на порядок.
это другая парадигма, которую воспринимать могут далеко не все.
Кого годами учили ООП как серебряной пуле и больше ничему другому.
Для людей кому в универе давали ФП все эти декораторы фасадов фабрик тоже будут казаться сломом мозга.
Истина как всегда посередине, но у шарпа перекос в сторону ООП слишком сильный. F#/Scala в этом плане посерединке.
Ну а вообще классическое ООП имхо устарело. Те же тайпклассы просто на порядок лучше всего, что предлагается в ООП в виде интерфейсов/классов/...
Портировать существующие проекты конечно не стоит, а вот начинать новые почему бы и нет. где-то пятая часть докладов на дотнексте на F#, к примеру, включая akka.net.
Что касается вакансий, то их чуть больше, и найти себе по вкусу среди них наверняка можно. Да и ЗП там вкусные
В остальных случаях это выглядит как минимум странно, а как максимум даже некомпетентно со стороны предложившего.
Некомпетентно одновременно повысить качество продукта и мотивацию за счет разового обучения? Ну да, так ведь никто никогда не делает.
Я например пришел на C# вакансию, год писал C#/Solitiy. Щас проект завершен, следующий планируем на Rust. Полет отличный.
Вместе вяжется то, что язык дело десяток. Программист одного языка/стека довольно несчастный человек. Особенно если он верит, что ничего лучше придумать нельзя, и все новые языки маргиналы без будущего.
В этом году в Питере будет сразу два доклада в поддержку вашей точки зрения: https://dotnext-piter.ru/2019/spb/talks/4vehcump1bwnqlqrewsilq/, https://dotnext-piter.ru/2019/spb/talks/2nvbecxhuasmfgnmxmnczt/. Приходите с VanKrock, будет что обсудить.
Может удобнее обернуть запрос через расширение, например, request.UseHandle<А>().UseHandle<В>()?
Вдохновлён этой статьей и докладом. Помимо того, что декораторы позволяют добавить функционал к уже готовой бизнес логике, они еще и переиспользуемые. Фантастика.
Но в голове не укладывается как это применить на своих проектах. Декоратор валидации хорошо смотрится если он один, а если нужна армия валидаторов для разных сущностей и их полей? Как нужно мыслить при написании клиентского кода?
P. S. Многие согласятся что в статье про архитектуру ПО слишком много деталей о C#, это мешает пониманию. Псевдокод был бы уместнее. А вообще, прекрасный материал.
domainEventStore.Raise
Почему у хранилища метод Raise?
статичный DomainEvents
Кто все эти люди, которых вы цитируете? :)
Быстрорастворимое проектирование