Недостатки и преимущества отдельных проектов / DLL в .NET? Сколько их слишком много?

Question

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

• Каковы преимущества разделения проектов / DLL?
• Каковы недостатки разделения проектов / DLL?
• Если я создам новое решение / DLL для каждого общего ресурса, не будет ли много проектов?
• После слишком большого количества проектов (например, 40+) это будет иметь некоторые негативные последствия для производительности IDE (VS.NET 2008)?

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

Answer 1

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

1. Каковы преимущества разделения Solutions / DLL?

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

2. Каковы недостатки разделения Solutions / DLL?

Основными недостатками, как говорили другие до меня, являются, прежде всего, сложность (управление, обслуживание), затем производительность (но это другое обсуждение, это не просто сказать)

3. Если я создам новое решение / DLL для каждого общего ресурса, не будет ли много решений?

Это зависит, во-первых, я думаю, что это может зависеть от выбора дизайна

4. После слишком большого количества решений (например, 40+) это будет иметь некоторые негативные последствия для производительности IDE (VS.NET 2008)?

Я не уверен в снижении производительности в IDE VS2008, но уверен, что это может повлиять на производительность при управлении одним решением из более чем 60 проектов, чем, например, 4 решения по 20 проектов в каждом .. Должно быть ясно, что производительность VS IDE может снизиться даже после открытия, например, 35 файлов вместе из одного или двух проектных решений.

В конце я думаю, что БОЛЬШОЙ, о чем я должен помнить, это то, что лучше "построить" именно то, что действительно нужно, чем, например, чрезмерно проектировать, поэтому, когда вещи становятся слишком сложными для управления (для многих проектов) ) лучше остановиться и подумать "все идет хорошо?"

Answer 2

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

• Ясность цели.
• Возможность заменить одну DLL и заставить остальную часть приложения работать как прежде.
• Повторное использование (хотя это действительно часто переоценивают *).

Недостатки

• Сложность в работе (простое перетасовывание между 7 проектами может быть проблемой).
• Возможность новых типов проблем зависимости (Проект A может ссылаться на Проект B или наоборот, но не на оба)
• Множество DLL для развертывания.

---

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

---

* Мы часто заставляем себя поверить, что будем использовать этот замечательный класс Ордена. Мы, вероятно, не будем. Доменные модели просто имеют тенденцию быть разными.

Answer 3

Основными недостатками лотов являются:

• сложность (огромное количество библиотек для управления и развертывания)
• производительность "fusion" (которую можно уменьшить с помощью ILMerge)

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

---

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

Answer 4

Я боролся с противоположностью вашей проблемы - слишком много библиотек и зависимостей.

Я не знаю ответов, но вот несколько вопросов, которые могут дать вам несколько полезных указателей.

Структурирование проектов и зависимостей больших приложений winforms в C #
Что вы делаете со ссылками при выгрузке проекта в Visual Studio?

Обратите внимание, что вы можете иметь разные пространства имен в одной и той же dll (и наоборот, вы можете распределить пространство имен по нескольким dll).

Для моих решений с большим количеством проектов у меня в настоящее время есть настройка, в которой у меня есть настраиваемая конфигурация сборки (щелкните в поле «Отладка / Выпуск» и выберите «Диспетчер конфигурации») под названием «WorkingSetOnly», где я могу выбрать компилировать или нет каждый проект при запуске - это ускоряет выполнение, но сохраняет intellisense, определение goto и т. д. Я также использую папки решений для организации проектов в два «сегмента» - WorkingSet и другие, хотя я пока не нашел способа связать два (конфиг и папки) автоматически.

Answer 5

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

         +------------> Core <------------+
         |               ^                |
         |               |                |
   Level Builder         |           Game Server
         ^               |
         |               |
         +-----------Game Client

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

Answer 6

Проблема круговой зависимости означает:

[Lib1]

[Project1]
  [ClassA]

[Project2]
  [ClassB]

если ClassA и ClassB ссылаются друг на друга, они должны быть извлечены в Lib1 и иметь ссылки Project1 и Project2 на Lib1, потому что очень трудно синхронизировать Project1 и 2 без этого.

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