Implementacja najlepszych praktyk .NET Full Webdev na przykładzie własnej aplikacji pisanej po godzinach

Odpowiedz Nowy wątek
2019-02-09 16:51
4

Mój pierwszy post więc w ramach przywitania się z community od razu podzielę się wiedzą i swoją pracą ;)

Na moim koncie gh:
[email protected]://github.com/piotr-mamenas/performance-app

Udostępniłem aplikacje nad którą pracuję po godzinach od dwóch lat, apka składającą się w sumie z 10 assembly, w tym backendowego Serwisu RESTowego w Web Api 2 oraz aplikacji Postback (wspomaganej akcjami SPA w Ajax) napisanej w MVC 5. Służyła mi ona do pogłębiania wiedzy odnośnie architektury aplikacji. Generalnie jest to ekstrakt najlepszych praktyk sugerowanych przez guru .NET developmentu takich jak: Dino Esposito, Martin Fowler, Robert C. Martin czy Gary McLean Hall i wiele wielu innych których chętnie i fanatycznie czytam :)

Co zatem znajdziecie w środku?

  1. Najlepsze praktyki z zakresu Domain Driven Development z wykorzystanie jednego Bounded Context zawierającego kilkanaście agregatów Encji z pojedyńczym Entity Root per Agregat, odpowiadającym za tranzakcyność. Ponadto podział na Base Entities, Relationship Entities oraz ValueObjects. Nie-anemiczny model domeny (Encje domenowe zawierają logikę biznesową),
  2. Podział na tzn Domain Layer, Infrastructure Layer, Service Layer i Presentation Layer wraz z zastosowaniem reguł SOA
  3. Zastosowane najlepsze praktyki z zakresu SOLID. Patternów Go4 (np Facade, Singleton, Builder, Decorator, Strategy), DRY, KISS oraz innych.
  4. Na frontendzie kod Javascriptowy jest podzielony na oddzielne komponenty izolowane Revealing Module Pattern opartej na Closures. Jeśli chodzi o strukturę strony to głównie jest to Bootstrap 3 z mieszanką flexa.
  5. Dependency Injection z wykorzystaniem kontenera Ninject w celu wtrzykiwania Repozytoriów i Serwisów bezpośrednio do Konstruktorów Kontrolerów.
  6. Implementacja tranzakcyjności operacji poprzez patterny Unit of Work i Generic Repository z użyciem Entity Framework 6 podpiętej pod bazę relacyjną. Z podziałem na zewnętrzne konfiguracje oraz przeładowaniami konfiguracji dla Base Entities.
  7. Najlepszymi praktykami w serializacji danych z użyciem DTO, View Modeli oraz mapowania obiektów AutoMapperem.
  8. Authentykacje i Autoryzacje opartą na Identity Framework 2 oraz ciasteczkach.

Jeśli ktoś się uczy lub chciałby po prostu poszerzyć swoją wiedzę z zakresu dobrych praktyk to jest to miejsce w którym można podpatrzeć rozwiązania implementacyjne i mam nadzieję nauczyć się czegoś nowego ;)

Domain Driven Design ;) - Aventus 2019-02-09 18:11

Pozostało 580 znaków

2019-02-21 20:30
0
WeiXiao napisał(a):

Jak ludzie radzą sobie z Includami używając repo?

O ile dobrze Cie zrozumiałem to:
ja widziałem coś takiego jako parametr metody repo.

List<Expression<Func<TEntity, object>>> includeProperties

A w tej metodzie

includeProperties.ForEach(i => { query = query.Include(i); });

gdzie Query to było

IQueryable<TEntity> 
edytowany 2x, ostatnio: szydlak, 2019-02-21 20:34

Pozostało 580 znaków

2019-02-21 20:34
0

@szydlak:

A jak pójdziemy krok dalej? :D

.Include(x => x.Something)
.ThenInclude(x => x.SomethingOtherA)
.Include(x => x.Something)
.ThenInclude(x => x.SomethingOtherB)
.Include(x => x.OtherSomething)
.ThenInclude(x => x.WTF)
.ThenInclude(x => x.WTF_2)
edytowany 2x, ostatnio: WeiXiao, 2019-02-21 20:35
Nie sprawdzałem na Core. Ja to widziałem w EF 6. - szydlak 2019-02-21 20:35

Pozostało 580 znaków

2019-02-21 22:46
0
WeiXiao napisał(a):

Dlaczego to jest słabe? testujesz realną ścieżkę w aplikacji

Bo higiena wymaga, aby logika biznesowa była niezależna od infrastruktury. Wtedy można ją przetestowania jednostkowo bez cudowania. I nawet przenieść do innego rodzaju aplikacji, bez problemu.

Test controller logic in ASP.NET Core

Jaki zysk daje zepsucie architektury i testowanie kontrolerów, zamiast implementacji zgodnie z MVC i umieszczeniem logiki w modelu, a nie w kontrolerach?
Nie oszczędzi się w ten sposób na ilości kodu ani na szybkości jego pisania. Więc jaki jest cel?

Tak samo z fakowaniem db do testów - w 99% nie ma sensu używać prawdziwej, ale czasem zdarzy się, że np. po zmianie bazy takie testy wykryją Ci jakiegoś buga typu: niestandardowy znaczek nagle nie chce się dać zapisać, a wcześniej działał i był używany.

No i jak niby sprawdzisz zapis problematycznych znaków do bazy w testach jednostkowych?

szydlak napisał(a):

ja widziałem coś takiego jako parametr metody repo.

List<Expression<Func<TEntity, object>>> includeProperties

Tylko czemu logika biznesowa ma mówić repozytorium jak korzystać ze źródła danych? Czemu logikę biznesową coś takiego jak include w ogóle ma obchodzić? Przecież to jest cieknąca abstrakcja, nic więcej.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
edytowany 1x, ostatnio: somekind, 2019-02-21 22:46

Pozostało 580 znaków

2019-02-21 23:05
0

@somekind:

Jaki zysk daje zepsucie architektury i testowanie kontrolerów, zamiast implementacji zgodnie z MVC i umieszczeniem logiki w modelu, a nie w kontrolerach?

Dlaczego zepsucie? nie możesz mieć zgodnie z MVC oraz mieć możliwości testowania całego flow?

Pozostało 580 znaków

2019-02-22 02:02
1
WeiXiao napisał(a):

Dlaczego zepsucie? nie możesz mieć zgodnie z MVC oraz mieć możliwości testowania całego flow?

Mogę, tylko po co sobie tak życie utrudniać?

Jeśli w kontrolerach nie ma żadnej logiki, to nie ma tam czego testować jednostkowo, więc nie ma sensu pisać takich testów (które wymagają więcej zachodu, bo trzeba mockować HttpContext i inne pierdoły.).
Cała logika jest w Modelu, który nie ma żadnych infrastrukturalnych zależności i banalnie się go testuje jednostkowo, bo nie trzeba mockować dziwnych rzeczy.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-02-22 15:43
0

Cała logika jest w Modelu, który nie ma żadnych infrastrukturalnych zależności i banalnie się go testuje jednostkowo, bo nie trzeba mockować dziwnych rzeczy.

@WeiXiao

Dlatego argument bo ropzytorium mogę "mockować" w testach jest w większości pospolitych przypadkach delikatnie mówiąc bez sensu...

Albo testujesz domenę jednostokowo albo serwis nad domeną z repozytorium funkcyjnie-akceptacyjnie lub jak kto woli "integracyjnie"...

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0