Тестирование Identity 2.0 для уровня модели домена

Я пытаюсь реализовать Identity 2.0 в своем решении ASP.NET MVC 5, которое соответствует архитектуре лука.

У меня есть ApplicationUser в моем ядре.

namespace Core.DomainModel
{
    public class ApplicationUser {...}
}

В моем уровне доступа к данным я использую Entity Framework 6.1, и мой контекст происходит от IdentityDbContext, и в этом и заключается проблема. ApplicationUser необходимо извлечь из Microsoft.AspNet.Identity.EntityFramework.IdentityUser

namespace Infrastructure.DAL
{
    public class TestContext : IdentityDbContext<ApplicationUser> {...}
}

Моя модель домена не должна ссылаться на Microsoft.AspNet.Identity.EntityFramework, которая противоречит идее лука.

Какое хорошее решение?

Ответ 1

Вы можете наследовать IUser из пространства имен Core, и usermanager будет счастлив. Вам нужно будет заменить IUserStore своей собственной реализацией. Затем инициализируйте пользовательский менеджер примерно так:

new UserManager<ApplicationUser>(new YourNameSpace.UserStore<YourApplicationUser>()))

Ответ 2

Да, это большая проблема с фреймворком Identity, который пока не нашел хорошего решения.

Я предполагал добавить EF в проект моего домена, но решил против него в одном проекте: модели домена не знают о ApplicationUser, используя только Id для текущего пользователя, который они получают из

ClaimsPrincipal.Current.Claims
    .FirstOrDefault(c => c.Type == ClaimTypes.NameIdentifier)
    .Value

В этом проекте я сохранил код Identity в проектах Web и Data.

В моем другом проекте я добавил Identity и EF повсюду, включая проект домена. И угадай что? ничего плохого не произошло.

Я также рассмотрел такие решения, как уже предоставленный ссылка в блог Imran Baloch. Для меня это выглядело как большая работа, чтобы не получить никакой ценности для клиентов.

Просто повторить себя, нет хорошего решения отделить EF от Identity, не переписывая кучу кода (не нравится). Поэтому либо добавьте EF в проект домена (не нравится), либо сохраните свой код Identity в проекте Web/Data (иногда это невозможно, поэтому мне также не нравится).

Извините, но это низкоуровневое ограничение .Net.

Ответ 3

Проблема в том, что вы пытаетесь использовать шаблон Onion. В его основаниях вы всегда будете строить зависимости.

Преодолейте единую ответственность за свои модели, которые вы создаете. Вы можете легко сделать это, пытаясь правильно следовать дизайну Driven Driven, реализуя отдельные модели для каждого слоя:

BusinessLogic.Models.ApplicationUser
Презентация .Models.ApplicationUser
DAL.Models.ApplicationUser

Обратите внимание, что все эти модели являются разными классами, даже если они имеют 100% одинаковые свойства (хотя это никогда не 100%). Недостатком является то, что вам может потребоваться карта с одной модели на другую, но если вы полностью нацелены на чистую, модульную и расширяемую архитектуру - вот в чем. Подсказка: Automapper (или ExpressMapper), чтобы избежать кода, необходимого для отображения.