Похоже, у вас есть сборка большого размера, в которой есть все общие функции (поправьте меня, если я ошибаюсь).
Как и в большинстве случаев, у этого подхода есть свои преимущества и недостатки.которые зависят от ваших потребностей.
В («устаревшей», но, вероятно, все еще актуальной) статье Повышение производительности управляемого кода фактически рекомендуется «Предпочитать одиночные большие сборки, а не несколько меньших сборок».Я не уверен, будет ли какое-либо влияние на производительность заметным.Если бы они были заметны, я бы подумал, что это будет только при запуске.
Даже если весь ваш код находится в одной сборке, для простоты использования я бы рекомендовал логически разделить функциональные области на отдельные пространства имен.Использование слова «куча», по-видимому, подразумевает, что это может быть не так.
С положительной стороны:
- Добавление ссылки на одну сборку легко сделать
- Развертывание может быть проще, поскольку развернуть можно только одну сборку (сложнее испортить?)
- Потенциальные улучшения производительности
С отрицательной стороны:
- Если 90% ваших пользователей используют только 5% реальной функциональности, тогда может не стоить загружать всю сборку
- Одна сборка может затруднить соблюдение архитектурных / проектных стандартов,Например, если уровень пользовательского интерфейса не должен напрямую взаимодействовать с уровнем данных, вероятно, не имеет смысла предоставлять доступ к общим функциям доступа к данным.Одна сборка может упростить обнаружение такой «ошибки».«Почему вы ссылаетесь на сборку доступа к данным из пользовательского интерфейса?»
Как я уже упоминал ранее, я думаю, что более важной, чем фактическая упаковка сборки, является логическая группировка функций в этой сборке.В вашей сборке Enterprise.dll я ожидаю увидеть несколько пространств имен, которые организовали функциональность.например, Enterprise.Logging, Enterprise.Caching, Enterprise.Validation, Enterprise.DataAccess, Enterprise.Security и т. д.