Individual user accounts Database

Możesz korzystać z IdentityDbContext jak ze zwykłego DbContext z Entity Framework. Wyrzuć kod z IdentityDbContext do osobnego projektu np. web.Persistence i dodaj referencje do tego projektu w zależności od potrzeb. Projekt zawierający reguły biznesowe (z tego co zrozumiałem Twój odpowiednik web.Model) nie powinien być zależny od ORM ani innych zewnętrznych bibliotek, warto go odseparować.

Wybitny Szczur napisał(a):

Projekt zawierający reguły biznesowe (z tego co zrozumiałem Twój odpowiednik web.Model) nie powinien być zależny od ORM ani innych zewnętrznych bibliotek, warto go odseparować.

Słuszna uwaga, tylko w świecie EF to jest niemożliwe.

Na tyle ile można było jest odseparowany :)

Odseparowanie Entity Framework od warstwy logiki biznesowej jest jak najbardziej możliwe, tyle że wymaga nieco zachodu. Ja zazwyczaj deklaruje kontrakty DAL (Repository pattern, command/message itp.) w warstwie logiki biznesowej, a następnie implementuje je w warstwie DAL. Dla mnie największym problemem z Entity Framework są circular references i konieczność dostosowania obiektów domenowych do frameworka, co zazwyczaj kończy się implementacją anti-corruption layer. Nie pisze że są to dobre rozwiązania bo znacznie zwiększają nakład na wykorzystanie Entity Frameworka nawet dla zwykłych operacji CRUD zaimpelemtowanych zgodnie z zasadami DDD, jednak przy dzisiej popularności EF często nie ma wyboru.

Zgodnie z sugestią zrobiłem nowy projekt, w którym robię DBContext : IdentityDbContext<ApplicationUser>
I wszytko by się zgadzało jak by nie właśnie circular dependency
Bo z projektu Model muszę mieć referencje do Web.Persistance, bo w Modelu przechowuję klasy, ale też musze mieć referencje do głównego projektu MVC, którym jest Web żeby korzystać z ApplicationUser
A później znowu muszę mieć referencje z Web do Web.Persistance, bo tam mam ten DBContext, z którego muszę skorzystać w np. IdentityConfig w celu np. stworzenie usera.
Czytałem trochę o tym ale nie za bardzo wiem jak to naprawić

Poza tym jest jeszcze problem w połączeniu Usera z inną tabelką w bazie danych
bo żeby w DBContext użyć:

            modelBuilder.Entity<IdentityUser>()
            .HasKey(t => t.Id);

            modelBuilder.Entity<Character>()
                        .HasRequired(t => t.IdentityUser)
                        .WithRequiredPrincipal(t => t.Character);

musiał bym mieć w tabelce Character
public virtual IdentityUser IdentityUser<get; set;>
a, żeby móc to zrobić to znów potrzebuję referencje do Web żeby był dostępny IdentityUser

To jest nowy projekt więc w razie jakiś sugestii mogę zacząć od nowa tak czy tak muszę stworzyć bazę danych w której będzie między innymi tabelka Characters która będzie relacją jeden do jednego do tabelki Users czyli tej stworzonej automatycznie oraz relacja jeden do wielu między User a Friends.

Nie wiem jak to rozwiązać, może jestem zbyt głupi na to ale muszę to zrobić
Bardzo proszę o pomoc

Web.Persistence? Brzmi dziwnie, albo coś jest web albo persistence...

Tak czy siak, nie korzystaj z ApplicationUser w projekcie z DBContextem. Albo stwórz inną klasę, którą będziesz potem mapował, albo przenieś ApplicationUser do jakiegoś projektu, z którego będą korzystały oba pozostałe. Podobnie nie wpychaj IdentityUser do bazy, przecież to jest klasa, która ma zastosowanie po stronie weba, a nie w warstwie bazodanowej.

P.S. Jeden do jednego i wiele do jednego, to krotności związków encji. Relacje to np. Users i Friends.

Jak zamierzasz korzystac .NET Identity nie umieszczejąc IdentityUser w bazie danych?

Czarny Szczur napisał(a):

Jak zamierzasz korzystac .NET Identity nie umieszczejąc IdentityUser w bazie danych?

Nie zamierzam, nie korzystam, być może moje słowa dotyczące tego są bez sensu. Zakładam, że coś z AspNet w przestrzeni nazw nie powinno mieć związku z bazą.
Jedno wiem na pewno - nie korzysta się z projektu GUI w projekcie data access.