Когда я смотрю проекты ASP.NET MVC, я каждый раз вижу свободную связанную архитектуру.
Для чего мне нужна свободная связь в веб-архитектуре (если я не делаю модульные тесты)?
Каковы преимущества и недостатки из этого?
Что такое основная причина для разделения слоев/классов?
Что делать, если я не хочу, например, изменить DAL? Я имею в виду, когда я должен изменить весь DAL?! Поэтому я мог бы связать свой DAL с пользовательским интерфейсом. Что плохо с этим?
Это сэкономит вам много времени для любого проекта, который не является тривиально небольшим, где я определяю тривиально мало меньше пары тысяч строк кода (в зависимости от языка).
Причина в том, что после того, как вы пройдете сверхмалые проекты, каждое изменение или обновление становится все сложнее, чем более тесно связано. Будучи слабо связанными, вы можете продолжать двигаться вперед, добавлять функции, исправлять ошибки и т.д.
В какой-то момент я думаю, что любая программа становится кошмаром для поддержания, обновления и добавления. Чем более слабо связан дизайн, тем дальше этот момент задерживается. Если он плотно связан, может быть, после примерно 10 000 строк кода он становится недостижимым, добавление некоторых функций становится невозможным без существенного переписывания с нуля.
Будучи слабо связанным, он может вырасти до 1 000 000 - 10 000 000 строк кода, все еще имея возможность вносить изменения и добавлять новые функции в течение разумного промежутка времени.
Эти цифры не должны восприниматься буквально, поскольку они просто составлены, но чтобы дать понять, где это становится полезным.
Если вам никогда не нужно обновлять программу, и это довольно просто, но, конечно, хорошо, чтобы быть плотно соединенным. Это даже нормально начать, но знайте, когда настало время разделить материал, но вам все еще нужен опыт написания слабосвязанного кода, чтобы узнать, в какой момент он станет полезным.
Предприятие Fizzbuzz представляет собой преднамеренно юмористический пример того, как можно переборщить с overengineering, и не каждый проект будет нуждаться в том же уровне развязки.
MVC обычно считается хорошей отправной точкой, потому что большинство проектов станут достаточно большими, чтобы они могли быть полезными. Когда проект становится больше, такого уровня развязки недостаточно, а часть M нужно разбить на несколько слоев и так далее. Для всех проектов не подходит один размер, но MVC - это большая часть развязки для большинства проектов.
Loose Coupling позволяет вам вносить изменения в одну область приложения, не затрагивая других. Теоретически это позволяет вам делать такие вещи, как изменение уровня доступа к данным, без необходимости перестраивать свой бизнес или пользовательский интерфейс.
Это определенно делает ваши приложения более гибкими, более умелыми в изменении и проще в обслуживании (поскольку вам не нужно беспокоиться об изменении одной области приложения, нарушающей другую).
На бумаге есть много преимуществ свободной связи, но на практике трудно сделать это правильно ИМХО. Вот некоторые преимущества:
Системы могут эволюционировать независимо в плане жизненного цикла.
Системы могут быть написаны на разных языках и в конечном итоге работать на разных ОС.
Системы могут (и должны) быть построены разными командами. Вы можете аутсорсинг разработки систем. Фактически это практически единственный способ масштабирования организации разработки программного обеспечения.
Вот некоторые недостатки:
Это больше работает в начале, и если вы не сделаете это хорошо, вы никогда не увидите его преимуществ.
Определение API/контрактов довольно сложно и требует очень опытных разработчиков. Это легко сделать вначале, но в долгосрочной перспективе это сложно.
Обобщение свободной связи может фактически приводить к свободному типу. Вместо использования четко определенных значимых объектов вы можете наблюдать увеличение использования параметров "объекта" или типа возврата, общих типов, добавленных к каждому классу или интерфейсу. Плохой эффект от этого - средний разработчик, вероятно, повсеместно добавит операции дикого литья, предполагая типы с обеих сторон так называемых слабосвязанных систем.
Некоторые методы ослабленной связи основаны на обобщении определения интерфейсов с намерением избежать прямой зависимости. Помните, что интерфейс должен быть вырезан на камне после его определения и публикации. Теперь это не совсем то, что я называю свободным сцеплением. Класс .NET, использующий JIT и такие методы, как перегрузка метода, может быть лучшим свободным инструментом связи. Таким образом, проблема с этими интерфейсами и фабриками повсюду - это приведет к размножению типов, сборок, тестовых примеров и т.д.... и просто больше работы и сложности в будущем. Вместо упрощения вещей вместо создания одной системы вам придется строить много. "система N-уровня - это N-кратная работа": -)
Свободная связь каким-то образом обходит один из самых мощных инструментов, когда-либо созданных: компилятор (С# или другие). И что вся цель этого на самом деле, но у нее определенно есть некоторые недостатки, потому что вся работа на земле, которую выполнял компилятор (проверка типа и т.д.), Должна быть выполнена в другом месте (тесты), и это будет стоить.
Многие из готовых инструментов, вероятно, больше не будут работать. Вы не сможете использовать такие вещи, как Visual Studio "Перейти к определению" или "Найти все ссылки".
Свободно связанная архитектура поможет вам, когда ваше приложение должно измениться или расти. И любое нетривиальное приложение в конечном итоге должно будет измениться или расти.
Если вы проектируете с плохо связанной архитектурой, при изменении требований должны быть затронуты только несколько частей приложения. С слишком жесткой архитектурой необходимо будет изменить многие части, и будет трудно точно определить, какие части будут затронуты.
Одно из основных преимуществ TDD, на мой взгляд, заключается в том, что при содействии слабосвязанной архитектуры.
Я думаю, что "правильный" способ был объяснен в других ответах. Но я напишу сейчас по собственному опыту.
Есть несколько вещей, которые вы должны учитывать при выборе архитектуры.
а. Client
У вас есть достаточно времени, чтобы сделать все "правильным" способом (отличная архитектура, тесты и т.д.)? Иногда клиент хочет быстро увидеть результаты. Мы можем пожаловаться на то, что время короткое, и продукт не будет соответствовать самым высоким стандартам, но, в конце концов, это наша проблема. В этих ситуациях мы объясняем клиенту, что он получит, и напишите код спагетти, который мы все знаем.
Каковы требования клиентов (с точки зрения надежности, масштабируемости, расширения возможностей, скорости)? Я думаю, что это самоочевидно. Иногда клиент диктует "правильный" способ. Мы можем предложить клиенту "правильный" способ, но в итоге клиент решит (в зависимости от времени и денег, конечно).
Кто будет поддерживать систему после ее разработки? Я хотел бы поддержать хороший и развязанный код. Поэтому, когда я пишу код, я прикладываю все усилия, чтобы сделать его "правильным" . Когда-нибудь я мог бы скомпилировать представление и контроллер или пару некоторых услуг и быть счастливым с ним. Зная мой собственный код, его легко поддерживать.
б. Проект
Каков размер проекта? Некоторые проекты настолько малы, что любая сложная архитектура не оправдана.
Есть ли шанс, что программное обеспечение быстро вырастет в будущем (больше возможностей)? Это одна из самых больших проблем. Но если программное обеспечение растет, это означает, что это успех. У вас, вероятно, будет больше ресурсов для работы. Относительно легко реорганизовать свой код и сделать его "правильным" .
Будет ли проект потенциально иметь проблемы с масштабируемостью? Есть проекты, которые никогда не будут расти с точки зрения пользователей и данных. Я видел проекты, которые пытаются выглядеть серьезными, используя базу данных Oracle RAC, когда простая встроенная база данных будет работать нормально!
Запустили ли вы проект или используете его у других разработчиков? Это сочетание вопросов, кто будет поддерживать программное обеспечение и будет ли программное обеспечение расти. Вы можете получить код спагетти от других разработчиков. У вас будет время и ресурсы, чтобы сделать его "правильным" ?
с. Команда разработчиков
Неужели команда достаточно опытная, чтобы сделать развязку правой? Когда я был менее опытным, я попытался написать "правильный" код. И я потерпел неудачу. Дело в том, чтобы действительно знать свою команду разработчиков, их навыки и знания. Не стоит недооценивать эту проблему. Работая с менее опытными разработчиками, я обычно приношу некоторые жертвы в архитектуру. Жертва, которая будет сделана, - это лучшая образованная догадка, которую я имею. Есть некоторые моменты из архитектуры, которые вы можете жертвовать, и есть некоторые, которые вы не можете. Обычно одна или несколько жертвоприношений, которые вы совершили раньше, вернутся и укусят вас.
Испытывают ли разработчики автоматические тесты? Недостаточно иметь автоматические тесты. Они должны быть полными (насколько это возможно) и делать правильно. Если ваши тесты слабы, лучше их вообще не иметь. Вы не хотели бы опираться на стену, полную дыр.
Заключение
Я знаю, что мы все хотим быть профессионалами. И как профессионалы, мы должны учитывать все вещи. Мы не можем тратить свое время и энергию на то, чтобы делать вещи "правильным" способом. Иногда мы должны смотреть на другие факторы (реальность) и делать выбор. И самое главное - жить с ним.
Преимущества:
Disavantages:
Во-первых, вы должны писать модульные тесты;)
Скажите, что вам нужно изменить базовую базу данных. Если ваш код доступа к данным тесно связан с вашей бизнес-логикой, это может оказаться огромным усилием. При наличии слабосвязанного кода ваша бизнес-логика останется незатронутой.
Что делать, если вы решите, что хотите написать некоторые утилиты командной строки, которые используют ваши базовые компоненты? Предоставление нескольких точек входа в вашу систему намного легче выполняется с помощью слабосвязанного кода.
Это даст вам масштабируемость. Например, если у вас есть сервисный уровень, вы можете разделить его на нескольких серверах. Также у вас будет меньше зависимостей, а модификации будут проще. Кроме того, поддержка кода будет проще.
Здесь вы можете увидеть интересную небольшую статью: SOA - Loosely Coupled... Что?
Вскоре он говорит:
Свободно связанные системы предоставляют множество преимуществ, включая поддержку позднего или динамического связывания с другими компонентами во время работы и могут опосредовать разницу в структуре компонентов, модели безопасности, протоколах и семантике, тем самым абстрагируя волатильность...
Потому что материал в задней части может быть полезен, даже если он не взаимодействует с веб-интерфейсом веб-браузера на основе браузера. Таким образом, вы хотите отключить его от этого конкретного пользовательского интерфейса.
Основная причина для соединения и развязки классов - это возможность расширения. Изменения в одном не должны влиять на других.
если вы создаете приложение, которое в настоящее время использует базу данных MYSql для хранения данных. Теперь у нас есть новое требование хранить данные в MSSQL в качестве его бэкэнд-системы. Какое решение вы оставите, если вы построите систему более интегрированной с библиотеками MYSQL. Переписать все приложение для MSSQL. Теперь как насчет этого. Мы строим новый DAL на основе MSSQL и подключаем Dal к системе без внесения каких-либо изменений в систему (UI).
Приложение вызывает процедуру, основанную на интерфейсах и интерфейсах, без реализации.
Попробуйте прочитать о Unity или MEF, эти темы предоставят вам хорошее понимание
Все зависит от намерения сделать Заявку вместе с деловыми интересами. Если бизнес стремится масштабировать его, и в нем задействовано достаточное количество топлива (прочитанное тело), которое дает достаточную мысль архитектору, чтобы сделать заявку пожинать долгосрочные выгоды.
Таким образом, преимущества: -
1) Если вы используете сторонний элемент управления/код: всегда пишите "слой обертки/адаптера" , чтобы по какой-либо причине, если это невозможно использовать, вы можете получить что-то еще и изменить адаптера, не нарушая код вашего репозитория приложения.
2) Инкапсуляция определенных сложных функций в "Уровень обслуживания" , который может требовать или не требовать запросов к базе данных: это полезно, потому что, поскольку запрос и ответ остаются неизменными (он может со временем меняться хорошо), вы всегда можете работать с производительностью этого конкретного кода без изменения вывода. С помощью единичных случаев мы также можем измерить производительность кода.
3) Создание определенных ролей для написания конкретного кода: если мы создаем много ролей, людям в команде легче сосредоточиться в своем конкретном репозитории, а не потеряться в куче не связанного кода.
4) Сфокусированный QA: если у нас есть многоуровневая архитектура, это всегда помогает улучшить QA в качестве его фокуса.
5) Поиск/устранение ошибок. Используя многоуровневую архитектуру и предполагая, что у вас есть хорошая регистрация на месте, она всегда экономит время, чтобы найти ошибки и решить проблему.
Недостатки: -
1) При создании приложения с такой структурой потребуется дополнительное время. Поэтому "перейти на рынок" будет отложено.
2) Если вы получите слишком много энтузиастов технологий, это может закончиться тем, что он убит.
3) Дополнительная латентность транзакции: поскольку данные перемещаются по различным уровням, есть дополнительная латентность, которая добавляется в каждую транзакцию.
Об изменении DAL: -
Конечно, будет время, когда производительность будет иметь приоритет над функциями в то время, вам придется начать рассматривать поставщиков данных, приводящих к изменению DAL.
Если вы соединяете свой DAL с вашим пользовательским интерфейсом, каждый раз, когда вы меняете свой DAL (если вообще, когда вообще), вам всегда потребуется переиздание всех исполняемых файлов в процессе производства. У этого есть своя своя проблема (уклоняюсь, чтобы объяснить это здесь, если Вы требуете, я могу всегда включать это)
В этом причина, изначально всегда лучше проводить время и заканчивать, когда произойдет "самоуничтожение" для приложения. Я имел в виду, что жизнь приложения, если на это хорошо ответили, все остальное упадет на место.
Разделение труда, которое является человеческим эквивалентом разделения проблем. Ваш гуру HTML должен работать независимо от вашей богини SQL.
Резкое изменение переднего конца должно продолжаться без разрывания бэкэнда и наоборот. Другими словами, вам нужно только нанять одного человека вместо двух.
Ответ с углом, о котором еще никто не говорил; временная развязка. Это можно сделать несколькими способами:
При использовании вышеизложенного (кроме асинхронной монады) вы часто обрабатываете сообщения явно, а не вызовы методов. Это приводит к тому, что мышление коррелирует с тем, как работает передача сообщений (идемпотентность их обработки, очереди для их хранения в пути, данные безопасности, прикрепленные к их конвертам, повторная логика в обработчиках, а не в запросах,...).
Переходя к ориентированным на сообщения архитектурам, которые временно развязаны, вы можете упростить расширение приложения, особенно если вы в основном делаете публикацию-подписку (см. также управляемую событиями архитектуру) - все может прослушивать события и реагировать на них их и вы не привязываете реализации интеграторов к исходным сайтам вызова.
Веб-сайты, которые работают на очереди, более отзывчивы в целом, потому что они не позволяют рабочим потокам зависать в ожидании ввода-вывода. Они также часто дешевле поддерживать в долгосрочной перспективе.
Для разных типов компиляции (и других показателей) просмотрите http://www.ndepend.com/Metrics.aspx и прочитайте об этом сами.