Witam
Zacząłem Tworzyć projekt MVC
posiadam solucję a w nim 3 projekty: bask.Model, bask.Service, bask.Web
w projekcie Model mam zrobione klasy do Code First oraz DBContext do tych klas
zaś w projekcie Web mam aplikację MVC właśnie z Authentication typu Individual user accounts
i w tym miejscu mam pytanie, w jaki sposób połączyć te bazy danych, bo te automatycznie tworzone posiadają np. encję z Userami a w tej, co sam tworzę mam encję, która ma mieć relację właśnie z tą tabelą i nie wiem jak zrobić tą relację.
- Rejestracja:ponad 10 lat
- Ostatnio:ponad 6 lat
0
C# 0
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ć.
- Rejestracja:około 17 lat
- Ostatnio:3 dni
- Lokalizacja:Wrocław
0
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.
0
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.
No ja ktoś lubi pisanie wrapperów na wrappery, to EF jest idealnym dla niego rozwiązaniem. Tylko nie na tym chyba programowanie polega.
Ale jak masz CRUD to nie używasz DDD. DDD używasz gdy domena jest skomplikowana. Gdy masz CRUDa to znaczy że nie jest. Nie musisz i nie powinieneś robić całego systemu w jednej architekturze, jeśli do danej części dana nie pasuje.
- Rejestracja:ponad 10 lat
- Ostatnio:ponad 6 lat
0
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
edytowany 3x, ostatnio: donex93
- Rejestracja:około 17 lat
- Ostatnio:3 dni
- Lokalizacja:Wrocław
0
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.
- Rejestracja:około 17 lat
- Ostatnio:3 dni
- Lokalizacja:Wrocław
0
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.
edytowany 1x, ostatnio: somekind