Должен ли я больше интересоваться связью между пакетами или между единицами распространения?

Question

Я смотрю на показатели связь а также посмотреть ДСМ.

Один из инструментов, которые я использовал, рассматривает связь между «модулями», при этом модуль является единицей распространения (в данном случае сборкой .net).

Я чувствую, что меня больше должно интересовать связь между пакетами (или пространствами имен), чем единицами распространения.

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

Что еще кто-то измеряет?

Что бы это ни стоило, я интуитивно чувствую, что если я сосредоточусь на связи пакета/пространства имен, то единица связи распространения станет бесплатной или, по крайней мере, будет проще.

Answer 1

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

Если отбросить эту оговорку, вот что я предлагаю.

На самом деле существует три разных взгляда на управление зависимостями/связями:1) физическая структура (т.е.Зависимости сборки) 2) Логическая структура (т.е.зависимости пространства имен) 3) Структура реализации (т.е.классовые зависимости)

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

Для приложений, развернутых на клиенте, номер 1 может быть очень важным (т.для таких вещей, как плагины).Для приложений, развернутых внутри предприятия (т.asp.net), пункт №1 обычно оказывается не столь важным (за исключением фреймворков, повторно используемых в нескольких приложениях).Обычно вы можете достаточно легко развернуть все приложение, чтобы не создавать накладные расходы на сложную структуру для № 1.

Пункт №2, как правило, больше связан с ремонтопригодностью.Знайте границы своих слоев и их связь с пространствами имен (т. е.вы делаете 1 слой для каждого пространства имен или упаковываете по-разному на логическом уровне).Иногда инструменты могут помочь вам обеспечить соблюдение границ слоев, взглянув на структуру логических зависимостей.

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

Чтобы немного приблизиться к сути вашего вопроса, пункт № 1 на самом деле касается того, как проекты размещаются в решении VS.Так что это не предмет для измерения.Это скорее то, что вы настраиваете вначале и запускаете.Пункт №2 — это то, что вы можете использовать для проверки во время сборки инструмента, чтобы убедиться, что разработчики не нарушили какие-либо правила.На самом деле это скорее проверка, чем мера.Пункт №3 действительно является тем, на измерение которого вам следует внимательно обратить внимание.Поиск в вашей кодовой базе классов, которые имеют высокую степень связанности, в будущем станет проблемой, поэтому убедитесь в качестве этих ребят.Кроме того, измерения на этом уровне позволяют получить некоторое представление о качестве (в целом) кодовой базы по мере ее развития.Кроме того, это может стать для вас тревожным сигналом, если кто-то проверит в вашей кодовой базе действительно непристойный код.

Итак, если вы хотите расставить приоритеты, взгляните на №1 и №2.Знайте, как они должны выглядеть.Но для большинства приложений пункт №3 должен отнимать больше всего времени.

Этот ответ, конечно, исключает огромные платформы (такие как .NET BCL).Этим детям необходимо очень внимательное внимание к пункту №1.:-)

В противном случае вы столкнетесь с такими проблемами:«Текущие версии .NET Framework включают в себя множество библиотек с графическим интерфейсом, которые не будут работать должным образом в Server Core»http://www.winsupersite.com/showcase/win2008_ntk.asp

Когда вы не можете запустить .NET при установке Windows Server 2008 без графического интерфейса, поскольку платформа принимает зависимости от библиотек графического интерфейса...

И последнее.Убедитесь, что вы знакомы с принципами хорошего управления зависимостями/связями.Хороший список можно найти здесь:

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Answer 2

Циклы связи и зависимости между единицами дистрибутива более «фатальны», потому что они могут действительно затруднить развертывание вашей программы, а иногда также могут сильно затруднить даже компиляцию вашей программы.

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