Почему веб-архитектура должна быть слабо связана?

Question

Когда я смотрю на проекты ASP.NET MVC, я всегда вижу слабосвязанную архитектуру.

Для чего мне нужна слабая связь в веб-архитектуре (если я не выполняю модульные тесты)?

Каковы преимущества и недостатки этого?

Какова основная причина для разделения слоев / классов?

Что, если я не хочу менять свой DAL, например? Я имею в виду, когда я должен изменить весь мой DAL ?! Таким образом, я мог связать свой DAL с пользовательским интерфейсом. Что в этом плохого?

Answer 1

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

Это определенно делает ваши приложения более гибкими, более способными к изменениям и более простыми в обслуживании (поскольку вам не нужно беспокоиться об изменении в одной области приложения, нарушающем другую).

Answer 2

Это сэкономит вам много времени для любого проекта, который не является достаточно маленьким, где я определяю тривиально маленький код как менее пары тысяч строк кода (в зависимости от языка).

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

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

Слабая связь позволяет ему увеличиваться до 1 000 000 - 10 000 000 строк кода, в то же время сохраняя возможность вносить изменения и добавлять новые функции в разумные сроки.

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

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

Enterprise Fizzbuzz - это нарочито юмористический пример того, как можно переоценить свои возможности при переподготовке, и не каждому проекту потребуется такой же уровень развязки.

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

Answer 3

На бумаге есть много преимуществ слабой связи, но на практике это трудно сделать правильно, ИМХО. Вот некоторые преимущества:

• Системы могут развиваться независимо с точки зрения жизненного цикла.

• Системы могут быть написаны на разных языках и, в конечном итоге, работать на разных ОС.

• Системы могут (и должны) быть построены разными командами. Вы можете отдать на аутсорсинг разработку систем. На самом деле это практически единственный способ масштабирования организации разработки программного обеспечения.

Вот некоторые недостатки:

• Это больше работы в начале, и если вы не сделаете это хорошо, вы можете никогда не увидеть преимущества этого.

• Определение API / контрактов довольно сложно и требует очень опытных разработчиков. Сначала это легко сделать, но в долгосрочной перспективе это тяжело.

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

• Некоторые методы слабой связи основаны на обобщении определения интерфейсов с целью избежать прямой зависимости. Помните, что интерфейс должен быть высечен в камне после его определения и публикации. Это не совсем то, что я называю слабой связью. Класс .NET, использующий JIT и методы, такие как перегрузка метода, может быть лучшим инструментом слабой связи. Таким образом, проблема с этими интерфейсами и фабриками повсеместно заключается в том, что это приведет к умножению типов, сборок, тестов и т. Д. И просто к дальнейшей работе и сложности в будущем. Вместо того, чтобы упрощать вещи, вместо создания одной системы, вам придется создавать много. «N-уровневая система - это N-кратная работа»: -)

• Слабое связывание так или иначе обходит один из самых мощных инструментов, когда-либо созданных: компилятор (C # или другие). И в этом вся его цель на самом деле, но у нее определенно есть некоторые недостатки, потому что всю основную работу, которую выполнял компилятор (проверка типов и т. Д.), Нужно будет выполнять где-то еще (тесты), и это будет иметь стоимость.

• Многие готовые инструменты, вероятно, больше не будут работать. Вы не сможете использовать такие вещи, как Visual Studio «Перейти к определению» или «Найти все ссылки».

Answer 4

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

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

Одним из главных преимуществ TDD, на мой взгляд, является то, что at помогает развивать слабосвязанную архитектуру.

Answer 5

Я думаю, что «правильный» путь был объяснен в других ответах. Но сейчас я напишу из собственного опыта.

Есть несколько вещей, которые вы должны учитывать при выборе архитектуры.

а. Клиент

Достаточно ли у вас времени, чтобы все сделать "правильно" (отличная архитектура, тесты и т. Д.)? Иногда клиент хочет увидеть результаты быстро. Мы можем жаловаться, что времени мало, и продукт не будет соответствовать самым высоким стандартам, но в итоге это наша проблема. В этой ситуации мы объясняем клиенту, что он получит, и пишем код спагетти, который мы все знаем.

Каковы требования клиентов (с точки зрения надежности, масштабируемости, расширяемости, скорости)? Я думаю, что это само за себя. Иногда клиент диктует «правильный» путь. Мы можем предложить клиенту «правильный» путь, но в итоге клиент решит (в зависимости от времени и денег, конечно).

Кто будет поддерживать систему после ее разработки? Я хотел бы поддержать красивый и отделенный код. Поэтому, когда я пишу код, я прилагаю все усилия, чтобы сделать его «правильным». Иногда я мог бы соединить представление и контроллер или пару какой-либо службы и быть счастливым с этим. Зная мой собственный код, его легко поддерживать.

б. Project

Каков размер проекта? Некоторые проекты настолько малы, что любая сложная архитектура не гарантируется.

Есть ли шанс, что программное обеспечение будет быстро расти в будущем (больше возможностей)? Это одна из самых больших проблем. Но если программное обеспечение растет, это означает, что это успех. Вероятно, у вас будет больше ресурсов для работы. Относительно легко реорганизовать ваш код и сделать его «правильным».

Будут ли у проекта проблемы с масштабируемостью? Есть проекты, которые никогда не будут расти, с точки зрения пользователей и данных. Я видел проекты, которые пытаются выглядеть серьезно, используя настройку базы данных Oracle RAC, когда простая встроенная база данных будет работать просто отлично!

Вы запустили проект или переняли его у других разработчиков? Это комбинация вопросов о том, кто будет поддерживать программное обеспечение и будет ли оно расти. Вы можете получить код спагетти от других разработчиков. У вас будет время и ресурсы, чтобы сделать это "правильно"?

с. Команда разработчиков

Достаточно ли опытна команда, чтобы сделать правильное разделение? Когда я был менее опытным, я пытался написать «правильный» код. И я потерпел неудачу. Суть в том, чтобы действительно знать свою команду разработчиков, их навыки и знания. Не стоит недооценивать эту проблему. Работая с менее опытными разработчиками, я обычно делаю некоторые жертвы архитектуре. Жертва, которая будет принесена, - лучшее образованное предположение, которое я имею. Есть некоторые моменты в архитектуре, которыми вы можете пожертвовать, а некоторые - нет. Обычно одна или несколько жертв, которые вы принесли ранее, возвращаются и кусают вас.

Опытные разработчики написали автоматические тесты? Недостаточно иметь автоматические тесты. Они должны быть полными (насколько это возможно) и сделаны правильно. Если ваши тесты слабые, то лучше их вообще не иметь. Вы не хотели бы опираться на дырявую стену.

Заключение :

Я знаю, что мы все хотим быть профессионалами. И, как профессионалы, мы должны все учитывать. Мы не можем тратить свое время и силы на то, чтобы делать вещи «правильным» образом. Иногда мы должны смотреть на другие факторы (реальность) и делать свой выбор. И самое главное - жить с этим.

Answer 6

Преимущества:

• Масштабируемость - позволяет расширить слой доступа к базе данных
• Возможность обмена - например, код провайдера электронной почты
• Ремонтопригодность - просто измените код в одном месте
• Простота настройки модульного тестирования - вы можете макетировать объекты, такие как ваша база данных

Disavantages:

• Возможно, несколько дополнительных строк кода
• Некоторые дополнительные классы интерфейса

Answer 7

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

Здесь вы можете увидеть интересную небольшую статью: SOA - Слабосвязанная ... Что?

Коротко сказано:

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

Answer 8

Прежде всего, вы должны писать модульные тесты;)

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

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

