4 warstwy modelu i dzielenie kodu na moduły

0

Czy ktoś może mi wyjaśnić ze swojego doświadczenia, jakie są zalety oraz wady stosowania 4 warstw w każdym module zamiast dzielenia tego w ten sposób.

Tego pierwszego podejścia w ogóle nie rozumiem.

Moduł 1 Infrastructura
  -- Any ORM or WebServices

Moduł 2 Application
  -- Transfer of money

Moduł 3 Dommain
  -- Account

Albo

Moduł 1 Core
  -- Application
     --etc
  --Dommain
    --etc

Moduł 2 Infrastructura
   -etc

Wydłubałem na szybko pseudo kod. Aby to zobrazować.

https://github.com/Webjarek/4Programers

4

Pierwsze z brzegu powody

  • testowanie logiki biznesowej: jeśli wymieszasz kod rozmawiający z bazą, z kodem wyliczającym np. wypłatę dla pracownika, to trudno jest przetestować czy wypłata jest wyliczana poprawnie.
  • czytelność kodu i konwencja - nowy programista dołączający do projektu szybciej się wdroży, bo od razu rozpozna pewne "standardy" w projekcie
  • łatwość modyfikacji - masz aplikację desktopową, ale w pewnym momencie management stwierdza, że główną jej funkcjonalność chcieliby mieć też na stronie/telefonie/lodówce - gdy masz osobną warstwę biznesową, to łatwiej będzie to przenieść na inną platformę i "opakować" nową infrastrukturą lub widokami.
0

Czyli to, co wrzuciłem na gita jest jak najbardziej poprawne ??

No i jak to się ma do tych dwóch innych podjeść.?

1

Czyli to, co wrzuciłem na gita jest jak najbardziej poprawne ??

Nie ma poprawne / niepoprawne. To nie pisanie dyktanda w podstawówce. Jak napiszesz większą aplikację używając danego rozwiązania to samemu będziesz mógł wyciągnąć wnioski na przyszłość (a potem nabierzesz własnej intuicji oraz będziesz w stanie zrozumieć czytaną teorię). To jedyny skuteczny sposób nauki.

stosowania 4 warstw w każdym module

Niekoniecznie to musi tak wyglądać. Można równie dobrze pomyśleć sobie, że 1 moduł = 1 warstwa (albo 1 moduł: 5 warstw, albo 10 modułów - jedna warstwa). Chodzi o to, że jak masz duży projekt to ogólnie dobrze zrobić jakieś warstwy, jakiś podział - z powodów, o których pisze @john_klamka a jaki to będzie podział to już jest dyskusyjne, zależy od podejścia.

Ważne, żeby izolować warstwy w ten sposób, żeby łatwo było można podmienić jedną z drugą (np. ta sama logika biznesowa, inny interfejs, czyli zostawiamy warstwę logiki ale podmieniamy interfejs). I tutaj np. widzę wadę rozwiązania "4 warstw w jednym module" - bo w ten sposób nie da się łatwo podmienić warstwy interfejsu z jednego modułu, bo masz cały komplet naraz.

No ale z drugiej strony - jeśli masz w jednym jednym katalogu wszystkie warstwy, może ułatwić to pracę przy zmianie jakiegoś konkretnego modułu (jako całości), bo robisz zmiany w jednym katalogu, a nie latasz po całym projekcie. Ale to już zależy od stylu pracy w danym projekcie.

0
LukeJL napisał(a):

Ważne, żeby izolować warstwy w ten sposób, żeby łatwo było można podmienić jedną z drugą (np. ta sama logika biznesowa, inny interfejs, czyli zostawiamy warstwę logiki ale podmieniamy interfejs). I tutaj np. widzę wadę rozwiązania "4 warstw w jednym module" - bo w ten sposób nie da się łatwo podmienić warstwy interfejsu z jednego modułu, bo masz cały komplet naraz.

Jeśli chodzi o interface jako UI to nie widzę problemu, bo to będzie oddzielny moduł prezentacji. Chodzi mi przede wszystkim o możliwość wydzielenia elementów. Co moim zdaniem pomoże w pracy w zespole oraz umożliwi łatwiejsze ponowne użycie części kodu.

Zawsze wydawało mi się, że moduł to część kodu, która ma jakąś pojedynczą odpowiedzialność jako całość.

Dlatego nie rozumiem czegoś takiego:

Moduł 1 Infrastructura
  -- Any ORM or WebServices

