Я работал на предприятии, мы используем несколько проектов в проектах решений для пользовательского интерфейса, бизнес-логики и доступа к данным, базу данных и другую для печати... но теперь я нахожусь на новом предприятии, и менеджер говорит мне что мне не нужно делать весь этот проект, просто я должен сделать их в отдельный каталог в одном проекте в решении.
Я просто хочу знать, нужно ли мне убеждать его использовать несколько проектов!
Я действительно согласен с вашим менеджером.
Несколько проектов означают множественные сборки, много копий вокруг сборок и, как правило, более медленное время компиляции.
Если ваша единственная причина иметь несколько проектов - это улучшенная организация, тогда вы делаете это неправильно. Было бы так же эффективно использовать папки.
Некоторые обоснованные причины наличия разных сборок:
Я очень удивлен принятым ответом. Я работал в обеих средах и нашел несколько проектов в целом полезными. Фактическое решение по-прежнему зависит от вашей команды (если один проект не мешает вам достичь ваших целей, то это достаточно).
Я опираюсь на дядю Боба Принципы OOD относительно управления пакетами. Они не очень хорошо известны (особенно по сравнению с его принципами SOLID для дизайна классов), но они разумны.
Взято от дяди Боба Принципы OOD
Первые три принципа упаковки заключаются в объединении пакетов, они скажите нам, что положить внутри пакетов:
- REP Эквивалентность повторного использования выпуска Принцип. Гранулом повторного использования является гранула высвобождения.
- CCP Общие принципы закрытия Классы, которые изменяются вместе, упаковываются вместе.
- CRP Общие принципы повторного использования Классы, которые используются вместе упаковываются вместе.
Последние три принципа касаются связей между пакетами, и расскажите о показателях, которые оценивают структуру пакета система.
- ADP Принцип ациклических зависимостей График зависимости пакеты не должны иметь циклов.
- SDP Стабильные зависимости Принцип Зависит от направления устойчивости.
- SAP The Stable Абстракции Принцип Абстракция возрастает со стабильностью.
Они совпадают с моим личным опытом, в котором склонность к меньшему количеству проектов часто приводила к проблемам в моем опыте:
Меньше пакетов может привести к плохому управлению зависимостями. Отдельные проекты/сборки могут помочь сохранить внутренние/частные классы и члены, если они не должны быть
Как правило, во многих проектах вы разрабатываете очень стабильный и проверенный "ядро" набор библиотек, которые очень редко меняются. Сохранение этих компонентов в собственном проекте (или даже в решении) может помочь изолировать их от текущих изменений в уровнях более высокого уровня.
Большие проекты, возникающие в результате использования меньшего (или одного) проекта, могут быть очень неуправляемыми. Visual Studio не устанавливает, что ваш проект/решение отражает структуру вашего файла, поэтому организованный большой проект все еще может существовать как хаос на вашем диске.
Visual Studio достаточно умна, чтобы не перекомпилировать сборки, которые не имеют никаких изменений. По мере стабилизации ваших "основных" проектов они будут видеть меньше компиляций, что может сэкономить время компиляции.
Аналогично выше, использование меньшего количества проектов приводит к обязательному перекомпиляции кода - независимо от того, имеет ли он соответствующие изменения. Однострочное изменение в очень большом проекте приведет к полной перекомпиляции.
Конечно, у нескольких проектов могут быть и свои проблемы:
Вы должны быть уверены в своих зависимостях, чтобы избежать циклических ссылок (которые .NET обрабатывает достаточно хорошо, но Visual Studio работает для предотвращения)
Ваши решения могут стать достаточно большими, чтобы гарантировать подрешения, которые могут быть сложными для управления
Исходное время компиляции решения может быть медленнее
И, наконец, одна из редко используемых функций в .NET заключается в том, что один .DLL может содержать несколько модулей (фактически это несколько сборок, разделяющих один набор метаданных). Я бы не предложил использовать это, но интересно узнать, как это работает: http://www.codeproject.com/Articles/9364/Merging-NET-assemblies-using-ILMerge
Если вы только когда-либо имеете одно приложение, то один проект в порядке. Но я думаю, что это очень редко. В большинстве случаев у вас будет несколько приложений, поэтому, имея несколько проектов, вы можете повторно использовать компоненты между приложениями, не занимаясь хакерскими вещами, такими как совместное использование исходных файлов.
Я нашел интересную статью о важности структуры (будь то проект или папка) в приложениях. Я скажу, что когда вы открываете решение и видите список проектов, там имена дают мне указание о том, как было создано приложение. Etc
(Пример шаблона проектирования MVP)
Структура каталогов является фундаментальной для вашего кода
"Как расскажет любой дизайнер, это первые шаги в дизайне процесс, который считается для большинства. Первые несколько штрихов, которые создают формы, нести в себе судьбу остальных". - Кристофер Александр
(Кристофер Александр - архитектор. программист, он повлиял на многих людей, которые много думают о программирование. Его ранняя книга A Pattern Language была оригинальной вдохновение для движения шаблонов проектирования. Он долго думал и тяжело о том, как строить красивые вещи, и эти размышления кажутся в основном применимы и к разработке программного обеспечения.)
В интервью радио CBC Александр рассказал следующую историю (перефразируя здесь): "Я работал с одним из моих учеников. с очень трудным временем что-то строить. Он просто не знал как действовать вообще. Поэтому я сидел с ним, и я сказал это:" Слушай, начните с выяснения, что самое главное. Получи прямо сначала. Получите это прямо в своем уме. Не торопитесь. не быть слишком поспешным. Подумайте об этом некоторое время. Когда вы чувствуете, что имеете нашел это, когда в вашем сознании нет сомнений, что это действительно самое главное, тогда идите вперед и сделайте это самое важное вещь. Когда вы сделаете это самое важное, спросите себя, если вы можете сделать его более красивым. Сократите дерьмо, просто получите его прямо в вашей голове, если вы можете сделать это лучше или нет. Когда это будет сделано, и вы чувствуете, что не можете сделать это лучше, затем найдите следующий важная вещь. "
Каковы первые штрихи в приложении, которые создают общий форме? Это структура каталогов. Структура каталогов - это самое первое, что встретил программист при просмотре источника код. Все вытекает из него. Все зависит от этого. это явно один из самых важных аспектов вашего исходного кода.
Рассмотрим различные реакции программиста при встрече различные структуры каталогов. Для стиля" по отдельности "мысли программиста приложения могут быть такими:
" Я вижу. В нем перечислены все функции верхнего уровня приложения за один раз. Ницца. - Давай посмотрим. Интересно, где находится этот пункт.... О, вот он является. И все остальное, что мне понадобится, тоже здесь, все в то же место. Отлично ". Однако для поэтапного стиля, мысли программиста приложения могут быть примерно такими:" Эти каталоги ничего не говорят мне. Сколько функций в этом приложении? Ударь меня. Он выглядит точно так же, как и все остальные. Нет разницы вообще. Отлично. Здесь мы снова идем... - Хм. Интересно, где этот элемент. Я думаю, что его части на всем протяжении приложения, распространяются в все эти каталоги. У меня действительно есть все предметы, которые мне нужны? Я полагаю мы узнаем позже "." Интересно, все ли соглашение об именовании после чего. Если нет, мне придется искать это в этом другом директории. "Ух ты, посмотри бы размер этого сингла каталог... sheesh." Пакет по слоям в других доменах неэффективен
Из-за разделения проблем. Это значительно облегчит неожиданные ссылки между классами/объектами.
Для программистов WPF/Silverlight подумайте о шаблоне проектирования MVVM: разделение ViewModels и представлений на два разных проекта гарантирует, что в ViewModel нет ссылки на объект View.
Другим моментом является время сборки, которое может быть короче, поскольку все решение не будет перекомпилироваться каждый раз. Может быть хорошим аргументом для вашего менеджера (но это предположение может быть неправильным в зависимости от размера вашего решения).
Используйте разные проекты, если вам нужно
Разделенные двоичные файлы для вашего решения, поэтому вы гибки в подготовке и развертывании обновлений/обновлений.
Возможность управления плагинами
Использование, например, кодов С++ внутри вашего С#.
Используются многоразовые компоненты. Типы, объявленные в сборках, могут быть повторно использованы в разных приложениях вашей компании для обеспечения единого API.