Czy tak powinno się pisać duże projekty?

Trafiłem ostatnio na to repozytorium i jestem w szoku. Nigdy nie widziałem bardziej przeinżynierowanego CRUDa (tak, wiem, że to tylko przykładowa aplikacja). Czy naprawdę tak powinno się pisać duże projekty? o_O

Celem tego repozytorium jest tylko zaprezentowanie jak powinny (według jego autora) wyglądać aplikacje wykorzystujące te zasady, które promują R. Martin, E. Evans, Jeffrey Palermo i wielu innych. W aplikacji występuje podział na funkcjonalności, a nie jakąś sztywną strukturę frameworka. Pierwsze spojrzenie na aplikacje powinno sugerować co robi, a nie jakich narzędzi użyto.

Nie przeglądałem jeszcze kodu, ale skoro sam piszesz ze jest to przykładowa aplikacja to o jakim przeinzynierowaniu mowa? Przeinzynierowanie występuje kiedy rozwiązujesz jakiś problem przy użyciu nadmiernych narzędzi/technik, podczas kiedy dałoby się to rozwiązać szybciej i prościej (prościej zarówno pod względem implementacji jak i potencjalnego rozszerzenia w przyszłości).

Cóż, kod jest dość kiepski, większość wymienionych skrótów które niby ma ten projekt prezentować: DDD, CQRS, ES, SOLID, Clean Code, UoW, są strasznie grubymi nićmi szyte, przez co wyszedł taki mały potworek.

Przegladnalem kod. Niby ma to prezentowac dobre praktyki a tu takie cos w kontrolerze. Az oczy krwawia.

if (!ModelState.IsValid)
            {
                return View(model);
            }

            var user = await _userManager.GetUserAsync(User);
            if (user == null)
            {
                throw new ApplicationException($"Unable to load user with ID '{_userManager.GetUserId(User)}'.");
            }

            var email = user.Email;
            if (model.Email != email)
            {
                var setEmailResult = await _userManager.SetEmailAsync(user, model.Email);
                if (!setEmailResult.Succeeded)
                {
                    throw new ApplicationException($"Unexpected error occurred setting email for user with ID '{user.Id}'.");
                }
            }

            var phoneNumber = user.PhoneNumber;
            if (model.PhoneNumber != phoneNumber)
            {
                var setPhoneResult = await _userManager.SetPhoneNumberAsync(user, model.PhoneNumber);
                if (!setPhoneResult.Succeeded)
                {
                    throw new ApplicationException($"Unexpected error occurred setting phone number for user with ID '{user.Id}'.");
                }
            }

            StatusMessage = "Your profile has been updated";
return RedirectToAction(nameof(Index));

Aventus napisał(a):

Przegladnalem kod. Niby ma to prezentowac dobre praktyki a tu takie cos w kontrolerze. Az oczy krwawia.

Co według Ciebie jest tu najgorzej zrobione? Dopiero zaczynam przygodę z ASP.NET i większość materiałów posiada takie rozbudowane akcje kontrolera.

Akcje kontrolera powinny mieć ogólnie jak najmniej logiki, a logiki biznesowej w ogóle nie mieć. Łamie to chociażby single responsibility principle. Kontrolery powinny być "głupie" - otrzymywać request, oddelegowacć go i po wykonaniu operacji zwrócić wynik. Można to wykonać na kilka sposobów, chociażby z wykorzystaniem wzorca mediator (który jest paradoksalnie używany w innych miejscach tego repo).

Do tego takie rzeczy jak ModelState.IsValid czy sprawdzanie, czy akcja jest wywoływana przez uprawnionego użytkownika, robi się przy użyciu filtrów.

Repo nie będę komentował, bo nie po to brałem urlop, żeby na hinduski kod patrzeć.

Mnie to pachnie przemysłem konferencyjnym. Urzekło mnie to EventRepository w EventStore no i to, że "Domain Model" nie ma nic wspólnego z eventSource. Dwie warstwy walidacji, nadpisanie operatorów, tak, żeby robiły to samo. Nie rozumie w ogóle, o co autorowi chodzi. Może chodzi o pokazanie struktury katalogów...?