Весь бойлерплейт вынести в общий набор библиотек компании.
Все инфраструктурные части, коннекторы, консюмеры, прослушиватели в общий набор библиотек проекта.
Если сервис предоставляет АПИ, то он же обязан предоставить готовую для использования библиотеку для работы с собой (и выкинуть в нугет репозиторий)
Вуаля. Ни-ка-ких проблем, чтоб создать новый сервис и встроить его в инфраструктуру. В идеале, конечно, создание нового сервиса начинается с создания по шаблону и сразу переходом к написанию логики. Ой. ну прям как в монолите! :)
Основная сложность здесь, это развивать качественные соглашения и следовать им, вести разработку общих либ и.. думать о других разработчиках, думать наперёд. Когда вы думаете о других, или даже о себе (в будущем), то получается хорошая разработка.
Многие ошибочно считают, что у приложения есть только те пользователи, которых видит бизнес: клиенты, кастомеры, партнёры... Но ещё есть и другие пользователи, это обслуживание, сопровождение, мониторинг, администрирование — тоже пользователи, про которых обычно забывают. Разработчики являются пользователями своего же изделия с точки зрения разработки, его надо развивать, поддерживать. Если обо всём этом подумать, нет проблем ни с микро-сервисной архитектурой, ни с монолитной. И там и там есть свои плюсы в каждой конкретной ситуации.
Библиотеки и тулы это хорошо конечно. Но они не решение, а средство, при чём зачастую ограниченное. Ещё, как это ни печально, иногда некоторые средства перестают поддерживаться, устаревают.
Поговорим о решении.
Используем настройку Arrange по happy path, т.е. на идеальный сценарий, прям в конструкторе теста. Таким образом основной успешный тест будет самым простым, буквально в пару строк.
А вот все отклонения вносятся уже в настроенный идеальный сценарий, в код каждого теста. Добавляется ещё несколько строк для каждого отклонения.
Это позволяет всегда оценивать все тесты с учётом изменений в идеальном сценарии, отказаться от кучи бойлерплейта, просто вносим точечные мутации в Arrange и проверяем ровно то, что нам интересно.
У нас старый проект, разработку которого начали до нас (и прошло несколько поколений вендорной разработки) в 2005-м, до сих пор успешно работает, активно развивается, абсолютное большинство библиотек из NuGet подходят. Да 100% совместимости прям всех-всех библиотек нет, но уровень обратной совместимости колоссальный.
Тут нужно уточнение. Какой год, на момент которого описывается флешбек? :) Фреймворк давно в составе винды, а новые Core распространяются часто без необходимости что-то ставить.
На всякий случай, в .NET уже очень давно есть режимы сборки со встроенной VM, а также Native AOT, создающий нативный бинарник, который запускается сразу. А ещё отличнейшая поддержка работы в docker-контейнерах, которых целая куча на любой вкус с разными линуксами, и в целом для серверных приложений он топ.
Сравнивать их вполне можно, так как есть большой спектр задач, которые решаются в обоих платформах.
Это не ворона и письменный стол. Это два письменных стола разного устройства и вида.
И вам немного не хватает знаний для сравнения. .NET давно имеет режим компиляции Native AOT, создающий полностью нативное приложение, не требуя предустановленных VM в системе. И до Native AOT был давно режим сборки вместе с VM, который также ничего не требовал для работы.
А зачем вообще качать Visual Studio на рутрекере? :) Cummunity Edition давным давно бесплатна и покрывает 99% потребностей и задач. Ещё есть VS Code с расширениями и Rider с лицухой для обучения за копейки, и Community редакция появилась недавно.
Перешёл с Delphi на .NET во времена NET 2.0. Причиной не было какого-то хайпа, никто к этому не принуждал, не принуждали обстоятельства, в компании где я работал, имел значения результат, а не способ его достижения. И перешёл именно потому, что C#, философия .NET, вектор развития понравились, а застой делфей с фокусом на десктопе, неудобный избыточный язык паскаль не нравились.
И ничуть не прогадал. Сегодня ведём разработку на dotnet в полный рост, я не встречал задач, которые бы прекрасно на нём не решались. Он самодостаточен, в нём есть всё, развитие идёт большими темпами, нет ощущения тяжести, что какие-то легаси тянут на дно. Он работает прекрасно в k8s, на всех платформах, окружение для разработки поднимается легчайше.
В общем, автор мог бы также рассказывать про советскую колбасу, зелёную траву и пломбир. Ничего по сути.
dotnet прекрасен. Чем больше я на нём работаю, имея под боком команды на других платформах, тем больше убеждаюсь, что он просто великолепен. Это не просто "хороший выбор", это замечательный выбор.
он полностью самодостаточен, ему не требуются никакие библиотеки и костыли на низкоуровневых ЯП (Си), не требуются веб-серверы, и прокладки на Go, прокси и ещё какие приблуды
на дотнете можно писать легчайше свои прокси, гейтвеи, веб-сервера, веб-приложения, микро-, макро- сервисы и монолиты любого уровня монструозности, игры, UI-шки, разрабатывать сайты с UI почти без JS, работать на самых последних протоколах
по опыту, даже совершенно запущенные легаси 20+ лет на дотнете, над которым поработало десятки компаний, передавалось из одного аутсорса в другой, сносно работает, сносно сопровождается и поддаётся бесшовному рефакторингу, развивается и приносит прибыль
это удивительно, но даже в проект 20-летней давности прекрасно внедряются новейшие библиотеки и решения
он очень быстрый, производительный, оптимально работает с CPU/RAM, поддаётся оптимизациям на любом уровне
оптимизации в дотнете уделено большое внимание, это отражается во всём и системе типов, безопасных стековых ссылок и т.д.
беспрецедентный уровень наблюдаемости, телеметрия из коробки, не надо подключать какие-то левые core-библиотеки и подстраиваться под них. всё работает сразу, с ходу, подключаются только нужные инструментарий и экспортеры. это когда в приложении на 10 строк кода, с ходу метрики каждой детали, трассируется всё и вся, автоинструментирование тож работает
не надо сидеть и ломать голову что же что же выбрать: Gin, Fiber, fastapi, фалкон, джанга, юи, лаварел...............? просто нет такого вопроса в принципе. kestrel+asp.net имеет несколько слоёв от низкоуровневой работы с пакетами, очень быстрых апи, до мощных MVC-like контроллеров, с поддержкой полной/частичной генерацией страниц на потрясающем языке Razor, который можно при желании заменить
И это правда. если основной стек разработки дотнет, то нет никакой необходимости устраивать зоопарк из всяких нод, питонов, гошек, пхпшек. не нужно это.
Чем плохо? Почему обязательно надо слепо следовать всем трендам и тащиться на Go? GoLang безусловно хорош, очень даже. Если выбирать с нуля, или переходить с пхп, ещё можно подумать.
Но! Менять шарп на Go? Что я с этого получу? Что я потеряю мне известно, а это прям много.
Если у нас на одном методе одна аутентификация, а на другом другая, это разные политики. В случае, когда "можно обойти" защиту применив другую схему, это проблема неправильно настроенной авторизации, а не аутентификации. А решение автора крайне не типичное и не расширяемое, и больше вносит путаницы, чем что-то действительно решает.
Говорю из опыта множества проектов с несколькими схемами. Политики решают эту задачу замечательно, потому что они и должны решать такую задачу.
Регистрируется как схема аутентификации в стандартном механизме аутентификации ASP.NET
Подключение аутентификации очевидное, всем понятное и единое (UseAuthentication)
Теперь можно использовать в различных политиках авторизации
Теперь можно использовать разную аутентификацию/авторизацию для разных методов, групп методов декларативно
Используется механизм принципала (HttpContext.User), и можно насыщать клеймами для разных ключей раздавать разные роли, и что угодно
Всё это теперь стандартно расширяемое и можно комбинировать.
В целом да, можно сделать самое простое решение в 5 строчек, но это не значит, что так будет хорошо. Тут 5 строчек, там 5 строчек, и на выходе получается вещь в себе, комбайн, который просто надо знать как работает до каждой косточки, и допиливать под каждый чих. Если придёт новый человек на проект, он аутентификацию будет искать там, где она обычно реализуется стандартно, а не в кастомных миддлварях.
Аутентификация/авторизация это про безопасность, и там экономить на строчках кода не желательно. Может выйти боком.
Очень, очень, и очень часто. Половина бизнес атрибутов опциональна, и далеко не всё можно закостылить дефолтным значением, как опциональным. Заходишь в кафе и просишь водички, а тебе наливают водки со словами "тебе это не нужно, никому тут это не нужно".
Сколько конкретных денег приносит, например, уборщица? Есть процессы с прямым доходным выхлопом, а есть сопровождающие, поддерживающие, обеспечивающие, которые нельзя посчитать в "конкретные деньги, которые они приносят".
Программирование это автоматизация. Далеко не каждая автоматизация направлена на сокращения ручного труда или прибыль.
Я не думаю, зачем абстрактный принцип нужен. Я прекрасно знаю зачем он нужен. И вижу выхлоп в работе. Как по-вашему я должен относиться к заявлениям, что всё это чушь собачья, и не нужна, если я на опыте вижу обратное? Это вообще сюр какой-то нездоровый.
Например, есть ещё KISS (Keep it simple, stupid), который даёт свою отличную от SOLID трактовку.
Это разные принципы, а не разные трактовки для одного и того же. Или я в упор не понял посыла.
Сообщения вида "делай хорошо, плохо не делай", "каждый случай индивидуален", "все люди человеки", которые при всей своей правоте несут ровно ноль информации и только забивают эфир.
Ну вот есть такой принцип для здоровья, что чистить зубы надо минимум два раза в день. И тут приходит человек, смотрите говорит, знакомый взял железную щётку и чистил два раза в день, остался без зубов. А вот другой знакомый, чистил два раза в день, содой. Остался без зубов. Ещё друг знакомого, чистил два раза в день, нормальной щёткой, делал это каждый раз по полтора часа не прекращая, остался без зубов.
Возвели, понимаешь, чистку зубов в какую-то догму. Нашли себе святую корову! Выкиньте этот глупый принцип :)
Так разве это плохо? То, что мертво умереть не может. Но "хоронят" обычно вполне себе живые языки и платформы :)
Весь бойлерплейт вынести в общий набор библиотек компании.
Все инфраструктурные части, коннекторы, консюмеры, прослушиватели в общий набор библиотек проекта.
Если сервис предоставляет АПИ, то он же обязан предоставить готовую для использования библиотеку для работы с собой (и выкинуть в нугет репозиторий)
Вуаля. Ни-ка-ких проблем, чтоб создать новый сервис и встроить его в инфраструктуру. В идеале, конечно, создание нового сервиса начинается с создания по шаблону и сразу переходом к написанию логики. Ой. ну прям как в монолите! :)
Основная сложность здесь, это развивать качественные соглашения и следовать им, вести разработку общих либ и.. думать о других разработчиках, думать наперёд. Когда вы думаете о других, или даже о себе (в будущем), то получается хорошая разработка.
Многие ошибочно считают, что у приложения есть только те пользователи, которых видит бизнес: клиенты, кастомеры, партнёры... Но ещё есть и другие пользователи, это обслуживание, сопровождение, мониторинг, администрирование — тоже пользователи, про которых обычно забывают. Разработчики являются пользователями своего же изделия с точки зрения разработки, его надо развивать, поддерживать. Если обо всём этом подумать, нет проблем ни с микро-сервисной архитектурой, ни с монолитной. И там и там есть свои плюсы в каждой конкретной ситуации.
Очень удобный подход, тоже к этому пришли.
Библиотеки и тулы это хорошо конечно. Но они не решение, а средство, при чём зачастую ограниченное. Ещё, как это ни печально, иногда некоторые средства перестают поддерживаться, устаревают.
Поговорим о решении.
Используем настройку Arrange по happy path, т.е. на идеальный сценарий, прям в конструкторе теста. Таким образом основной успешный тест будет самым простым, буквально в пару строк.
А вот все отклонения вносятся уже в настроенный идеальный сценарий, в код каждого теста. Добавляется ещё несколько строк для каждого отклонения.
Это позволяет всегда оценивать все тесты с учётом изменений в идеальном сценарии, отказаться от кучи бойлерплейта, просто вносим точечные мутации в Arrange и проверяем ровно то, что нам интересно.
У нас старый проект, разработку которого начали до нас (и прошло несколько поколений вендорной разработки) в 2005-м, до сих пор успешно работает, активно развивается, абсолютное большинство библиотек из NuGet подходят. Да 100% совместимости прям всех-всех библиотек нет, но уровень обратной совместимости колоссальный.
Тут нужно уточнение. Какой год, на момент которого описывается флешбек? :) Фреймворк давно в составе винды, а новые Core распространяются часто без необходимости что-то ставить.
На всякий случай, в .NET уже очень давно есть режимы сборки со встроенной VM, а также Native AOT, создающий нативный бинарник, который запускается сразу. А ещё отличнейшая поддержка работы в docker-контейнерах, которых целая куча на любой вкус с разными линуксами, и в целом для серверных приложений он топ.
Сравнивать их вполне можно, так как есть большой спектр задач, которые решаются в обоих платформах.
Это не ворона и письменный стол. Это два письменных стола разного устройства и вида.
И вам немного не хватает знаний для сравнения. .NET давно имеет режим компиляции Native AOT, создающий полностью нативное приложение, не требуя предустановленных VM в системе. И до Native AOT был давно режим сборки вместе с VM, который также ничего не требовал для работы.
А зачем вообще качать Visual Studio на рутрекере? :)
Cummunity Edition давным давно бесплатна и покрывает 99% потребностей и задач.
Ещё есть VS Code с расширениями и Rider с лицухой для обучения за копейки, и Community редакция появилась недавно.
Перешёл с Delphi на .NET во времена NET 2.0. Причиной не было какого-то хайпа, никто к этому не принуждал, не принуждали обстоятельства, в компании где я работал, имел значения результат, а не способ его достижения. И перешёл именно потому, что C#, философия .NET, вектор развития понравились, а застой делфей с фокусом на десктопе, неудобный избыточный язык паскаль не нравились.
И ничуть не прогадал. Сегодня ведём разработку на dotnet в полный рост, я не встречал задач, которые бы прекрасно на нём не решались. Он самодостаточен, в нём есть всё, развитие идёт большими темпами, нет ощущения тяжести, что какие-то легаси тянут на дно. Он работает прекрасно в k8s, на всех платформах, окружение для разработки поднимается легчайше.
В общем, автор мог бы также рассказывать про советскую колбасу, зелёную траву и пломбир. Ничего по сути.
dotnet прекрасен. Чем больше я на нём работаю, имея под боком команды на других платформах, тем больше убеждаюсь, что он просто великолепен. Это не просто "хороший выбор", это замечательный выбор.
он полностью самодостаточен, ему не требуются никакие библиотеки и костыли на низкоуровневых ЯП (Си), не требуются веб-серверы, и прокладки на Go, прокси и ещё какие приблуды
на дотнете можно писать легчайше свои прокси, гейтвеи, веб-сервера, веб-приложения, микро-, макро- сервисы и монолиты любого уровня монструозности, игры, UI-шки, разрабатывать сайты с UI почти без JS, работать на самых последних протоколах
по опыту, даже совершенно запущенные легаси 20+ лет на дотнете, над которым поработало десятки компаний, передавалось из одного аутсорса в другой, сносно работает, сносно сопровождается и поддаётся бесшовному рефакторингу, развивается и приносит прибыль
это удивительно, но даже в проект 20-летней давности прекрасно внедряются новейшие библиотеки и решения
он очень быстрый, производительный, оптимально работает с CPU/RAM, поддаётся оптимизациям на любом уровне
оптимизации в дотнете уделено большое внимание, это отражается во всём и системе типов, безопасных стековых ссылок и т.д.
беспрецедентный уровень наблюдаемости, телеметрия из коробки, не надо подключать какие-то левые core-библиотеки и подстраиваться под них. всё работает сразу, с ходу, подключаются только нужные инструментарий и экспортеры. это когда в приложении на 10 строк кода, с ходу метрики каждой детали, трассируется всё и вся, автоинструментирование тож работает
не надо сидеть и ломать голову что же что же выбрать: Gin, Fiber, fastapi, фалкон, джанга, юи, лаварел...............? просто нет такого вопроса в принципе. kestrel+asp.net имеет несколько слоёв от низкоуровневой работы с пакетами, очень быстрых апи, до мощных MVC-like контроллеров, с поддержкой полной/частичной генерацией страниц на потрясающем языке Razor, который можно при желании заменить
И это правда. если основной стек разработки дотнет, то нет никакой необходимости устраивать зоопарк из всяких нод, питонов, гошек, пхпшек. не нужно это.
Чем плохо? Почему обязательно надо слепо следовать всем трендам и тащиться на Go? GoLang безусловно хорош, очень даже. Если выбирать с нуля, или переходить с пхп, ещё можно подумать.
Но! Менять шарп на Go? Что я с этого получу? Что я потеряю мне известно, а это прям много.
Поддержу, это именно функция авторизации.
Если у нас на одном методе одна аутентификация, а на другом другая, это разные политики. В случае, когда "можно обойти" защиту применив другую схему, это проблема неправильно настроенной авторизации, а не аутентификации. А решение автора крайне не типичное и не расширяемое, и больше вносит путаницы, чем что-то действительно решает.
Говорю из опыта множества проектов с несколькими схемами. Политики решают эту задачу замечательно, потому что они и должны решать такую задачу.
Здесь много кода даёт весомый профит:
Регистрируется как схема аутентификации в стандартном механизме аутентификации ASP.NET
Подключение аутентификации очевидное, всем понятное и единое (UseAuthentication)
Теперь можно использовать в различных политиках авторизации
Теперь можно использовать разную аутентификацию/авторизацию для разных методов, групп методов декларативно
Используется механизм принципала (HttpContext.User), и можно насыщать клеймами для разных ключей раздавать разные роли, и что угодно
Всё это теперь стандартно расширяемое и можно комбинировать.
В целом да, можно сделать самое простое решение в 5 строчек, но это не значит, что так будет хорошо. Тут 5 строчек, там 5 строчек, и на выходе получается вещь в себе, комбайн, который просто надо знать как работает до каждой косточки, и допиливать под каждый чих. Если придёт новый человек на проект, он аутентификацию будет искать там, где она обычно реализуется стандартно, а не в кастомных миддлварях.
Аутентификация/авторизация это про безопасность, и там экономить на строчках кода не желательно. Может выйти боком.
Очень, очень, и очень часто. Половина бизнес атрибутов опциональна, и далеко не всё можно закостылить дефолтным значением, как опциональным. Заходишь в кафе и просишь водички, а тебе наливают водки со словами "тебе это не нужно, никому тут это не нужно".
Сколько конкретных денег приносит, например, уборщица? Есть процессы с прямым доходным выхлопом, а есть сопровождающие, поддерживающие, обеспечивающие, которые нельзя посчитать в "конкретные деньги, которые они приносят".
Программирование это автоматизация. Далеко не каждая автоматизация направлена на сокращения ручного труда или прибыль.
Я не думаю, зачем абстрактный принцип нужен. Я прекрасно знаю зачем он нужен. И вижу выхлоп в работе. Как по-вашему я должен относиться к заявлениям, что всё это чушь собачья, и не нужна, если я на опыте вижу обратное? Это вообще сюр какой-то нездоровый.
Так ни на что не надо молиться, это же итак должно быть очевидно.
SOLID, DRY, KISS, и куча других, это принципы, которые можно соблюдать и нарушать. Что не так?
Это разные принципы, а не разные трактовки для одного и того же. Или я в упор не понял посыла.
Сообщения вида "делай хорошо, плохо не делай", "каждый случай индивидуален", "все люди человеки", которые при всей своей правоте несут ровно ноль информации и только забивают эфир.
Ну вот есть такой принцип для здоровья, что чистить зубы надо минимум два раза в день. И тут приходит человек, смотрите говорит, знакомый взял железную щётку и чистил два раза в день, остался без зубов. А вот другой знакомый, чистил два раза в день, содой. Остался без зубов. Ещё друг знакомого, чистил два раза в день, нормальной щёткой, делал это каждый раз по полтора часа не прекращая, остался без зубов.
Возвели, понимаешь, чистку зубов в какую-то догму. Нашли себе святую корову! Выкиньте этот глупый принцип :)
Как можно найти противоречие там, где его отродясь нет и не было? KISS не противоречит SOLID, который не навязывает классы.