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