Moduł 2 Application
  -- Transfer of money

Moduł 3 Dommain
  -- Account

Przecież i tak nie wymienie warstwy aplikacji ani domeny bo jedno jest zależne od drugiego.

1
WebJarek napisał(a):

Zawsze wydawało mi się, że moduł to część kodu, która ma jakąś pojedynczą odpowiedzialność jako całość.

Dlatego nie rozumiem czegoś takiego:

Moduł 1 Infrastructura
  -- Any ORM or WebServices

Moduł 2 Application
  -- Transfer of money

Moduł 3 Dommain
  -- Account

Przecież i tak nie wymienie warstwy aplikacji ani domeny bo jedno jest zależne od drugiego.

Tak jak napisałeś moduł to część kodu, która ma pojedynczą odpowiedzialność. W skali makro moduł infrastrukturalny zawiera kod, który ma jedną odpowiedzialność - komunikację z bazą / webserwisami. Ten moduł nie interesuje się tym co dane oznaczają, on je tylko przerzuca do następnej warstwy. Moduł aplikacji zajmuje się tylko liczeniem kasy, nie interesuje go gdzie są przechowywane dane, ma więc też tylko jedną odpowiedzialność - liczyć tak, żeby kasa się zgadzała :P

0
john_klamka napisał(a):

Przecież i tak nie wymienie warstwy aplikacji ani domeny bo jedno jest zależne od drugiego.

Tak jak napisałeś moduł to część kodu, która ma pojedynczą odpowiedzialność. W skali makro moduł infrastrukturalny zawiera kod, który ma jedną odpowiedzialność - komunikację z bazą / webserwisami. Ten moduł nie interesuje się tym co dane oznaczają, on je tylko przerzuca do następnej warstwy. Moduł aplikacji zajmuje się tylko liczeniem kasy, nie interesuje go gdzie są przechowywane dane, ma więc też tylko jedną odpowiedzialność - liczyć tak, żeby kasa się zgadzała :P

Nie rozumiesz mnie, chodzi mi konkretnie o sytuację, kiedy kod jest rozwijany w ten sposób.

Moduł 1 Infrastructura
  -- WebServices
  -- DAL
  -- Repo Account
  -- Repo Bill

Moduł 2 Application
  -- Transfer of money
  -- Print Bill

Moduł 3 Dommain
  -- Account
0

Jak dla mnie to to jest zwykły i dość oczywisty podział na warstwy.

0

Powiedzmy, że aplikacją jest sklep internetowy. A teraz dzwoni do mnie kolega i prosi mnie, abym mu przesłał moduł odpowiedzialny za koszyk tego sklepu. Albo jeszcze inaczej, zlecasz stworzenie komuś z zewnątrz modułu, który będzie odpowiedzialny za integrację z magazynem albo jakimś dropshipongiem. No i w tym momencie robienie z wastw oddzielnych modułów (bibliotek dll) nie bardzo zda swoje zadanie, a raczej będzie przeszkadzać.

3

No nie, w tym momencie poza modularyzacją poziomą (warstwami) potrzebujesz też pionowej (moduły funkcjonalne).
Warstwy lepiej robić jako oddzielne dll, bo wtedy łatwiej zachować ich separację (np. nie używać rzeczy związanych z HTTP w logice biznesowej). Moduły funkcjonalne to mogą być oddzielne projekty składające się z kilku dll-warstw, a mogą to nawet być oddzielne (mikro)serwisy.

0

Aha, czyli kolega tworzy nowy projekt (Solution) z tymi samymi nazwami (warst) po czym je scalamy... ??? Ewentualnie wymieniamy infrastrukturę. Czy o to ci chodzi ?? Pokaż to na przykładze

1

Ale po co scalać? Możesz przecież podpiąć do innego projektu kilka dll. Albo korzystać z niego jak z usługi webowej i w ogóle nie przejmować się jego architekturą.

0

No ale jeśli mam 2 solution i w każdej 3 warstwy (DLL) w tym infrastrukturę. A teraz chcę wydzielić.

Do pierwszej solution w projekcie (Module funkcyjnym) te 3 DLL z solucji drugiej. To jak zadbać o spójność infrastruktury np. dostępu do bazy, tak by nie powtarzać kodu w obu warstwach infrastruktury.

1

No to możesz mieć warstwę dostępu do danych jako jedną bibliotekę dll, z której korzystają oba projekty.

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