Вы даже листинги кода взяли из официальной документации по FluentValidation. Вам не кажется, что для статьи на Хабр нужно приложить чуть больше усилий?
проблема "ненужных" зависимостей устраняется атрибутом [FromServices], соответственно minimal api экономит только на создании самого контроллера, как уже заметили выше.
OK, вы разделили маппинг на секции. Логически это чем-нибудь отличается от разделения экшенов по отдельным контроллерам? Принудительным использованием fluent builder вместо атрибутов?
Тем не менее, использование MediatR ухудшает читаемость кода. Хотя бы потому, что возможно добиться аналогичной организации кода, руководствуясь банальным SOLID, при этом избежав проблемы поиска "а какой класс в проекте реализует вот тот дженерик интерфейс с таким то параметром", что особенно сильно проявляется на больших проектах.
Про удобство: возьмем типичный не очень микро сервис с сотней-другой эндпоинтов, обвешанных атрибутами авторизации, кастомной сериализации, подсказками для OpenAPI и прочей часто встречающейся в энтерпрайз-разработке логикой. Перенос всего этого в один файл (или предполагается разбитие файла на секции?) значительно ухудшит и удобство, и наглядность. Даже при использовании максимально тонких контроллеров.
Предпочитаю 16'. В рюкзак все еще влезает, т.е. мобильность лично мою никак не портит. А каждый сантиметр по вертикали добавляет комфорта, особенно если стационарного места на ближайшее время не предвидится.
По примерам кода выше уже проехались. Добавлю, что тема очень избитая, и сказать что-то новое (а иначе зачем писать статью, особенно на Хабр) достаточно сложно. Плюс, декоратор - сам по себе популярный и многим известный паттерн, и с его вариациями в DI, в сторонних библиотеках типа MediatR, или просто работая с middleware pipeline - сталкивались многие. Поэтому, опытному разработчику эта статья не нужна, а новичку я бы рекомендовал прочитать любой популярный гайд/курс/книгу по паттернам. Если очень хочется именно C# и на русском языке - есть прекрасная книга Сергея Теплякова. Да хотя бы статья на википедии.
В чем ценность именно этого коротенького перевода, состоящего из 2 не самых удачных примеров кода? Получился бы более достойный хабра материал при склейке всех переводов в одну статью.
Как раз воспользоваться options.ValidateOnBuild - максимально дешево, один раз написать тест на сборку контейнера. Все интеграционные тесты через TestHost также свалятся, если валидация контейнера не прошла. Да и ваш SetUpServiceProvider свалится.
Эта валидация не покрывает многие кейсы, часть из них я упомянул в заключении.
Можете пример привести, когда контейнер пройдет валидацию, но не пройдет ваш тест? Т.е. в чем практическая польза предложенного метода. Проверка зависимостей контроллеров - не принимается, поскольку из коробки есть
нельзя не задать встречный вопрос: когда сменивший вид деятельности (например, продвинувшийся по карьерной лестнице) человек перестает быть программистом, т.е. теряет соответствующую компетенцию?
...и последнее, что в этом посте указано из непосредственно программирования, как основной рабочей деятельности, это:
В 1990 году я устроился по контракту в Rational, работая в C++ над первым выпуском Rational Rose. Здесь я познакомился с Гради Бучем и разработал план своей первой книги.
далее лишь изучение новых языков:
Я успел немного позаигрывать с Golang, Elixr и Kotlin, и я с трепетом смотрел на Haskel. Я даже пробовал с Scala и F#.
Расширять кругозор - безусловно, нужно. Но это совершенно не подтверждает наличие хоть какого-либо практического опыта, особенно в энтерпрайз разработке и просто на больших проектах (где как раз становится актуальным SOLID и другие способы снижения сложности кода). Хотя бы в этом тысячелетии, что весьма желательно в стремительно развивающейся отрасли.
Роберт Мартин — известный программист со стажем, реализовал огромное число проектов.
Какие проекты Роберт Мартин "реализовал" как программист? На его сайте об этом ни слова. На википедии следующее:
In 1991, Martin founded Object Mentor, now defunct, which provided instructor-led training on the extreme programming methodology.[citation needed] As of March 2020, he operated two companies:[citation needed]
Uncle Bob Consulting – provides consulting and training services
Clean Coders – which provides training videos
Даже в своем собственном блоге Мартин предпочитал подавать себя прежде всего как консультант. От блога, кстати, я давно отписался по причине огромного количества воды и рекомендаций в стиле "нормально делай - нормально будет".
Снимал в Актау в апреле: банкоматы сбера выдают тенге с рублёвой МИР без проблем. Банкоматы и терминалы Халых банка работать с этой же картой отказались, несмотря на заявленную поддержку.
Где-то я этот формальный стиль изложения уже видел... https://docs.fluentvalidation.net/en/latest/
А далее в статье идет перевод https://docs.fluentvalidation.net/en/latest/start.html.
Вы даже листинги кода взяли из официальной документации по FluentValidation. Вам не кажется, что для статьи на Хабр нужно приложить чуть больше усилий?
проблема "ненужных" зависимостей устраняется атрибутом [FromServices], соответственно minimal api экономит только на создании самого контроллера, как уже заметили выше.
OK, вы разделили маппинг на секции. Логически это чем-нибудь отличается от разделения экшенов по отдельным контроллерам? Принудительным использованием fluent builder вместо атрибутов?
Тем не менее, использование MediatR ухудшает читаемость кода. Хотя бы потому, что возможно добиться аналогичной организации кода, руководствуясь банальным SOLID, при этом избежав проблемы поиска "а какой класс в проекте реализует вот тот дженерик интерфейс с таким то параметром", что особенно сильно проявляется на больших проектах.
Влияет ли minimal api на производительность?
Про удобство: возьмем типичный не очень микро сервис с сотней-другой эндпоинтов, обвешанных атрибутами авторизации, кастомной сериализации, подсказками для OpenAPI и прочей часто встречающейся в энтерпрайз-разработке логикой. Перенос всего этого в один файл (или предполагается разбитие файла на секции?) значительно ухудшит и удобство, и наглядность. Даже при использовании максимально тонких контроллеров.
почему?
Предпочитаю 16'. В рюкзак все еще влезает, т.е. мобильность лично мою никак не портит. А каждый сантиметр по вертикали добавляет комфорта, особенно если стационарного места на ближайшее время не предвидится.
Это буквально первая задача из гайда литкода для абсолютных начинающих. Своеобразный hello world. Попробуйте задачи уровня Hard.
По примерам кода выше уже проехались. Добавлю, что тема очень избитая, и сказать что-то новое (а иначе зачем писать статью, особенно на Хабр) достаточно сложно. Плюс, декоратор - сам по себе популярный и многим известный паттерн, и с его вариациями в DI, в сторонних библиотеках типа MediatR, или просто работая с middleware pipeline - сталкивались многие. Поэтому, опытному разработчику эта статья не нужна, а новичку я бы рекомендовал прочитать любой популярный гайд/курс/книгу по паттернам. Если очень хочется именно C# и на русском языке - есть прекрасная книга Сергея Теплякова. Да хотя бы статья на википедии.
del
Нейропортреты сейчас в тренде :) а справится ли нейросеть, например, с генерацией спрайтов для 2D графики?
В чем ценность именно этого коротенького перевода, состоящего из 2 не самых удачных примеров кода? Получился бы более достойный хабра материал при склейке всех переводов в одну статью.
Как раз воспользоваться options.ValidateOnBuild - максимально дешево, один раз написать тест на сборку контейнера. Все интеграционные тесты через TestHost также свалятся, если валидация контейнера не прошла. Да и ваш SetUpServiceProvider свалится.
Можете пример привести, когда контейнер пройдет валидацию, но не пройдет ваш тест? Т.е. в чем практическая польза предложенного метода. Проверка зависимостей контроллеров - не принимается, поскольку из коробки есть
После которого зависимости контроллеров будут валидироваться самим контейнером.
способ есть https://andrewlock.net/new-in-asp-net-core-3-service-provider-validation/
нельзя не задать встречный вопрос: когда сменивший вид деятельности (например, продвинувшийся по карьерной лестнице) человек перестает быть программистом, т.е. теряет соответствующую компетенцию?
...и последнее, что в этом посте указано из непосредственно программирования, как основной рабочей деятельности, это:
далее лишь изучение новых языков:
Расширять кругозор - безусловно, нужно. Но это совершенно не подтверждает наличие хоть какого-либо практического опыта, особенно в энтерпрайз разработке и просто на больших проектах (где как раз становится актуальным SOLID и другие способы снижения сложности кода). Хотя бы в этом тысячелетии, что весьма желательно в стремительно развивающейся отрасли.
Почувствуйте разницу, к примеру, с содержимым блога и резюме Mark Seeman https://blog.ploeh.dk/hire-me/
Какие проекты Роберт Мартин "реализовал" как программист? На его сайте об этом ни слова. На википедии следующее:
Даже в своем собственном блоге Мартин предпочитал подавать себя прежде всего как консультант. От блога, кстати, я давно отписался по причине огромного количества воды и рекомендаций в стиле "нормально делай - нормально будет".
Снимал в Актау в апреле: банкоматы сбера выдают тенге с рублёвой МИР без проблем. Банкоматы и терминалы Халых банка работать с этой же картой отказались, несмотря на заявленную поддержку.
Для создания иерархии объектов и разрешения зависимостей можно было просто использовать DI-контейнер. Он для этого и предназначен.