Знакомство с Entity Framework Core
Entity Framework (EF) — это упрощенная, расширяемая и кроссплатформенная версия популярной технологии для доступа к данным Entity Framework. Она появилась в .NET Core в середине 2016 г.
Поскольку общие сведения о EF Core уже доступны в документации Майкрософт, здесь будут просто приведены ссылки на эту информацию.
Дополнительные ресурсы
-
Entity Framework Core https://docs.microsoft.com/ef/core/
-
Начало работы с ASP.NET Core и Entity Framework Core с использованием Visual Studio https://docs.microsoft.com/aspnet/core/data/ef-mvc/
-
Класс DbContext https://docs.microsoft.com/dotnet/api/microsoft.entityframeworkcore.dbcontext
-
Сравнение EF Core и EF6.x https://docs.microsoft.com/ef/efcore-and-ef6/index
Собственные функции внедрения зависимостей
При сборке больших, масштабируемых приложений важно обеспечить слабые взаимозависимости между компонентами и службами. Внедрение зависимостей — популярный способ решения этой задачи и собственный компонент ASP.NET Core
В приложениях ASP.NET разработчики используют для внедрения зависимостей стороннюю библиотеку. Одна из таких библиотек, Unity, входит в шаблоны и рекомендации Майкрософт.
Пример внедрения зависимостей с использованием библиотеки Unity — это реализация как оболочки для :
Создайте экземпляр , зарегистрируйте свою службу и установите средство разрешения зависимостей в новый экземпляр для вашего контейнера:
Там, где необходимо, вставьте :
Так как внедрение зависимостей является частью ASP.NET Core, вы можете добавить свою службу в метод файла Startup.cs:
Репозиторий, как и в Unity, можно внедрять где угодно.
Примечание
Дополнительные сведения о внедрении зависимостей см. здесь.
Обновление ссылок на пакеты
В файле CSPROJ в проекте версии 1.x перечислены все проекты NuGet, используемые проектом.
В проекте ASP.NET Core 2.0, предназначенном для .NET Core 2.0, коллекция пакетов в файле CSPROJ заменяется ссылкой на один метапакет:
В метапакет входят все компоненты ASP.NET Core 2.0 и Entity Framework Core 2.0.
В проектах ASP.NET Core 2.0, предназначенных для .NET Framework, по-прежнему должны использоваться ссылки на отдельные пакеты NuGet. Измените значение атрибута каждого узла на 2.0.0.
Например, вот список узлов , используемых в типичном проекте ASP.NET Core 2.0, предназначенном для .NET Framework:
Требуемые версии .NET Framework
Проекты ASP.NET Core предлагают разработчикам гибкость работы с .NET Core и .NET Framework. Определить наиболее подходящую платформу поможет статья Выбор между .NET Core и .NET Framework для серверных приложений.
При разработке для .NET Framework проекты должны ссылаться на отдельные пакеты NuGet.
Работа с .NET Core позволяет избавиться от многочисленных явных ссылок на пакеты благодаря метапакету ASP.NET Core. Установите метапакет в свой проект.
При использовании метапакета никакие указанные по ссылкам пакеты с приложением не развертываются. Все эти ресурсы входят в хранилище среды выполнения .NET Core и предварительно компилируются для повышения производительности. Дополнительные сведения см. в статье Метапакет Microsoft.AspNetCore.App для ASP.NET Core 2.1.
Вопросы и ответы
-
Снижается ли новая минимальная модель размещения?
Нет. Новая модель размещения функционально эквивалентна 98% сценариев, поддерживаемых и . Существуют некоторые сложные сценарии, для которых требуются определенные обходные пути , но мы предполагаем, что они чрезвычайно редки.
-
Является ли универсальная модель размещения устаревшей?
Нет. Универсальная модель размещения является альтернативной моделью, которая поддерживается бессрочно. Универсальный узел подкрепляет новую модель размещения и по-прежнему является основным способом размещения приложений на основе рабочих ролей.
-
Нужно ли выполнять миграцию на новую модель размещения?
Нет. Новая модель размещения является предпочтительным способом размещения новых приложений с помощью .NET 6 и более поздних версий, но вы не вынуждены изменять макет проекта в существующих приложениях. Это означает, что приложения могут выполнить обновление с .NET 5 на .NET 6, изменив целевую платформу в файле проекта с на . Дополнительные сведения см. в разделе в этой статье. Однако мы рекомендуем перенести приложения на новую модель размещения, чтобы воспользоваться преимуществами новых функций, доступных только для новой модели размещения.
-
Нужно ли использовать инструкции верхнего уровня?
Нет. Новые шаблоны проектов используют инструкции верхнего уровня, но новые API размещения можно использовать в любом приложении .NET 6 для размещения веб-сервера или приложения.
-
Где можно вставить состояние, сохраненное в виде полей в классе или ?
мы настоятельно рекомендуем использовать внедрение зависимостей (DI) в качестве потока состояния в ASP.NET Core приложениях.
Существует два подхода к хранению состояния за пределами DI:
-
Сохраните состояние в другом классе. Хранение в классе предполагает статическое состояние, доступ к которому можно получить из любого места в приложении.
-
Используйте класс, созданный операторами верхнего уровня, для хранения состояния. Использование для хранения состояния — это Семантический подход:
-
-
Что делать, если я использую пользовательский контейнер внедрения зависимостей?
Поддерживаются пользовательские контейнеры DI. Пример см. в разделе .
-
Вы и по-прежнему работаете?
Да. — Это способ проверки новой модели размещения. Пример см. в разделе .
Время существования экземпляра IUnitOfWork и DbContext EF в контейнере IoC
Необходимо реализовать общий доступ к объекту (предоставляемому как объект ) из нескольких репозиториев в рамках одной и той же области запроса HTTP. Например, это может требоваться, когда выполняемая операция должна иметь дело с несколькими агрегаторами, или просто потому, что вы используете несколько экземпляров репозитория
Также важно упомянуть, что интерфейс является частью уровня домена, а не типом EF Core
Для этого время существования службы экземпляра объекта должно быть установлено в значение ServiceLifetime.Scoped. Это время существования по умолчанию при регистрации с помощью в контейнере IoC из метода ConfigureServices файла в проекте веб-API ASP.NET Core. Это проиллюстрировано в следующем коде.
Режим создания экземпляра DbContext не должен быть настроен как ServiceLifetime.Transient или ServiceLifetime.Singleton.
Создание и применение миграций в EF Core
Использование миграции — это стандартный способ создания и обновления базы данных с помощью Entity Framework Core. Процесс миграции состоит из двух этапов: создание миграции и применение миграции. Как мы уже говорили, схема нашей базы данных должна быть согласована с моделью базы данных, и каждое изменение в модели базы данных необходимо переносить в саму базу данных.
Эти изменения могут быть, например, следующими:
- Изменения в свойствах класса модели
- Изменения конфигурации
- Добавление или удаление свойств из класса контекста
Начиная с ASP.NET Core 3.0 инструменты EF Core, необходимые для миграции, не устанавливаются предварительно. Следовательно, мы должны установить библиотеку . Если вы следите за этой серией с самого начала, значит, у вас уже установлена библиотека .
Чтобы создать миграцию, мы можем использовать окно консоли диспетчера пакетов Visual Studio или командное окно (командная строка Windows) :
Добавление миграции Add-Migration MigrationName
Или через интерфейс командной строки dotnet:
dotnet ef migrations добавить MigrationName
В нашем приложении мы собираемся использовать Консоль диспетчера пакетов (PMC), поэтому давайте сделаем это, набрав:
После того, как мы нажмем клавишу Enter, наша миграция будет завершена.
Действия, которые происходят за кулисами
Файл содержит модель базы данных и обновляется каждый раз при добавлении новой миграции. Два других файла: и — это файлы, содержащие и описывающие вновь созданную миграцию.
Итак, если вы выполнили все шаги из предыдущих статей, содержимое файла должно выглядеть следующим образом:
В этом файле есть два метода с удобными названиями и . Метод состоит из команд, которые будут выполнены, когда мы применим эту миграцию. В качестве противоположного действия метод будет выполнять команды, когда мы откатываем эту миграцию (в этом случае он просто удалит созданную таблицу).
Применение созданной миграции
После того, как мы успешно создали нашу миграцию, мы должны применить ее, чтобы изменения вступили в силу в базе данных. Существует несколько способов применения миграции (с использованием сценариев SQL, с использованием метода Database.Migrate или с использованием методов командной строки), и, как мы делали с созданием, мы собираемся использовать подход методов командной строки.
Для консоли диспетчера пакетов команда:
Update-Database
Для окна командной строки команда:
dotnet ef database update
Поскольку мы уже определились с PMC, давайте откроем окно PMC и выполним команду:
После нажатия клавиши Enter мы увидим все различные действия, которые EF Core выполняет для нас, чтобы применить созданную миграцию. В результате у нас будет таблица , созданная со всей предоставленной конфигурацией из предыдущих статей:
Есть еще несколько важных фактов, которые нам нужно знать о миграции EF Core. Если мы проверим нашу базу данных, мы найдем еще одну созданную таблицу: . EF Core использует эту таблицу для отслеживания всех примененных миграций. Таким образом, это означает, что если мы создадим еще одну миграцию в нашем коде и применим ее, EF Core применит только недавно созданную миграцию.
Но как EF Core узнает, какую миграцию нужно применить?
Ну, он сохраняет уникальный идентификатор в , который представляет собой уникальное имя файла миграции, созданного при миграции, и никогда больше не выполняет файлы с тем же именем:
Каждая миграция применяется внутри транзакции SQL, что означает, что вся миграция либо завершается успешно, либо не выполняется. Если нам нужно применить несколько миграций, они будут применяться в точном порядке их создания.
Adding a Migration
At the very first time, you defined the initial domain classes. At this point, there is no database for your application which can store the data from your domain classes.
So, firstly, you need to create a migration.
Open the Package Manager Console from the menu Tools -> NuGet Package Manager -> Package Manager Console in Visual Studio and execute the following command to add a migration.
Package Manager Console
PM> add-migration MyFirstMigration
If you are using dotnet Command Line Interface, execute the following command.
CLI
> dotnet ef migrations add MyFirstMigration
In the above commands, is the name of a migration. This will create three files in the folder of your project, as shown below.
- <timestamp>_<Migration Name>.cs: The main migration file which includes migration operations in the Up() and Down() methods. The Up() method includes the code for creating DB objects and Down() method includes code for removing DB objects.
- <timestamp>_<Migration Name>.Designer.cs: The migrations metadata file which contains information used by EF Core.
- <contextclassname>ModelSnapshot.cs: A snapshot of your current model. This is used to determine what changed when creating the next migration.
Now, after creating a migration snapshot, it’s time to create the database.
Модель
В EF Core доступ к данным осуществляется с помощью модели. Модель состоит из классов сущностей и объекта контекста, который представляет сеанс взаимодействия с базой данных. Объект контекста позволяет выполнять запросы и сохранять данные. Дополнительные сведения см. в разделе Создание модели.
EF поддерживает следующие подходы к разработке моделей:
- Создание модели на основе существующей базы данных.
- Написание кода модели вручную в соответствии с базой данных.
- После создания модели используйте Миграции EF для создания базы данных на основе модели. Миграции позволяют развивать базу данных по мере изменения модели.
Обновление страницы удаления
Для страницы «Delete» (Удаление) платформа Entity Framework обнаруживает конфликты параллелизма, вызванные схожим изменением кафедры. Когда метод отображает представление подтверждения, представление включает исходное значение в скрытое поле. Затем это значение доступно для метода , который вызывается, когда пользователь подтверждает удаление. Когда Entity Framework создает команду SQL , она включает предложение с исходным значением . Если команда приводит к нулевой строке (то есть изменилась строка после отображения страницы подтверждения удаления), возникает исключение параллелизма, а метод вызывается с флагом ошибки , чтобы отобразить страницу подтверждения с сообщением об ошибке. Также возможно, что было затронуто нулевое число строк, поскольку строка была удалена другим пользователем, поэтому в этом случае отображается другое сообщение об ошибке.
В DepartmentController.CSзамените метод следующим кодом:
Этот метод принимает необязательный параметр, который указывает, отображается ли страница повторно после ошибки параллелизма. Если этот флаг имеет значение , в представление отправляется сообщение об ошибке с помощью свойства .
Замените код в методе (с именем ) следующим кодом:
В шаблонном коде, который вы только что заменили, этот метод принимал только идентификатор записи:
Вы изменили этот параметр на экземпляр сущности, созданный связывателем модели. Это предоставляет доступ к значению свойства в дополнение к ключу записи.
Вы также изменили имя метода действия с на . Шаблонный код с именем метод , чтобы присвоить методу уникальную сигнатуру. (Среда CLR требует, чтобы перегруженные методы имели различные параметры метода.) Теперь, когда сигнатуры уникальны, можно придерживаться соглашения MVC и использовать одно и то же имя для методов и DELETE.
При перехвате ошибки параллелизма код повторно отображает страницу подтверждения удаления и предоставляет флаг, указывающий, что нужно отобразить сообщение об ошибке параллелизма.
В виевс\департмент\делете.кштмлзамените код шаблона следующим кодом, который добавляет поле сообщения об ошибке и скрытые поля для свойств DepartmentID и rowversion. Изменения выделены.
Этот код добавляет сообщение об ошибке между заголовками и :
Он заменяет в поле :
Наконец, он добавляет скрытые поля для свойств и после инструкции :
Запустите страницу индекса отделов. Щелкните правой кнопкой мыши гиперссылку Удалить для английского Отдела и выберите пункт Открыть в новой вкладке, а затем на первой вкладке щелкните гиперссылку изменить для английского Отдела.
В первом окне измените одно из значений и нажмите кнопку сохранить.
Изменение будет подтверждено на странице индекса.
На второй вкладке нажмите кнопку Delete (Удалить).
Вы видите сообщение об ошибке параллелизма, а значения кафедры обновляются с использованием актуальных сведений из базы данных.
Если нажать кнопку Delete (Удалить) еще раз, вы будете перенаправлены на страницу индекса, которая показывает, что кафедра была удалена.
Изменения кода проверки подлинности
ASP.NET Core 2,1 предоставляется ASP.NET Core Identity в виде Razor библиотеки классов (ркл).
Пользовательский интерфейс по умолчанию 2,1 в Identity настоящее время не предоставляет существенных новых функций по сравнению с версией 2,0. Замена Identity с помощью пакета РКЛ является необязательной. Ниже перечислены преимущества замены кода, созданного шаблоном Identity , РКЛ версией.
- Многие файлы перемещаются из исходного дерева.
- Все исправления ошибок или новые функции Identity включены в Microsoft.AspNetCore.app метапакет. Обновление будет автоматически получено Identity при обновлении.
Если вы внесли нетривиальные изменения в созданный в шаблоне Identity код, сделайте следующее:
- Предыдущие преимущества, возможно, не выключают для преобразования в версию РКЛ.
- вы можете поддерживать код ASP.NET Core 2,0 Identity , который полностью поддерживается.
Identity 2,1 предоставляет конечные точки с областью. Например, в следующей таблице приведены примеры Identity конечных точек, которые изменяются с 2,0 на 2,1:
URL-АДРЕС 2,0 | URL-АДРЕС 2,1 |
---|---|
/аккаунт/логин | /Identity/аккаунт/логин |
/аккаунт/логаут | /Identity/аккаунт/логаут |
/аккаунт/манаже | /Identity/аккаунт/манаже |
Приложения, имеющие код с использованием Identity и заменой Identity пользовательского интерфейса 2,0 в библиотеке 2,1, Identity должны учитывать URL-адреса учетных записей сегмента, добавленные в Identity префиксы URI. Одним из способов управления новыми Identity конечными точками является настройка перенаправлений, например из .
Обновление Identity до версии 2,1
Для обновления до 2,1 доступны следующие параметры Identity .
- Используйте Identity код пользовательского интерфейса 2,0 без изменений. Использование Identity кода UI 2,0 полностью поддерживается. Это хороший подход при внесении значительных изменений в созданный Identity код.
- Удалите существующий Identity код 2,0 и Identity шаблон в проект. Проект будет использовать ASP.NET Core Identity Razor библиотеку классов. Вы можете создать код и пользовательский интерфейс для любого Identity измененного кода пользовательского интерфейса. Примените изменения кода к вновь сформированному коду пользовательского интерфейса.
- Удалите существующий Identity код 2,0 и Identity шаблон в проект с возможностью переопределения всех файлов.
Замена Identity пользовательского интерфейса 2,0 на Identity Razor библиотеку классов 2,1
в этом разделе описаны действия по замене кода, созданного шаблоном ASP.NET Core 2,0, на Identity ASP.NET Core Identity Razor библиотеку классов. Следующие шаги предназначены для Razor проекта страниц, но подход к проекту MVC аналогичен.
- Убедитесь, что .
- Удалите следующие папки и все файлы в них:
- Контроллеры
- Страницы/учетная запись/
- Расширения
- Выполните построение проекта.
-
Формирование Identity шаблонов в проект:
- Выберите проекты, в которых выполняется выход из файла _ Layout. cshtml .
- Выберите + значок в правой части класса контекста данных. Примите имя по умолчанию.
- Выберите Добавить , чтобы создать новый класс контекста данных. Для формирования шаблона требуется создать новый контекст данных. Вы удаляете новый контекст данных в следующем разделе.
Обновить после формирования шаблонов Identity
-
Удалите Identity производный класс, сформированный с помощью шаблона, в папке Areas/ Identity /Дата/ .
-
Удалите области/ Identity / Identity хостингстартуп. CS.
-
Обновите файл _ LoginPartial. cshtml :
- Переместите pages/ _ LoginPartial. cshtml в pages/Shared/ _ LoginPartial. cshtml.
- Добавьте ссылки на форму и привязку.
- Обновите элемент до .
В следующем коде показан обновленный файл _ LoginPartial. cshtml :
Обновите , включив в него следующий код.
шаблоны Project используют дуенде Identity Server
Project шаблоны теперь используют Identity сервер дуенде. Руководство по миграции см. Identity в разделе Server4 v 4.1 to дуенде Identity Server V5.
Важно!
Дуенде Identity Server — это продукт с открытым кодом с соглашением о взаимной лицензии. Если вы планируете использовать Identity сервер дуенде в рабочей среде, вам может потребоваться получить коммерческую лицензию от дуенде Software и заплатить за лицензию. Дополнительные сведения см. в разделе Дуенде Software: Licenses.
сведения об использовании Microsoft Azure Active Directory для см ASP.NET Core Identity . в разделе Identity (репозиторий GitHub dotnet/aspnetcore).
Добавьте свойство с именем в каждый , чтобы удовлетворить новое требование из обновленной версии . Ключи необходимы как часть контракта с Identity хранилищами сервера дуенде.
Примечание
Существующие миграции необходимо создать повторно для Identity сервера дуенде.
Ссылочные типы, допускающие значение NULL (NRT), и статический анализ состояния NULL компилятора .NET
ASP.NET Core шаблоны проектов используют ссылочные типы, допускающие значение null (нртс), и компилятор .net выполняет статический анализ состояния null. Эти функции были выпущены в C# 8 и включены по умолчанию для приложений, созданных с помощью ASP.NET Core 6.0 (C# 10) или более поздних версий.
Предупреждения статического анализа состояния NULL компилятора .NET можно либо использовать как руководство по обновлению примера документации, либо к примеру приложения локально или игнорировать. Статический анализ состояния NULL можно отключить, в файле проекта приложения, который мы рекомендуем только для примеров документации и примеров приложений, если при изучении .NET возникли ненужные предупреждения компилятора. Не рекомендуется отключать проверку состояния NULL в рабочих проектах.
Дополнительные сведения о NRT, свойстве MSBuild и обновлении приложений (включая рекомендации ) см. в следующих ресурсах в документации по C#:
- Ссылочные типы, допускающие значение NULL
- Ссылочные типы, допускающие значение NULL (справочник по C#)
- Подробнее о методах разрешения предупреждений, допускающих значения NULL
- Обновление базы кода путем добавления ссылочных типов, допускающих значение NULL, чтобы повысить качество диагностических предупреждений о значениях NULL
- Атрибуты для статического анализа состояния со значением NULL
Использование фабрики DbContext (например, для Blazor)
Некоторые типы приложений (например, ASP.NET Core Blazor) используют внедрение зависимостей, но не создают область службы, соответствующую нужному времени существования . Даже если такое соответствие отсутствует, приложению, возможно, потребуется выполнять несколько единиц работы в рамках такой области, например в одном HTTP-запросе.
В таких случаях можно использовать AddDbContextFactory для регистрации фабрики для создания экземпляров . Пример:
Класс должен предоставить доступ к общедоступному конструктору с помощью параметра . Такой же шаблон используется в традиционных приложениях ASP.NET Core (см. раздел выше).
Затем фабрику можно использовать в других службах посредством внедрения конструктора. Пример:
Внедренную фабрику затем можно использовать для создания экземпляров DbContext в коде службы. Пример:
Обратите внимание, что созданными таким образом экземплярами управляет поставщик служб приложения. Поэтому приложение должно удалять их
Дополнительные сведения об использовании EF Core с Blazor см. в статье ASP.NET Core Blazor Server с Entity Framework Core.
Executing Custom SQL
Sometimes, you may want to execute custom SQL at the same time as the migration is applied to the database. You may need to do this because your database provider doesn’t support something, or because the operation you want to perform is not related to the migration. Or you might want to add a new coumn to a table and then populate it with data.
In these instances, you can use the method. This should be placed in the generated method at the point where you want the SQL to be executed. In the example below, the method is called before the first table is created:
If you need to reverse the custom SQL operation in the event that the migration is applied, you would use the method to execute the appropriate SQL in the method.
Использование средств
Перед использованием этих средств может потребоваться создать запускаемый проект или задать среду.
Целевой проект и запускаемый проект
Команды ссылаются на проект и запускаемый проект.
-
Проект также называется целевым проектом , так как он служит для добавления или удаления файлов. По умолчанию проект в текущем каталоге является целевым. Можно указать другой проект в качестве целевого проекта с помощью параметра.
-
Запускаемый проект — это тот, который выполняет сборка и запуск средств. Средства должны выполнять код приложения во время разработки для получения сведений о проекте, таких как строка подключения к базе данных и Конфигурация модели. По умолчанию проект в текущем каталоге является запускаемым проектом. Можно указать другой проект в качестве запускаемого проекта с помощью параметра.
Запускаемый проект и целевой проект часто являются одним и тем же проектом. Типичный сценарий, в котором они являются отдельными проектами, состоит в следующих случаях:
- Контекст EF Core и классы сущностей находятся в библиотеке классов .NET Core.
- Консольное приложение .NET Core или веб-приложение ссылается на библиотеку классов.
Также можно разместить код миграции в библиотеке классов, отдельном от контекста EF Core.
Другие целевые платформы
средства CLI работают с проектами .net Core и платформа .NET Framework проектами. приложения с моделью EF Core в библиотеке классов .NET Standard могут не иметь проекта .net Core или платформа .NET Framework. например, это справедливо для приложений Xamarin и универсальная платформа Windows. В таких случаях можно создать проект консольного приложения .NET Core, предназначенное только для запуска в качестве запускаемого проекта для инструментов. Проект может быть фиктивным проектом без реального кода — необходимо только предоставить целевой объект для инструментов.
Зачем нужен фиктивный проект? Как упоминалось ранее, средства должны выполнять код приложения во время разработки. Для этого им нужно использовать среду выполнения .NET Core. если EF Coreная модель находится в проекте, ориентированном на .net Core или платформа .NET Framework, EF Core средства позаимствованы среду выполнения из проекта. Они не могут сделать это, если модель EF Core находится в библиотеке классов .NET Standard. .NET Standard не является реальной реализацией .NET; это спецификация набора интерфейсов API, которые должны поддерживаться реализациями .NET. Поэтому .NET Standard недостаточно для того, чтобы средства EF Core выполняли код приложения. Фиктивный проект, который создается для использования в качестве запускаемого проекта, предоставляет конкретную целевую платформу, в которую средства могут загрузить библиотеку классов .NET Standard.
среда ASP.NET Core
чтобы указать среду для проектов ASP.NET Core, задайте переменную среды ASPNETCORE_ENVIRONMENT перед выполнением команд.
Начиная с EF Core 5,0, дополнительные аргументы также могут передаваться в Program. Креатехостбуилдер, что позволяет указать среду в командной строке:
Совет
Токен направляет все, что следует за аргументом, и не пытается проанализировать их как параметры. Все дополнительные аргументы, не используемые, пересылаются в приложение.
Изменения в Blazor логике маршрутизации приложений в 5.0.1 и последующих версиях 5. x до 6,0
вычисление приоритета маршрута изменилось в ASP.NET Coreном выпуске исправления 5.0.1. Это может повлиять на вас, если вы определили перехватывать все маршруты или маршруты с необязательными параметрами.
Старое поведение
с предыдущим поведением в ASP.NET Core 5.0.0 или более ранней версии маршруты с более низким приоритетом, такие как, сопоставляются перед маршрутами с более высоким приоритетом, например .
Новое поведение
новое поведение в ASP.NET Core 5.0.1 или более поздней версии соответствует поведению маршрутизации, определенному в ASP.NET Core приложениях, где платформа рассчитывает и устанавливает приоритет маршрута для каждого сегмента, а также использует длину маршрута для прерывания связей в качестве вторичного критерия.
Причина изменения
исходное поведение считается ошибкой в реализации, поскольку наша цель заключается в том, чтобы система маршрутизации находилась так Blazor же, как и система маршрутизации ASP.NET Core для подмножества функций, поддерживаемых Blazor маршрутизацией.
Рекомендованное действие
Добавьте атрибут к компоненту в файле, чтобы принять правильное поведение:
Если имеет значение , то при сопоставлении маршрутов предпочтение отдается точным совпадениям, а не подстановочным знакам.
Важно!
Все приложения должны явно задать значение .
Возможность задать значение или оставить его неопределенным , предоставляется только для обеспечения обратной совместимости.
При выпуске .NET 6 маршрутизатор всегда будет предпочитать точные соответствия, и параметр будет недоступен.
Преимущества, обеспечиваемые ASP.NET Core
Миллионы разработчиков использовали и продолжают использовать ASP.NET 4.x для создания веб-приложений. ASP.NET Core — это модификация ASP.NET 4.x с архитектурными изменениями, формирующими более рациональную и более модульную платформу.
ASP.NET Core предоставляет следующие преимущества:
- Единое решение для создания пользовательского веб-интерфейса и веб-API.
- Разработано для тестируемости.
- Razor Pages упрощает написание кода для сценариев страниц и повышает его эффективность.
- Blazor позволяет использовать в браузере язык C# вместе с JavaScript. совместное использование серверной и клиентской логик приложений, написанных с помощью .NET;
- Возможность разработки и запуска в ОС Windows, macOS и Linux.
- Открытый исходный код и ориентация на сообщество.
- Интеграция современных клиентских платформ и рабочих процессов разработки.
- Поддержка размещения служб удаленного вызова процедур (RPC) с помощью gRPC.
- Облачная система конфигурации на основе среды.
- Встроенное введение зависимостей.
- Упрощенный высокопроизводительный модульный конвейер HTTP-запросов.
- Следующие возможности размещения:
- Kestrel
- Службы IIS
- HTTP.sys
- Nginx
- Apache
- Docker
- .
- Инструментарий, упрощающий процесс современной веб-разработки.
Инфраструктура в Entity Framework Core с точки зрения DDD
С точки зрения DDD важной особенностью EF является возможность использования сущностей предметной области POCO, которые в терминологии EF также называются сущностями code-first. При использовании сущностей предметной области POCO ваши классы модели предметной области являются неустойчивыми, следуя принципам Persistence Ignorance (независимости сохраняемости) и Infrastructure Ignorance (независимости инфраструктуры)
В шаблонах DDD вы должны инкапсулировать правила и поведение домена в самом классе сущностей, чтобы он мог управлять инвариантами, проверками и правилами при доступе к любой коллекции. Таким образом, в DDD не рекомендуется разрешать общий доступ к коллекциям дочерних сущностей или объектов значений. Вместо этого следует предоставить методы, определяющие, как и когда могут обновляться поля и коллекции свойств, и какое поведение и действия должны осуществляться, когда это происходит.
Начиная с EF Core 1.1, для удовлетворения этих требований DDD можно создавать в своих сущностях простые поля вместо общедоступных свойств. Если вы не хотите, чтобы поле сущности было доступно извне, можно просто создать атрибут или поле вместо свойства. Можно также использовать методы задания закрытых свойств.
Аналогичным образом, теперь вы можете иметь доступ к коллекциям только на чтение, используя общедоступное свойство, написанное как , которое поддерживается закрытым членом поля для коллекции (например ) в вашей сущности, основанной на EF для сохраняемости. В предыдущих версиях Entity Framework требовалось наличие свойств коллекции для поддержки , что означало, что любой разработчик, использующий родительский класс сущностей, может добавлять или удалять элементы с помощью его коллекций свойств. Эта возможность противоречила бы рекомендуемым шаблонам в DDD.
Вы можете использовать закрытую коллекцию при предоставлении объекта только для чтения, как показано в следующем примере кода.
Свойство может быть доступно только для чтения с помощью . Этот тип доступен только для чтения, поэтому он защищен от обычных внешних обновлений.
EF Core предоставляет способ сопоставления модели предметной области с физической базой данных без «засорения» этой модели предметной области. Это чистый код POCO .NET, так как действие сопоставления реализовано на уровне сохраняемости. В данном действии сопоставления необходимо настроить сопоставление полей с базой данных. В следующем примере метода из и класса вызов указывает EF Core на необходимость обратиться к свойству через его поле.
При использовании полей вместо свойств сущность сохраняется так же, как если бы она имела свойство . Однако она предоставляет единственный метод доступа для добавления в заказ новых элементов. В результате поведение и данные оказываются связаны друг с другом и будут согласованными во всем коде приложения, использующем модель предметной области.
Правила для проектов, предназначенных для общей платформы
Общая платформа — это набор сборок (DLL-файлов), которые не находятся в папках приложения. Чтобы запустить приложение, необходимо установить на компьютере общую платформу. Дополнительную информацию см. в этой публикации об общей платформе.
ASP.NET Core 2,1 включает следующие общие платформы:
- Microsoft.AspNetCore.App
- Microsoft.AspNetCore.All
Версия, указанная в ссылке на пакет, является минимальной требуемой версией. Например, проект, ссылающийся на версии программного пакета, не будет выполняться на компьютере, где установлена только среда выполнения 2.1.0.
Известные проблемы в проектах, предназначенных для общей платформы:
-
пакет SDK для 2.1.300 для .net Core (впервые добавленный в Visual Studio 15,6) устанавливает неявную версию 2.1.0, которая вызывает конфликты с Entity Framework Core. Рекомендуемое решение — обновить пакет SDK для .NET Core до 2.1.301 или более поздней версии. Дополнительные сведения см. в разделе пакеты, использующие общие зависимости с Microsoft.AspNetCore.app, не могут ссылаться на версии исправления.
-
Все проекты, которые должны использовать или, должны добавить ссылку на пакет в файле проекта, даже если они содержат ссылку на проект в другом проекте с помощью или .
Пример
- содержит ссылку на пакет .
- содержит ссылку на проект .
Добавьте ссылку на пакет для в . Дополнительные сведения см. в разделе интеграционное тестирование сложно настроить и может привести к нарушению обслуживания общей платформы.