Answer 9

Все зависит от намерения сделать Заявку и делового интереса. Если бизнес заинтересован в его масштабировании и задействован достаточный объем топлива (читай корпус), что дает архитектору достаточное количество мыслей, чтобы приложение получало долгосрочные выгоды.

Итак, преимущества: -

1) Если вы используете сторонний элемент управления / код: всегда пишите «слой-обертка / адаптер» , чтобы по любой причине, если это невозможно, вы могли получить что-то другое и заменить адаптер слой, не нарушая код хранилища приложений.

2) Инкапсуляция определенных сложных функциональных возможностей в «Сервисный уровень» , который может требовать или не требовать запросов к базе данных: это выгодно, поскольку запрос и ответ остаются неизменными (они, несомненно, также могут изменяться со временем ), вы всегда можете работать над производительностью этого конкретного кода, не меняя вывод. Имея единичные регистры, мы также можем измерить производительность кода.

3) Создание определенных ролей для написания конкретного кода: если мы создаем много ролей, людям в команде становится легче сосредоточиться на своем конкретном репозитории, а не теряться в куче несвязанного кода.

4) Сосредоточенный контроль качества: если у нас многоуровневая архитектура, она всегда помогает улучшить качество контроля, поскольку оно сфокусировано.

5) Поиск / устранение ошибок: используя многоуровневую архитектуру и предполагая, что у вас есть хорошее ведение журнала, всегда экономится время на поиск ошибок и их устранение.

Недостатки: -

1) Настройка приложения с такого рода фреймворком займет дополнительное время. Так что «выход на рынок» будет отложен.

2) Если вы слишком увлечены технологиями, это может привести к чрезмерному убийству.

3) Дополнительная задержка транзакции: поскольку данные проходят через различные уровни, возникает дополнительная задержка, которая добавляется в каждую транзакцию.

Об изменении DAL: -

Конечно, будет время, когда производительность будет иметь приоритет над функциями, в то время как вам придется подумать о поставщиках данных, ведущих к изменению DAL.

Если вы подключаете свой DAL к своему пользовательскому интерфейсу, каждый раз, когда вы меняете свой DAL (если вообще, когда вообще), вам всегда потребуется повторно выпускать все двоичные файлы в рабочем состоянии. У которого есть свой набор проблем (я уклоняюсь, чтобы объяснить это здесь, если вам нужно, я всегда могу это включить)

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

Answer 10

Основная причина объединения и развязки классов - расширяемость. Изменение одного не должно влиять на другое.

если вы создаете приложение, которое в настоящее время использует базу данных MYSql для хранения данных. Теперь у нас есть новое требование хранить данные в MSSQL как его бэкэнд-систему. Какое решение вам останется, если вы создадите систему, более интегрированную с библиотеками MYSQL. Переписать Целое приложение для MSSQL. А теперь как насчет этого Мы создаем новый DAL на основе MSSQL и подключаем Dal к системе, не внося никаких изменений в систему (UI).

Приложение вызывает подпрограмму на основе интерфейсов, и интерфейсы свободны от реализации.

Попробуйте прочитать о Unity или MEF, эти темы помогут вам лучше понять