Архитектурно-ориентированная и функционально-ориентированная структура проекта

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

Я бы проголосовал за второй. В первой структуре обработчики событий for FeatureAсовершенно не связаны с обработчиками событий for FeatureB. Похоже, что разработчики будут работать над одной функцией за раз, и если вы работаете над FeatureXзапросом, гораздо более вероятно, что вам потребуется настроить FeatureXобработчик запроса, чем, скажем, FeatureZзапрос.

Кстати, мне нравится, как вы задали этот вопрос с нейтральной точки зрения.

— Примечание для себя - придумайте имя
источник

1

+1 с одной оговоркой: для небольших проектов второй приведет к большей файловой структуре, чем есть файлы для ее вставки. Я бы использовал первую для них.

— Майкл К

@ Михаил, я согласен, но в данном случае это большой проект.

— Zzz

1

+1: И если вам когда-либо придется общаться с пользователем / клиентом, то терминология может быть достаточно последовательной.

— Стивен Эверс

4

Мне всегда было комфортнее со вторым подходом, но у меня всегда есть «особенность», называемая общей или общей для действительно общих / базовых классов.

Подход второй позволяет разделить действительно отдельные вещи, но без «общей» области он иногда разделяет вещи на области, которые им не подходят.

— Билл
источник

+1 для общего и общего (каждый проект имеет общие утилиты, инструменты ...)

— Zzz

3

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

Это особенно важная проблема, когда реализация функции охватывает несколько dll, exe, баз данных или других частей программного обеспечения.

— Джон Фишер
источник

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

Но они оба делают предположения, которые могут быть совершенно неверными - если вы можете обновить свой вопрос с более подробной информацией, я могу передумать. :)

— Питер Боутон
источник