Программист C#
Говоря "настройка EF", я буду подразумевать настройку контекста базы данных. Поговорим в этой статье мы о некоторой автоматизации, кастомизации и обобщениях. Какая-то информация позволит делать обыденные вещи проще, а какая-то, возможно, станет ключевым фактором при выборе ORM.
Наконец, мы подошли к кульминации серии статей по автоматизации создания однотипных классов, проектов и даже целых архитектур. И расскажу я здесь про азы создания пользовательских расширений, про подключение с помощью расширений шаблонов элементов и проектов, про создание Wizard для наших шаблонов проектов, и про то, как удобнее это все использовать.
Прочитав предыдущие 2 статьи ([1], [2]), вы могли задуматься, а как поставить все это дело на поток? Как распространять свежие версии шаблонов, отделив доставку от разработки? Как вообще эти шаблоны разрабатывать? До сих пор мы только пользовались магией Visual Studio для их автоматического создания на основе готовых файлов. Оказывается, в Visual Studio есть готовые шаблоны проектов для шаблонов проектов и элементов (классов). Их мы и рассмотрим в этой статье.
В прошлый раз я рассуждал на тему расширений и шаблонов, что их можно создавать не только для общего пользования, но и для нужд конкретного проекта. А так же показал, как легко можно создать шаблон элемента (класса, например). Вы можете ознакомиться с предыдущей статьей по этой ссылке. Здесь же мы поговорим про создание шаблона проекта.
В магазине Visual Studio есть множество различных расширений на все случаи жизни. Есть в сети различные их подборки, которые могут упростить жизнь в общих или конкретных случаях. Однако я, почему-то, никогда не встречал шаблоны или расширения заточенные под проект.
Все мы боимся новой заразы. Привитые и не привитые. И даже те, кто не прививаются принципиально. Те кто носят маски и те кто нет. Уже есть проработанные методики лечения, но их эффективность, мягко скажем, не очень, во всяком случае по моему субъективному мнению. И вот, совершенно случайно, я наткнулся на новость, датируемую прошлым годом, в которой говорилось, что ученые из Сеченовского университета выявили эффективность метиленового синего при лечении коронавируса.
Когда я принимаю решение о том, какую выбрать архитектуру приложения, или как спроектировать БД, или какие нужны подготовительные работы для старта, или о том, что написать в следующем блоке кода, я думаю. Думаю о том, что я хочу получить, о том, как это решает мою проблему, есть ли более оптимальные решения. Согласитесь, такой подход будет полезен во многих сферах, причем не только интеллектуального труда. Но в данной статье я хочу поговорить про собеседование IT специалистов. Причем, специалистов с опытом, уровня Middle и выше. Приготовьтесь, я буду немного язвить.
Данная статья не является инструкцией по работе с EF миграциями. Здесь я собрал несколько скользких моментов и попытки их обойти. Давайте начнем!
PostgreSQL имеет тип данных Jsonb, который позволяет добавлять к стандартной реляционной модели дополнительные свойства с возможностью поиска по ним.
EntityFramework Core с расширением Npgsql умеет вытягивать данные поля в тип System.String
Однако для фильтрации по Json свойствам через EF на уровне запросов приходится использовать чистый SQL, что не очень то удобно, так как нужно лезть в маппинг (если он не автоматический), искать названия полей, соответствующих свойствам моделей, поддерживать это именование. Пропадает гибкость, которую нам дает ORM.
Если вас это угнетает, так же как и меня, добро пожаловать под кат.
В конце статьи имеется ссылка на исходники!
<local:HighlightTextBlock TextWrapping="Wrap">
<local:HighlightTextBlock.HighlightRules>
<local:HighlightRule HightlightedText="{Binding Filter, Source={x:Reference thisWindow}}">
<local:HighlightRule.Highlights>
<local:HighlightBackgroung Brush="Yellow"/>
<local:HighlightForeground Brush="Black"/>
</local:HighlightRule.Highlights>
</local:HighlightRule>
</local:HighlightTextBlock.HighlightRules>
<Run FontWeight="Bold">Property:</Run>
<Run Text="{Binding Property}"/>
</local:HighlightTextBlock>