[t.....r]

#programowanie #naukaprogramowania #csharp
Robię swój pierwszy webowy projekt z wykorzystaniem ASP.NET Core, staram się robić go według DDD. Zastanawiam się jak powinien zaimplementować repozytoria dla relacji wielu do wielu, czyli UserReviewApproved i UserReviewDisapproved. Póki co umieściłem metody w repozytorium dla Reviews, jedna z funkcji wygląda tak:

 public async Task AddUserReviewApprovedAsync(Guid userId, Guid reviewId)
 {
 var user = await _userRepository.GetByIdAsync(userId);
 if (user == null)
 return;
 var review = await GetByIdAsync(reviewId);
 if (review == null)
 return;
 var reviewUserApproved = new ReviewUserApproved(user, review);
 _context.ReviewUserApproved.Add(reviewUserApproved);
 await _context.SaveChangesAsync();
 }

I tutaj pojawiają się pytania o poprawnej takiego rozwiązania. A więc:
1. Czy dla UserReviewApproved i UserReviewDisapproved powinienem stworzyć nowe repozytoria.
2. Czy poprawne wzajemne wykorzystywanie się repozytoriów tak jak w przykładzie z walidacją nulla przy userze.
3. Jeśli nie to jak mam walidować nulle, w repozytoriach, serwisach (przesyłanie gotowych obiektów do repozytorium) czy może po prostu zdać się na bazę danych (not null).

[t.....r]

@teaperr: Jak tak sobie teraz myślę to zostawienie walidacji bazie danych wydaje się najbardziej rozsądne, ale skoro już się tak rozpisałem, to poczekam na wasze opinie. ( ͡° ͜ʖ ͡°)

[Dworki]

@teaperr: Nie ma potrzeby pobierania usera i review, ustawiasz Id i tyle. Jeżeli coś będzie nie tak to poleci 500 do klienta i jest to dobre rozwiązanie. Rozumiem jednak, że reviewId pochodzi od klienta i może w jakiś sposób być niepoprawne. Tak więc przed przekazaniem do repo reviewId powinieneś je sprawdzić, np. w serwisie lub kontrolerze, zależy gdzie masz logikę.

Tak więc repo:

public async Task AddUserReviewApprovedAsync(Guid userId, Guid

[Dworki]

@Dworki: Tak dodatkowo to await _context.SaveChangesAsync(); dałbym do UnitOfWork, żeby mieć możliwość sterowania zapisem z serwisu/kontrolera.

Nie ma potrzeby pobierania usera i review, ustawiasz Id i tyle. Jeżeli coś będzie nie tak to poleci 500 do klienta i jest > to dobre rozwiązanie.

To wyżej tyczy się repo, bo walidację tak jak napisałem robisz poziom niżej w serwisie/kontrolerze i zwracasz odpowiednie kody błędów, żeby klient wiedział co się dzieje. Jeżeli

[t.....r]

@Dworki: Dzięki wielkie, dokładnie o taką odpowiedź mi chodziło :). Mógłbyś mi jeszcze podpowiedzieć jak najlepiej rozwiązać pobieranie obiektów posiadających w sobie kolekcje innych obiektów. Czy optymalizacja taka jak na poniższym kodzie ma jakiś sens czy przestać się wygłupiać i od razu wyrzucać całe obiekty?

 public async Task GetByIdWithoutOpinionsAsync(Guid id)
 {
 var review = await _context.Reviews.Include(c => c.User).Include(c=>c.Course)
 .SingleOrDefaultAsync(c => c.Id

[Dworki]

@teaperr: W net core za dużo nie robiłem, ale pobierałbym tylko to co potrzebuje.(w starym ef jest lazy loading, który pobiera to do czego się odwołasz) Jeszcze chciałem dodać do tego wcześniejszego dodawania Review, to jeżeli robisz DDD, to bardziej logiczne byłoby pobranie Usera, w którym masz metodę ApproveReview(Guid reviewId). W tej metodzie dodanie do kolekcji ApprovedReviews i później zapisanie zmian SaveChanges().

[t.....r]

@Dworki: Rozumiem, dzięki jeszcze raz.