Dobre praktyki .NET

Odpowiedz Nowy wątek
2018-02-28 22:16
0

Cześć, piszę sobie już od jakiegoś roku w ASP.NET MVC i chciałbym dopytać się Was o dobre praktyki.
Dążę do tego żeby mój kod był jak najlepszej jakości, dlatego chciałbym was prosić o wskazanie popularnych błędów nowicjuszy i zaproponowanie dobrych zasad których warto według was przestrzegać. Chętnie wysłucham opinii starszych kolegów chociażby byłby to proste komentarze typu "pisz mało kodu w kontrolerze, logikę umieszczaj w modelu".

Pozostało 580 znaków

2018-02-28 23:35
2

pisz mało kodu w kontrolerze, logikę umieszczaj w modelu

czekałem na ten post - marmite 2018-03-01 00:13

Pozostało 580 znaków

2018-03-01 05:57
2

SOLID, YAGNI, DRY, GRASP, Separation of concerns.

edytowany 1x, ostatnio: error91, 2018-03-01 05:59

Pozostało 580 znaków

2018-03-01 09:29
5
  1. Zrób z modelu osobny projekt;
  2. Twórz w modelu mikroserwisy dziedziczące po interfejsach, które samodzielnie zdefiniujesz. Po co to jest? Patrz punkt 4 oraz dodatkowo łatwiejsze testowanie modelu i mockowanie serwisów;
  3. Twórz logikę biznesową w tychże mikroserwisach;
  4. Używaj kontenera IoC żeby zbindować interfejsy do odpowiednich mikroserwisów, żeby nie musieć bawić się w ręczne wstrzykiwanie zależności, np. do kontrolerów;
  5. Nie czytaj hinduskich tutoriali;
  6. Unikaj staticów czy singletonów na rzecz możliwości ustawienia czasu życia obiektu w kontenerze IoC;
  7. Obiekty z modelu przekazuj do wyższych warstw za pomocą DTO;
  8. Nigdy nie pchaj encji do widoku;
  9. Wzorzec repozytorium: bardzo często niepotrzebny. Można go zastąpić kontekstowym wykorzystaniem ORM'a w serwisach zamiast trzymania globalnego repo albo kilku repo spinanych np. w unit of work. Dla mnie jest to prawie zawsze przerost formy nad treścią;
  10. Nie czytaj hinduskich tutoriali;
  11. Ucz się grać na gitarze samodzielnie jak Jimmy Page.
  12. Nie używaj Entity Frameworka;
  13. Używaj NHibarnate'a albo Dappera;
  14. Kup starego Peugeota.
edytowany 3x, ostatnio: grzesiek51114, 2018-03-01 10:06
Dodałbym tylko, żeby nie czytać hinduskich tutoriali ;) - mstl 2018-03-01 09:32
Mikroserwis to raczej co innego. :P - somekind 2018-03-01 11:51
@somekind: a sumie tak to nazywam, bo staram się pisać małe serwisy czyli mikro-serwisy ;) - grzesiek51114 2018-03-01 12:43

Pozostało 580 znaków

2018-03-01 09:41
Smutny Orzeł
0

Możesz zaargumentować dlaczego nie używać Entity Framework?

Pozostało 580 znaków

2018-03-01 09:46
0

http://commitandrun.pl/2016/0[...]work_nie_jest_dobrym_wyborem/

Poza tym kiedy poużywałem dłużej NHibernate'a to już w sumie mógłbym do EF nie wracać, nie mówiąc już o tym, że EF buduje koszmarne zapytania i jest naprawdę powolny w stosunku do chyba całej reszty ORM'ów.

PS: Dalej jest tam tylko left join? Już nawet sam sposób w jaki zapisuje się left joina w EF (bo nie można po prostu napisać .Left.Join(), prawda?) plus stosowanie różnych includów i mamy niezły ROTFL. Nie to co prostota NH, choć przyznaję: NH ma troszkę większy próg wejścia niż EF ale później oddaje to z nawiązką.

edytowany 4x, ostatnio: grzesiek51114, 2018-03-01 09:55

Pozostało 580 znaków

2018-03-01 09:50
Smutny Orzeł
0
grzesiek51114 napisał(a):

http://commitandrun.pl/2016/0[...]work_nie_jest_dobrym_wyborem/

Poza tym kiedy poużywałem dłużej NHibernate'a to już w sumie mógłbym do EF nie wracać, nie mówiąc już o tym, że EF buduje koszmarne zapytanie i jest naprawdę powolny w stosunku do chyba całej reszty ORM'ów.

PS: Dalej jest tam tylko left join? Już nawet sam sposób w jaki zapisuje się left joina w EF plus stosowanie różnych includów i mamy niezły ROTFL. Nie to co prostota NH, choć przyznaję: NH ma troszkę większy prób wejścia niż EF ale później oddaje to z nawiązką.

U mnie w firmie stosuje sie w EF i raczej narzekaja na NH, ale dzieki za info, bede musial sie zapoznac rowniez z NH i potestowac :)

Pozostało 580 znaków

2018-03-01 09:52
0

@Smutny Orzeł
Polecam. Poza tym od dawna odnoszę dziwne wrażenie, że w EF dużo łatwiej polecieć z N+1 select'em, co jest rzecz jasna kolejną jego wadą.

edytowany 2x, ostatnio: grzesiek51114, 2018-03-01 09:52

Pozostało 580 znaków

2018-03-01 10:29
Błękitny Orzeł
0

Logika w modelu? Serwisy wstrzykiwane od modeli?
Czy to jest DDD i Domain Services?

Czy kontrolery powinny zwracać te modele czy czyste DTO?

Pozostało 580 znaków

2018-03-01 10:34
0

Logika w modelu?

Tak. Przecież nie w kontrolerach. :-)

Czy to jest DDD i Domain Services?

A nie wiem. Po prostu takie rozplanowanie projektu jest dla mnie wygodne i racjonalne. Można to nazwać jakkolwiek.

Czy kontrolery powinny zwracać te modele czy czyste DTO?

Komunikacja pomiędzy warstwami modelu za pomocą DTO, a z widokami za pomocą Viewmodeli.

edytowany 1x, ostatnio: grzesiek51114, 2018-03-01 10:34

Pozostało 580 znaków

2018-03-01 10:59
Błękitny Orzeł
0
grzesiek51114 napisał(a):

Logika w modelu?

Tak. Przecież nie w kontrolerach. :-)

A to nie w warstwie z serwisami? :P

Czy kontrolery powinny zwracać te modele czy czyste DTO?

Komunikacja pomiędzy warstwami modelu za pomocą DTO, a z widokami za pomocą Viewmodeli.
Wszystkie warstwy powinny komunikować się ze sobą tym samym DTO?

Repozytorium(infrastruktura) => Domena => Serwisy => API ten sam DTO?

Czy WebAPI powinno zwracać modele nazwane(zlokalizowane w folderze) DTO czy ViewModel?
Oczywiście przypadki
1) API dostarcza danych tylko do jednego klienta(frontend) - więc modele są dostosowane do funkcjonalności frontu.
W takim razie zwraca DTO czy ViewModele?

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