Архітектура (структура) орієнтована на особливості структури проекту

14

Я брав участь у проекті, має структуру файлів / папок проекту, орієнтовану на архітектуру:

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>
    |____ ...

Це чітко з архітектурної точки зору системи (запропонована командою розробників).

Це конструктивна структура, запропонована командою дизайнерів:

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>
    |____ ...

Цей варіант наближений до дизайнерів, і він чітко описує особливість, яку потрібно реалізувати.

Наші команди розпочали святу війну: який найкращий підхід. Невже хтось може нам допомогти та пояснити мінуси та плюси першого та другого. Можливо, є третя, яка є кориснішою і кориснішою для нас обох.

Дякую.

project-structure

— Zzz
джерело

Я не розумію жодної структури - яка різниця між подіями та запитами (а отже, обробниками подій та обробниками запитів)?

— Пітер Бауфтон

1

Дуже чітке запитання - і нейтральне теж!

— Майкл К

1

З точки зору масштабованості, другий підхід повинен бути досить легко масштабувати горизонтально.

— CodeART

11

Я би проголосував за другого. У першій структурі обробники подій для "" FeatureAабсолютно не пов'язані з обробниками подій для FeatureB. Схоже, розробники працюватимуть над однією функцією одночасно, і якщо ви працюєте над FeatureXзапитом, набагато більше шансів, що вам потрібно буде підправити FeatureXобробник запиту, ніж, скажімо, FeatureZзапит.

До речі, мені подобається, як ви задали це питання з нейтральної точки зору.

— Зауважте, щоб самостійно придумати ім’я
джерело

1

+1 з одним застереженням: для невеликих проектів другий призведе до більшої структури файлів, ніж є файли для їх розміщення. Я використовував би перший для них.

— Майкл К

@Michael я згоден, але в цьому випадку це великий проект.

— Zzz

1

+1: І якщо вам колись доведеться спілкуватися з користувачем / клієнтом, то термінологія може бути досить послідовною.

— Стівен Еверс

4

Мені завжди було зручніше з другим підходом, але у мене завжди є "особливість", яка називається загальною або загальною для справді спільних / базових класів.

Підхід два тримає по-справжньому окремі речі окремо, але без "загальної" області він іноді розділяє речі на сфери, які їм не підходять добре.

— Білл
джерело

+1 для загального та загального (кожен проект має загальні утиліти, інструменти ...)

— Zzz

3

Чому автори винаходу переймаються деталями реалізації? Якщо це розділення між сторонами аргументу, то я думаю, що відповідь зрозуміла. Люди, що вигадують ідеї / функції, не визначають структуру файлів, яка потрібна реалізаторам.

Це особливо важливе питання, коли реалізація функції охоплює декілька dll, exes, баз даних чи інших програмних частин.

— Джон Фішер
джерело

1

Я думав про це, але, за інших рівних обставин, другий підхід має деякі чіткі філософські переваги для всіх, крім самих тривіальних застосувань. Принаймні, це гарна пропозиція.

— Роберт Харві

@ Роберт Харві: Якщо ви говорите про ідеалогічну організацію проекту, то мені знадобиться придумати нову відповідь. Однак, це здається, що вони говорять про файли, що містять код ...

— Джон Фішер

Ключовим моментом є розділення функцій на різні відра. Для всіх, крім найменших застосунків, вам знадобиться така організація, як ця, незалежно від того, чи ви маєте на увазі структуру папок, структуру класу або конвенцію про область імен.

— Роберт Харві

1

@ Роберт Харві: Що з питаннями побудови та розгортання? Як щодо простіших речей, таких як просто можливість використовувати IDE для написання та налагодження коду? Деякі з цих речей повинні мати потужний вплив на структури папок.

— Джон Фішер

1

Доведеться погодитися з другим підходом, враховуючи два варіанти. Перший просто схожий на аморфну крапку. Принаймні другий має певну форму.

Це дійсно залежить від того, наскільки великий проект. Якщо "особливості" великі, кожному з них потрібно власне окреме відро.

— Роберт Харві
джерело

1

Я не розумію термінології, яку ви використовуєте, але спробую відповісти все одно, оскільки обидві структури здаються неправильним підходом.

Якщо у вас є лише кілька функцій, вам потрібно згрупувати їх за категоріями, - і це, здається, не обслуговується ні в одному дизайні (якщо тільки це не Node1, як передбачається, але "весь X проекту" пропонує в іншому випадку, і мене цікавить, що це WTF - чи є Node2?)

Я можу розглянути щось подібне:

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
|   |
|

Або це:

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

Але вони обидва роблять припущення, які можуть бути повністю вимкнені - якщо ви можете оновити своє запитання більш детально, я можу передумати. :)

— Пітер Баутон
джерело