Сохраняя все слабо связанным и расширяемым:Слишком много слоев, слишком маленькая рентабельность инвестиций?
https://stackoverflow.com/questions/1251015
-
12-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я (сейчас больше, чем когда-либо) вижу, как разработчики пишут огромное количество слоев, таких как:
implementation PresentationLayer ->
interface IMyDTO ->
implementation MyDTO ->
interface IMyService ->
implementation MyService ->
interface IMyDomainRepository ->
implementation MyDomainRepository ->
interface IMyDomainObject ->
implementation MyDomainObject ->
interface IMyIndependentStorageLayer ->
implementation MyMSSQLStorageLayer
Просматривая блоги на C #, это кажется лучшей вещью со времен нарезанного хлеба.По сути, все слабо взаимосвязано.Не используйте объект домена напрямую.Запустите все через уровень сервиса.Доступ к данным осуществляется через репозиторий.Все слои совершенно независимы.
Не поймите меня неправильно, мне нравится идея, но разве компромисс во времени не огромен, особенно в более крупном проекте?Действительно ли рентабельность инвестиций в техническое обслуживание достаточно велика, чтобы оправдать это?
Объяснения, которые я прочитал, довольно неуклюжие, такие как "таким образом, я могу подключить другую базу данных, если мне нужно".Неужели?Я не думаю, что это обычная проблема, когда кто-то внезапно требует перейти с MSSQL на Oracle, и теперь вы сидите там и жалеете, что у вас нет миллиона слоев, которые не знают друг о друге.
Существует ли тенденция переусердствовать с ослабленным сцеплением, или я просто читаю не те блоги?Что вы чувствуете по этому поводу, и были ли у вас случаи, когда вы были действительно рады позже, что проделали дополнительную работу в самом начале?
Решение
Очень сложно разработать правильную концепцию программного обеспечения, ориентированную на бизнес.Я имею в виду с приемлемой рентабельностью инвестиций.
Однако, на мой взгляд, количество уровней или уровень низкой связности концепции программного обеспечения зависит от контекста, в котором будет использоваться программное обеспечение!
Если вы уверены в том, что должно делать программное обеспечение, и, вероятно, в будущем не будет больших изменений или добавлений, приложение связи сверхнизкого уровня с большим количеством уровней - это не решение.Потому что это делает архитектуру слишком сложной без какой-либо причины, а время, потраченное на архитектуру, не приносит прибыли...
С другой стороны, если вы знаете, что приложение придется настраивать под каждого клиента и, безусловно, оно будет подвергнуто глубоким изменениям, поэтому время, потраченное на низкоуровневую архитектуру сопряжения, является хорошей идеей...
Низкоуровневая связь может быть разумной, когда вы хотите повторно использовать часть кода для другого приложения.В этом случае, конечно, время, потраченное на дизайн, полностью окупается.
Затем, подводя итог, я скажу, что все зависит от эволюции программного обеспечения в будущем и потенциала повторного использования кода для других приложений.
Но для меня это лучшая практика, когда я занимаюсь систематически не очень сложной архитектурой.
Другие советы
Очевидно, что с этим можно перестараться, и нужно знать, "где остановиться" при добавлении слоев.
Мое эмпирическое правило заключается в том, что если одному слою не нужно включать какую-либо значительную функциональность / код, то мне это не нужно.При этом тестируемость - это важная вещь, поэтому, если какой-то слой улучшит мою тестируемость, я добавлю его.
Ничто в дизайне приложений не обходится без цены.Здесь цена - повышенная сложность.Вы всегда должны просмотреть свои варианты, прежде чем выбрать тот, который наилучшим образом соответствует вашим потребностям.
Учитывая сказанное, я думаю, что ваш вопрос звучит немного предвзято.В реальном мире вы не часто можете увидеть клиента, требующего новый тип базы данных, но вы часто можете увидеть нового клиента, который хочет тот же тип доступа к данным, что и предыдущий, но в другой базе данных.Речь идет не только о простоте изменения, но и о повторном использовании кода.
Оценивая эти вещи, я обычно нахожу полезным взглянуть на это через призму принципа DRY и рассмотреть дублирование в вашем проекте.
Если вы используете архитектуру, которая является более сложной, чем ваш проект, вы, как правило, будете видеть множество слоев, которые мало что делают, кроме обертывания других слоев и передачи вызовов.Это повторение самого себя.
С другой стороны, если вы используете тонкую архитектуру для сложной системы, вы можете обнаружить, что создание функциональности в одной части системы не позволяет вам повторно использовать эту функциональность в другой части, заставляя вас повсюду писать много очень похожего кода.Это повторение самого себя.
По моему опыту, если вы будете бдительно выявлять дублирование и постоянно проводить рефакторинг для его устранения, структура предстанет перед вами сама собой.Предположим, например, что вы начинаете с довольно базовой архитектуры, но разбиваете вещи на методы, как только их нужно будет повторно использовать, и разбиваете методы на классы, как только их нужно будет повторно использовать другими классами.Тогда вы, возможно, в конечном итоге поймете, что ваши 13 классов Helper / Manager / Handler, которые вы написали для устранения дублирования, на самом деле выглядят так, как будто они берут на себя ответственность, которая могла бы быть более четко определена, если бы она перешла на уровень сервиса.
Бывает сложно понять, когда это того стоит, но я думаю, что ключ к успеху в построении системы с большим количеством уровней заключается в предельно четком распределении обязанностей между различными уровнями.Любой добавляемый вами слой должен быть полезен для уменьшения сложности операций в слое над ним и упрощения элегантного объединения функциональных возможностей.
Возьмем гипотетический пример проекта.Тесты используют различные встроенные базы данных SQLite для повышения скорости, базой данных разработки на компьютере какого-либо разработчика является PostgreSQL, промежуточная база данных представляет собой единую установку Oracle, а производственная база данных представляет собой масштабируемый, очень дорогой и очень сложный в настройке кластер Oracle.
Как бы вы могли это осуществить, не отделяя уровень SQL от бизнес-уровня?
Это недавняя тенденция, и менее опытные руководители / архитекторы становятся жертвами того, что бросаются наутек.
В проекте, над которым я работаю, доступ к данным был:
Интерфейс сервиса -> Реализация сервиса -> Интерфейс делегирования -> Реализация делегирования -> Интерфейс DAO -> Реализация DAO -> Ibatis XML.
В нашем случае это было (и есть!) плохо, потому что большая часть кода в любом методе реализации делегирования состояла из одной строки;это просто называется ДАО.Для каждого DAO у нас было два дополнительных класса и одна дополнительная конфигурация bean, и мы вообще ничего от этого не получали.
Примите изменения, проведите рефакторинг и двигайтесь дальше.Используйте столько слоев, сколько потребуется, чтобы разделить различные концепции по частям...а потом остановись.Если нет ощутимой выгоды от написания какого-либо кода, за исключением того, что он будет следовать шаблону, либо притормозите и попытайтесь полностью понять, почему шаблон так поступил, либо примите, что шаблон не подходит для вашего приложения, и проигнорируйте этот фрагмент.
В настоящее время я работаю над большим SOA-проектом, где каждый слой был разделен, и почти каждый класс создается с помощью некоторой абстрактной фабрики.Сейчас мы пытаемся перенести часть существующей функциональности в отдельно размещенные сервисы, и это настоящий кошмар - перебирать слои, пытаясь экстраполировать важные фрагменты, потому что есть бесконечный щелчок правой кнопкой мыши > Перейти к определению...преследовать то, что было всего лишь 1 строкой кода на самом внешнем уровне!
В разделении как таковом нет ничего плохого, и, конечно, даже в моем проекте есть много областей, где я нахожу это полезным с архитектурной точки зрения.Только не увлекайся...Будьте прагматичны и взвесьте все "за" и "против" при изучении областей, которые вы собираетесь разделить.
Ваше здоровье
