Должен ли я отделять свой контекст приложения от ApplicationDbContext, используемого для идентификации?

В Visual Studio 2013 при создании проекта ASP.NET создается файл IdentityModels.cs, который содержит класс ApplicationDbContext, который наследует от IdentityDbContext<ApplicationUser>, который в конечном итоге наследуется от DbContext.

Должен ли я хранить этот контекст только для связанных с учетной записью сущностей и создавал отдельный контекст для всех других объектов в приложении или я должен его смешивать.

Любая проблема или причина безопасности не включать все объекты всего моего приложения в один контекст?

Ответ 1

Для этого нет правильного ответа. Нет проблемы безопасности, связанной с двумя различными контекстами. Все сводится к вашей архитектуре - вам нужно создавать ссылки на пользователей в вашем домене или нет. В отдельных доменах вы не можете иметь EF, поддерживающий внешние ключи от пользовательских таблиц до домена.

Несколько раз я начал с двух разных dbContexts, но устал от дополнительного обслуживания и не получал и не объединял вещи в один.

И поскольку вы спрашиваете об этом, скорее всего, вы не получите ничего из двух отдельных db-контекстов, добавьте дополнительный код и нежелательное обслуживание в будущем. Поэтому я говорю, что нужно только начать. Вы всегда можете отделиться, когда вам это действительно нужно.

Ответ 2

Я бы создал отдельный контекст, главным образом по той причине, что вам может понадобиться отделить свою учетную запись db от вашего приложения db в какой-то момент. Часто политика безопасности организации запрашивает это. Вы всегда можете указать на одну и ту же строку соединения, если у вас нет этого требования, и все еще поддерживаете два контекста. Я предпочитаю разделять контексты, так как он сохраняет ограниченный api для отображения сущности. Сохранение его в отдельности также дает вам возможность шифровать вашу аутентификацию dd и, возможно, не ваши данные приложения, что дает вам хороший баланс между безопасностью и производительностью.

Ответ 3

Это отличный вопрос и тот, который я сам себе рассматривал.

Что делать, если вы хотите, чтобы ваше приложение использовало конструкцию с доменным дизайном или луковой архитектуры?

Компоненты членства и идентификации - это компоненты инфраструктура или приложения.

Объекты приложения часто считаются компонентами уровня домена.

Если вы используете один контекст, вам будет сложно отделить сущности вашего контекста на отдельные уровни без ущерба для целостности вашей архитектуры.

Сообщите мне, что вы думаете в комментариях?