.net developer, бывший препресс-програмист
Репозиторий является посредником между слоем доступа к данным и доменным слоем,
работая как in-memory коллекция доменных обектов. Клиенты создают декларативные
описания запросов и передают их в репозиторий для выполнения.
— свободный перевод Мартина Фаулера
EntityFraemwork предоставляет нам готовую реализацию паттернов Repository: DbSet<T> и UnitOfWork: DbContext. Но мне часто приходится видеть, как коллеги используют в своих проектах собственную реализацию репозиториев поверх существующих в EntityFraemwork.
Чаще всего используется один из двух подходов:
И каждый из этих подходов содержит недостатки.
Когда речь заходит о создании .NET библиотеки, части API которой являются платформозависимыми, приходится думать, как всё это оформить в NuGet пакет, да так, чтобы установленная из пакета библиотека работала в разных сценариях (.NET Framework, .NET Core, self-contained app и т.д.). К сожалению, в сети сложно найти инструкцию, которая бы шаг за шагом показывала, как выполнить эту задачу. Данная статья призвана быть такой инструкцией.
По мнению Артема Закируллина*, одна из фундаментальных проблем, с которой сталкиваются разработчики при анализе кода – высокая когнитивная нагрузка. Это не абстрактное, а реальное ограничение возможностей, которое стоит времени и денег. На чтение и понимание кода, тратится больше времени, чем на его написание. Поэтому, разработчику нужно постоянно задаваться вопросом: не пишет ли он код, чтение которого создает чрезмерную когнитивную нагрузку?
Подробнее о том, с какими проблемами от высокой когнитивной нагрузки сталкиваются разработчики и какие решения помогут упростить понимание кода для последующей работы с ним читайте под катом.
*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.
Это - продолжение статьи, первая часть которой была опубликована ранее. В той части был рассмотрен процесс инициализации, общий для любого приложения .NET Core на базе шаблона Generic Host. А в этой части будет рассмотрена инициализация, специфическая именно для веб-приложения. Именно в нее входят вызовы методов Startup-класса.
Если вы не читали первую часть, то рекомендую в нее заглянуть, по двум причинам. Во-первых, процесс инициализации, специфической именно для веб-приложения, существенно опирается на механизмы, рассмотренные в первой части: методы интерфейса построителя веб-приложения IWebHostBuilder в основном реализуются через вызовы методов интерфейса построителя IHostBuilder, и процесс инициализации проходит, в целом, через те же стадии, общие для любого базирующегося на Generic Host приложения .NET Core. А во-вторых, там объяснено, для чего часть информации убрана под спойлеры, и какую информацию под какими спойлером можно увидеть (и решить - а стоит ли ее смотреть).
И ещё пара слов про вторую часть. К моему сожалению, она получилась раза в два больше первой части, которая сама по себе была и так немалой. Но мне не удалось найти способа сократить ее без ущерба для содержания. Так что заранее прошу простить меня тех, кому большой объем статьи помешает с ней ознакомиться. Возможно, им сможет помочь краткое содержание этой статьи, которое находится сразу под катом.
А ещё, опыт публикации первой части показал, что стоит заранее предупредить потенциальных читателей, чтобы ненароком не ввести их в заблуждение: в этой статье содержится только описание "как оно работает", но нет никакой информации, как этим пользоваться практически, никаких рецептов и вообще - никакого кода. К сожалению, большой объем матераиала заставил чем-то пожертвовать. И я решил ради полноты описания принципов работы - информации, которую лично я нигде больше не видел - пожертвовать сведениями о практических приемах работы - той информацией, которая, в конце концов, уже опубликована в руководстве от изготовителя и в многочисленных статьях.
Итак, кому интересен предмет статьи - добро пожаловать под кат.
Не так давно на Хабре я увидел статью с многообещающим названием "Что из себя представляет класс Startup и Program.cs в ASP.NET Core". Меня всегда интересовало и интересует, что именно происходит под капотом той или иной библиотеки или фреймворка, с которыми мне доводится работать. И к веб-приложениям на ASP.NET Core это относится в полной мере. И я надеялся получить из этой статьи новую информацию о том, как работают упомянутые классы при запуске такого приложения. Та статья, к сожалению, меня разочаровала: в ней всего лишь в очередной раз был пересказан кусок руководства, никакой новой информации я оттуда не получил. И при чтении ее я подумал, что, наверное, есть и другие люди, которым, как и мне, интересно не просто знать, как применять тот или иной фреймворк (ASP.NET Core в данном случае), но и как он работает. А так как я по разным причинам последнее время довольно сильно углубился во внутреннее устройство ASP.NET Core, то я подумал, что теперь мне есть много что рассказать о нем из того, что выходит за рамки руководств. И вот потому я решил для начала написать статью про то, что действительно представляют из себя классы Startup и Program - так, чтобы рассказать не о том, как ими пользоваться, а о том, как работают эти классы, причем - в контексте работы всего веб-приложения на ASP.NET Core. Однако поскольку необъятное объять нельзя, то предмет этот статьи ограничен. Прежде всего, она ограничивается рассказом только про веб-приложения, созданные с использованием нового типа шаблона приложения - Generic Host. Во-вторых, статья будет посвящена только тому, как происходит инициализация веб-приложения, потому что основная роль рассматриваемых классов именно такова - инициализация и запуск размещенного приложения.
И ещё - предупреждение, судя по одному из комментариев - необходимое, чтобы не вводить в заблуждение потенциальных читателей: эта статья не предназначена служить руководством, она не содержит рецептов "как это использовать на практике". Такая информация есть в многочисленных уже написанных другими руководствах, и я не вижу для себя смысла писать еще одно. Да и объем статьи и без того велик.
Итак, кому рассматриваемая тема, даже в столь ограниченном объеме, интересна - добро пожаловать под кат.
Игры бывают разные, большие и маленькие, триA и супер инди, в компаниях с сотнями разработчиков и что создаются самородками-одиночками. Редко их делают с нуля и пишут код только игры, чаще пишут игровые тулы, редактор и параллельно пишут саму игру. За всей этой многомиллиардной индустрией стоит код, много кода, очень много кода. Игровые движки и фреймворки – мощные инструменты, которые помогают разработчику творить его идеи и создавать увлекательные игровые миры. Это каркас, на котором строятся все игровые вселенные, они включают в себя сотни инструментов, библиотек и ресурсов, позволяя разработчикам превратить строчки кода в театр для одного зрителя.
Существует более сотни игровых движков, каждый из них содержит как минимум одну фичу которой нет ни в каком другом. Всех возможностей вместе нет ни в одном, и это прекрасно - иначе бы такой движок монополизировал рынок. Хм, Unreal5 ты ли это? Иногда полезно пробежать по release notes движка, чтобы оставаться в курсе последних новостей. Возможно вы разрабатываете свое решение и эта статья натолкнет вас на новые идеи. Готовы узнать что ваша любимая игры была сделана не на Unity, а на православном SDL?
Вот и пришло время для релиза VPN-клиента, родившегося благодаря хакатону DemHack, и выращенного при поддержке РосКомСвободы, PrivacyAccelerator и Теплицы социальных технологий.
Спустя полгода с того момента, как идея была впервые озвучена, мы презентуем готовый продукт — бесплатный опенсорсный клиент для self-hosted VPN, с помощью которого вы сможете установить VPN на свой сервер в несколько кликов.
Вместо скучной технической статьи о том, что вот оно: что-то сделали, что-то не успели, что-то пересмотрели, которую можно сократить до нескольких абзацев сути, я решил написать о своих размышлениях, о том, что вообще происходит, о бешеных принтерах, о развитии Интернета, в контексте его приватности, анонимности и блокировок.
Всем привет! Возможно уже совсем скоро разные новостные и IT-ресурсы будут подчищать информацию о способах обхода блокировок. А пока этого не случилось, запасаемся полезными гайдами и разворачиваем свои собственные VPN с защищенными от блокировок протоколами. Расскажу как это сделать, как изменилась Amnezia и как мы защитили WireGuard от блокировок.
В этой статье я покажу как написать приложение для windows на ассемблере. В качестве IDE будет привычная многим Visual Studio 2019 со своими привычными плюшками - подсветка кода, отладка и привычный просмотр локальных переменных и регистров. Собирать приложение будет MASM, а значит, у нас будут и масмовские плюшки. Это будет полноценное оконное приложение с меню, иконкой, отрисовкой, выводом текста и обработкой мыши с клавиатурой.
Поговорим о том, как при наличии небольшого количества времени и навыков построить мультимедийный комбайн с дополнительными возможностями домашнего сервера на базе Kubuntu 20.04 и KODI, способного работать 24/7/365.
Индексы — это первое, что необходимо хорошо понимать в работе SQL Server, но странным образом базовые вопросы не слишком часто задаются на форумах и получают не так уж много ответов.
Роб Шелдон отвечает на эти, вызывающие смущение в профессиональных кругах, вопросы об индексах в SQL Server: одни из них мы просто стесняемся задать, а прежде чем задать другие сначала подумаем дважды.
Я долго придумывал вступление к теме FPGA-реимплементации в контексте ретро, но это сложнее чем кажется. Давайте попробуем издалека. Сейчас электроника довольно неплохо стандартизирована, но ведь 40-50 лет назад ситуация была гораздо сложнее. То, что мы сейчас принимаем как должный и абсолютный незыблемый стандарт, когда-то таковым не являлось. Как, например, то, что в 1 байте 8 бит. Были машины и с 6 и с 9 битными байтами и много чего еще. Тем собственно старая техника и интригует. Сколько человекочасов было убито на её проектирование, какие гениальные и не очень решения принимались. И всё это будет утеряно? Да и просто - как это всё работало? Вопрос, который, думаю, интересовал многих ретро-энтузиастов ещё с детства.
Время идет, технологии меняются, набитые шишки копятся, настала пора обновить материалы по SVG-анимациям. Тем более, что тема для многих фронтендеров все еще остается странной и запутанной. В этой статье мы рассмотрим SVG-анимации с разных сторон, посмотрим на актуальное состояние дел, возможности и сопутствующие инструменты. Мы не будем разбирать каждое свойство и каждый хак. Слишком большой объем материала получится. Для этого есть MDN и ему подобные сайты. Задача текущей статьи — дать общее представление о том, что бывает, и от чего можно оттолкнуться, если вы решили изучать эту тему, а у вас полная каша в голове.