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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Элементы принадлежности и идентификационные данные Инфраструктура или приложение компоненты слоя.

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

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

Дайте мне знать, что вы думаете в комментариях?