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

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

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

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

13
asp.net asp.net-identity-2 c# dbcontext entity-framework

3 ответов

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

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

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

15

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

6

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

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

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

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

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

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

1