Zorientowana na architekturę (strukturę) a struktura projektu zorientowana na cechy

14

Projekt, w który zaangażowałem się, ma strukturę plików / folderów zorientowaną na architekturę:

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

Jest to jasne z architektonicznego punktu widzenia systemu (zaproponowany przez zespół programistów).

Jest to struktura zorientowana na funkcje, zaproponowana przez zespół projektantów:

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

Ten wariant jest bliższy projektantom i jasno opisuje funkcję, którą należy wdrożyć.

Nasze zespoły rozpoczęły świętą wojnę: jakie jest najlepsze podejście. Czy ktoś mógłby nam pomóc i wyjaśnić wady i zalety pierwszego i drugiego. Może istnieje trzeci, który jest bardziej przydatny i korzystny dla nas obu.

Dziękuję Ci.

Zzz
źródło
Nie rozumiem żadnej struktury - jaka jest różnica między zdarzeniami a żądaniami (a zatem modułami obsługi zdarzeń i modułami obsługi żądań)?
Peter Boughton,
1
Bardzo jasne pytanie - i neutralne!
Michael K,
1
Z punktu widzenia skalowalności drugie podejście powinno być dość łatwe do skalowania w poziomie.
CodeART

Odpowiedzi:

11

Głosowałbym na drugą. W pierwszej strukturze procedury obsługi zdarzeń dla FeatureAsą całkowicie niezwiązane z procedurami obsługi zdarzeń dla FeatureB. Wygląda na to, że programiści będą pracować nad jedną funkcją naraz, a jeśli pracujesz nad FeatureXżądaniem, jest o wiele bardziej prawdopodobne, że będziesz musiał zmodyfikować moduł FeatureXobsługi żądań niż, powiedzmy, FeatureZżądanie.

Nawiasem mówiąc, uwielbiam to, jak zadałeś to pytanie z neutralnego punktu widzenia.

Uwaga do samodzielnego wymyślenia imienia
źródło
1
+1 z jednym zastrzeżeniem: w przypadku małych projektów drugi spowoduje, że struktura plików będzie większa niż liczba plików, w których można go wstawić.
Michael K,
@Michael zgadzam się, ale w tym przypadku jest to duży projekt.
Zzz
1
+1: Jeśli kiedykolwiek będziesz musiał rozmawiać z użytkownikiem / klientem, terminologia może być dość spójna.
Steven Evers,
4

Zawsze czułem się bardziej komfortowo z drugim podejściem, ale zawsze mam „funkcję” zwaną ogólną lub wspólną dla prawdziwie wspólnych / podstawowych klas.

Podejście drugie utrzymuje naprawdę osobne rzeczy oddzielnie, ale bez „wspólnego” obszaru czasami dzieli rzeczy na obszary, które nie pasują dobrze.

Rachunek
źródło
+1 za wspólne i ogólne (każdy projekt ma ogólne narzędzia, narzędzia ...)
Zzz
3

Dlaczego twórcom funkcji zależy na szczegółach implementacji? Jeśli jest to separacja stron argumentu, myślę, że odpowiedź jest jasna. Ludzie wymyślający pomysły / funkcje nie określają struktury plików potrzebnej przez implementatorów.

Jest to szczególnie ważne, gdy implementacja funkcji obejmuje wiele bibliotek DLL, plików exe, baz danych lub innych elementów oprogramowania.

John Fisher
źródło
1
Zastanawiałem się nad tym, ale pomimo tego, że wszystkie inne rzeczy są jednakowe, drugie podejście ma pewne wyraźne zalety filozoficzne dla wszystkich, z wyjątkiem najbardziej trywialnych zastosowań. Przynajmniej jest to dobra sugestia.
Robert Harvey
@Robert Harvey: Jeśli mówisz o ideologicznej organizacji projektu, musiałbym wymyślić nową odpowiedź. Wygląda jednak na to, że mówią o plikach zawierających kod ...
John Fisher,
Kluczem jest podział funkcji na wyraźne segmenty. W przypadku wszystkich aplikacji z wyjątkiem najmniejszych potrzebujesz takiej organizacji, bez względu na to, czy chodzi o strukturę folderów, strukturę klas czy konwencję przestrzeni nazw.
Robert Harvey
1
@Robert Harvey: Co z problemami z kompilacją i wdrożeniem? Co powiesz na prostsze rzeczy, takie jak możliwość używania IDE do pisania i debugowania kodu? Niektóre z tych rzeczy powinny mieć ogromny wpływ na struktury folderów.
John Fisher,
1

Muszę zgodzić się z drugim podejściem, biorąc pod uwagę dwie opcje. Pierwszy wygląda jak amorficzna kropelka. Przynajmniej drugi ma jakiś kształt.

To naprawdę zależy od tego, jak duży jest projekt. Jeśli „funkcje” są duże, każda z nich potrzebuje osobnego wiadra.

Robert Harvey
źródło
1

Nie rozumiem używanej terminologii, ale i tak spróbuję odpowiedzieć, ponieważ obie struktury wydają się być niewłaściwym podejściem.

O ile nie masz tylko kilku funkcji, musisz pogrupować je w kategorie - i to nie wydaje się być pokrywane w żadnym projekcie (chyba że taki jest Node1, ale sugeruje „cały X projektu” w przeciwnym razie i zastanawiam się, czy to WTF - czy jest Node2?)

Mogę rozważyć coś takiego:

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

Albo to:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events


Ale obaj przyjmują założenia, które mogą być całkowicie nie na miejscu - jeśli możesz zaktualizować swoje pytanie o więcej szczegółów, mogę zmienić zdanie. :)

Peter Boughton
źródło