Хранение всех свободно связанных и расширяемых: Слишком много слоев, слишком маленький ROI?

I (теперь более чем когда-либо) разработчики пишут огромное количество слоев, например:

implementation PresentationLayer ->
    interface IMyDTO ->
        implementation MyDTO ->
            interface IMyService -> 
                implementation MyService -> 
                    interface IMyDomainRepository ->
                        implementation MyDomainRepository ->
                            interface IMyDomainObject -> 
                                implementation MyDomainObject ->
                                    interface IMyIndependentStorageLayer ->
                                        implementation MyMSSQLStorageLayer

код >

Просматривая блоги С#, это кажется лучшим, поскольку нарезанный хлеб. В принципе, все слабо связано. Не используйте объект домена напрямую. Запустите все через сервисный уровень. Доступ к данным через репозиторий. Все слои совершенно независимы.

Не поймите меня неправильно, мне нравится идея, но не компромисс вовремя огромна, особенно в более крупном проекте? Является ли ROI в обслуживании действительно достаточно большим, чтобы оправдать это?

Объяснения, которые я прочитал, являются довольно неудобными, например, "таким образом я могу прикрепить другую базу данных, если мне нужно". В самом деле? Я не думаю, что это общая проблема, которую кто-то внезапно требует переключиться с MSSQL на Oracle, и теперь вы сидите там и хотите, чтобы у вас было миллион уровней, которые все не знают друг о друге.

Есть ли тенденция к переходу за борт со свободной связью, или я просто читаю неправильные блоги? Как вы относитесь к этому, и у вас были случаи, когда вы были действительно рады, что вы сделали дополнительную работу в начале?

Ответ 1

Очень сложно создать правильную концепцию, ориентированную на бизнес для программного обеспечения. Я имею в виду с приемлемым ROI.

Однако для меня количество слоев или уровень низкого сочетания концепции программного обеспечения зависит от контекста, в котором будет использоваться программное обеспечение!

Если вы уверены в том, что программное обеспечение должно делать, и в будущем, вероятно, не будет больших изменений или добавлений, приложение для соединения с низким уровнем шума с большим количеством слоев не является решением. Потому что это делает архитектуру слишком сложной без какой-либо причины, и время, потраченное на архитектуру, не выгодно...
С другой стороны, если вы знаете, что приложение должно быть настроено для каждого клиента и, безусловно, будет модифицировано по глубине, поэтому время, потраченное на архитектуру связи низкого уровня, является хорошей идеей...
Связь низкого уровня может быть разумной, если вы хотите повторно использовать часть кода для другого приложения. В этом случае, конечно, затраты времени на дизайн вполне выгодны.
Затем, в общем, я скажу, что все зависит от эволюции программного обеспечения в будущем и возможности повторного использования кода для других приложений.
Но это лучшая практика для меня не систематически очень сложной архитектуры.

Ответ 2

Очевидно, что это может быть перебор, и нужно знать, где остановиться, добавлять слои.

Мое эмпирическое правило состоит в том, что если одному слою не нужно включать какую-либо значительную функциональность/код, мне это не нужно. Это говорит о том, что тестируемость - это значительная вещь, поэтому, если слой покупает мне лучшую тестируемость, я добавлю его.

Ответ 3

Ничто в приложении-дизайне не идет без цены. Здесь цена становится более сложной. Вы ВСЕГДА должны просматривать ваши варианты, прежде чем выбирать тот, который наилучшим образом соответствует вашим потребностям.

С учетом сказанного, я думаю, что ваш вопрос звучит немного предвзято. В реальном мире вы, возможно, нередко видите, что клиент требует новый вид БД, но вы часто можете увидеть нового клиента, который хочет получить тот же доступ к данным, что и предыдущий, но на другой БД. Это не только о легкость изменения, но и о повторном использовании кода.

Ответ 4

Оценивая эти вещи, я обычно считаю полезным взглянуть на него через объектив принципа DRY и посмотреть на дублирование в вашем проекте.

Если вы используете более сложную архитектуру, чем ваш проект, вы, как правило, увидите много слоев, которые мало чем обернут другие слои и передадут вызовы. Это повторяется.

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

По моему опыту, если вы проявляете бдительность в выявлении дублирования и постоянно рефакторинг, чтобы удалить его, структура представится вам. Скажем, например, что вы начинаете с довольно простой архитектуры, но выбирая вещи в методы, как только их нужно повторно использовать, и выбирая методы в классы, как только они должны быть повторно использованы другими классами. Затем вы, возможно, в конце концов поймете, что ваши 13 классов помощника/менеджера/обработчика, которые вы написали для удаления дублирования, на самом деле выглядят довольно похоже на то, что они берут на себя ответственность, которая могла быть более четко определена, если бы она перешла на уровень службы.

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

Ответ 5

Возьмите гипотетический пример. В тестах используются разные встроенные базы данных SQLite для скорости, база данных разработки на каком-то компьютере разработчика - PostgreSQL, промежуточная база данных - это единая установка Oracle, а производственная база - это масштабируемая, очень дорогостоящая и очень сложная конфигурация Oracle. кластера.

Как бы вы могли снять это, не отделяя уровень SQL от бизнес-уровня?

Ответ 6

Это недавняя тенденция, и менее опытные руководители/архитекторы становятся жертвами прыжков на подножку.

В проекте, в котором я включен, доступ к данным:

Интерфейс службы → Реализация услуги → Интерфейс делегата → Реализация делегата → Интерфейс DAO → Реализация DAO → Ибатис XML.

Это было (и есть!) плохо в нашем случае, потому что самый код в любом методе реализации делегирования был одной строкой; это просто называется DAO. Для каждого DAO у нас было два дополнительных класса и один дополнительный bean config, и мы ничего не получали от этого.

Примите изменения, рефакторинг и перейдите. Используйте столько слоев, сколько требуется, чтобы разделить разные понятия... и затем остановитесь. Если нет заметного выигрыша в написании какого-либо кода, кроме того, что он будет следовать шаблону, либо замедлить работу, либо попытаться полностью понять, почему шаблон сделал это, либо принять, что шаблон неверен для вашего приложения и проигнорировать этот бит.

Ответ 7

В настоящее время я работаю над большим проектом SOA, где каждый слой был разделен, и почти каждый класс создается через абстрактный factory. Теперь мы пытаемся разгрузить некоторые из существующих функций в отдельно размещенные сервисы, и это настоящий кошмар, проходящий через слои, пытающиеся экстраполировать важные биты, потому что существует бесконечный щелчок правой кнопкой мыши > Перейти к определению..., чтобы преследовать вниз, что было только 1 строка кода на самом внешнем слое!

Нет ничего плохого в развязке как таковой, и, конечно, даже в моем проекте есть много областей, где я считаю это полезным с архитектурной точки зрения. Просто не увлекайтесь... Будьте прагматичны и взвешивайте плюсы и минусы при изучении областей, которые вы планируете отделить.

Приветствия