Архитектура проекта .NET

Question

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

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

Мой главный вопрос:

• Должны ли мы разбить их на отдельные библиотеки DLL, где у каждой службы есть свои собственные библиотеки DLL (например, product.services.serice1.dll, product.services.serice2.dll и т. Д.), Или мы должны объединить все эти службы в одну DLL, с различными пространствами имен, для разделения между ними. Это срок исполнения, есть ли разница между двумя? Кроме того, что является самым «приемлемым» стандартом, который одобрен сообществом (и Microsoft)?

Спасибо

Answer 1

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

Что касается производительности, то никакого реального влияния на количество загруженных библиотек DLL нет (если вы остаетесь в здравом уме и не обращаетесь к тысячам из них), но это влияние ОГРОМНО в процессе разработки, если вы придерживаетесь поведения VS по умолчанию кто любит копировать каждую ссылку в каталоге bin / debug каждого проекта. На средних и больших решениях (1000 классов) процесс сборки будет намного длиннее и сложнее.

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

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

Answer 2

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

Answer 3

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

Пол

Answer 4

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

Answer 5

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

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

После загрузки сборок производительность должна быть одинаковой.

Answer 6

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

Answer 7

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

Answer 8

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

• Разделение базы кода с помощью сборок .NET и проектов Visual Studio (8 страниц)
• Определение компонентов .NET с пространствами имен (7 страниц)