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