Почему являются циклические ссылки в Visual Studio плохой практикой?

Вы также можете позволить библиотеке Square Picasso сделать тяжелый подъем:

Picasso
    .with(context)
    .load("http://...")
    .into(imageView);

В качестве бонуса вы получаете кеширование, преобразования и т. д.

30
задан Mihai Limbășan 25 November 2008 в 19:54
поделиться

8 ответов

Да, это - плохая практика по точно причине, которую Вы заявили - Вы не можете восстановить из источника.

40
ответ дан 27 November 2019 в 23:17
поделиться

Это - один из признаков сверхмодуляризации.

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

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

Sheesh.

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

, Конечно, модульный принцип обычно является хорошей вещью.

, Но как все хорошие вещи, это может быть взято к смешным экстремальным значениям.

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

23
ответ дан 27 November 2019 в 23:17
поделиться

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

я заметил это много со служебными блоками. Должен быть антишаблон.

13
ответ дан 27 November 2019 в 23:17
поделиться

Вопрос, который я поставил бы Вашим коллегам:

Хорошо, очень маловероятно, что мы потеряем все наши двоичные файлы одновременно. Но, скажите мне, каково преимущество этого подхода?

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

3
ответ дан 27 November 2019 в 23:17
поделиться

круговые зависимости плохи потому что:

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

, это - потенциально бесконечный цикл в процессе сборки

1
ответ дан 27 November 2019 в 23:17
поделиться

Гм, я думаю с точки зрения вопроса OP, приблизительно здание проекты с нуля, это - плохие методы, из-за:

  1. Неспособность создать из источника / царапина - Что, если я поддерживаю несколько версий кода. Между каждой версией были внесены несколько изменений в каждом освобождении.. Единственным путем я могу feasabily поддерживать эти параллельные версии, должен теперь сохранить скомпилированные двоичные файлы в моем управлении версиями. Это также означает, что сравнения между каждой версией библиотеки - это намного тяжелее. (Я должен узнать, какая версия используется, затем пойдите посмотреть на фактический исходный код для lib, а не просто прямую разность на самом источнике.
  2. Возможно тяжелее для выставления патчей к клиентам, которые инкрементно исправили версии.. Где и что исправить?
0
ответ дан 27 November 2019 в 23:17
поделиться

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

Visual Studio 2008 явно запрещает циклические ссылки между проектами (не двоичными файлами) в решениях. Как вы заявили, это не относится к двоичным файлам. Я полагаю, это потому, что VS2008 ожидает, что двоичные ссылки управляются независимо, и он ожидает, что вы создаете эти проекты независимо. Вообще говоря, это означает, что все двоичные ссылки должны рассматриваться как сторонние компоненты, которые представляют собой четкие односторонние отношения (между вашим кодом и двоичным кодом).

Кроме того, MSBuild позволяет вам использовать файл SLN для сборки всего, если все ваши проекты используют VB или C #. Это позволяет создавать файл Uber-Solution, который идеально подходит для автоматизированного процесса сборки. Уловка в том, что для работы такого файла основного решения все проекты в SLN должны использовать ссылки на проекты. Поэтому, чтобы воспользоваться этим преимуществом, Microsoft по определению ожидает, что вы не используете циклические ссылки, поскольку они явно запрещены в Visual Studio IDE (для ссылок на проекты).

Скотт Хансельман ссылается на файл с Uber-решением в следующем посте:
Microsoft ожидает, что вы не используете циклические ссылки, поскольку они явно запрещены в Visual Studio IDE (для ссылок на проекты).

Скотт Хансельман ссылается на файл с Uber-решением в следующем посте:
Microsoft ожидает, что вы не используете циклические ссылки, поскольку они явно запрещены в Visual Studio IDE (для ссылок на проекты).

Скотт Хансельман ссылается на файл с Uber-решением в следующем посте:
Взлом: Параллельные MSBuilds из среды IDE Visual Studio
http://www.hanselman.com/blog/CategoryView.aspx?category=MSBuild

0
ответ дан 27 November 2019 в 23:17
поделиться

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

1
ответ дан 27 November 2019 в 23:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: