Каковы общие причины разделения проекта разработки (например, приложения ASP.NET MVC) на несколько проектов? Организацию кода также можно выполнить с помощью папок. Множественные проекты, как правило, порождают конфликты циклических ссылок и усложняют их из-за необходимости управлять / разрешать их.
Итак, почему?
Некоторые причины
Инкапсуляция - упаковывая набор подпрограмм в другую библиотеку в виде статической библиотеки или набора DLL, он становится черным ящиком. Чтобы это был хороший черный ящик, все, что вам нужно сделать, это убедиться, что вы вводите правильные входные данные и получаете правильные выходные данные. Это помогает, когда вы повторно используете эту библиотеку. Он также обеспечивает соблюдение определенных правил и предотвращает программирование с помощью взлома ('хм ... Я просто сделаю эту функцию-член общедоступной')
Сокращает время компиляции - библиотека уже собрана; вам не нужно перестраивать его во время компиляции, просто сделайте ссылку на него (при условии, что вы работаете на C ++).
Разделение - заключая ваши классы в отдельные библиотеки, вы можете уменьшить взаимосвязь и позволить вам повторно использовать библиотеку для других целей. Точно так же, пока интерфейс библиотеки не меняется, вы можете вносить изменения в библиотеку сколько угодно, и другим, кто ссылается на нее или ссылается на нее, вообще не нужно менять свой код. Библиотеки DLL полезны в том аспекте, что не требуется повторной компиляции, но с ними может быть сложно работать, если многие приложения устанавливают разные версии одних и тех же библиотек DLL. Вы можете обновлять библиотеки, не затрагивая клиентский код. Хотя вы можете сделать то же самое только с папками, нет явного механизма, который бы заставлял такое поведение действовать.
Кроме того, практикуя эту дисциплину наличия разных библиотек, вы также можете убедиться, что написанное вами является универсальным и не связано с реализацией.
Лицензирование / коммерциализация - Думаю, это совершенно очевидно.
Одна из возможностей - иметь систему, над которой данная группа (или один разработчик) может работать независимо от остального кода. Другой - исключить общий служебный код, который нужен остальной части системы - на ум приходят такие вещи, как обработка ошибок, ведение журнала и общие служебные программы.
Конечно, когда вы думаете о том, что происходит в конкретной функции / классе / файле, где находятся границы, это вопрос искусства, а не науки.
Я могу вспомнить один пример: при разработке одного проекта вы можете найти библиотеку, которая может иметь более широкое применение и которая заслуживает быть отдельным проектом. Например, возможно, вы работаете над видеоигрой и в конечном итоге пишете аудиотеку, которая никоим образом не связана конкретно с игровым проектом.
Повторное использование кода. Допустим, у вас есть проект A, и вы запускаете новый проект B, который имеет многие из тех же функций, что и проект A. Имеет смысл вытащить общие части A и превратить их в библиотеку, которая может использоваться как A, так и B Это позволяет вам иметь код в обоих местах без необходимости поддерживать один и тот же код в двух местах.
Повторное использование кода в инвертированном виде. Допустим, у вас есть проект, который работает на одной платформе. Теперь вы хотите, чтобы он работал на двух платформах. Если вы можете отделить код, зависящий от платформы, вы можете запускать разные проекты для каждой библиотеки, зависящей от платформы, а затем скомпилировать свою центральную базу кода с разными библиотеками для разных платформ.
Несколько советов по разделению вашего проекта на несколько проектов:
Одна из причин разделения проекта на несколько библиотек классов - возможность повторного использования. Я еще не видел, чтобы часть приложения BLL или DAL повторно использовалась в другом приложении. Об этом нам рассказывали в учебниках 90-х годов! Но большинство, если не все современные приложения слишком специфичны, и даже на одном предприятии я никогда не видел, чтобы одни и те же части BLL или DAL повторно использовались в нескольких приложениях. В большинстве случаев то, что у вас есть в этих библиотеках классов, предназначено исключительно для обслуживания того, что пользователь видит в этом конкретном приложении, и это не то, что можно легко повторно использовать (если вообще).
Другая причина для разделения проекта на несколько библиотек классов связана с возможностью развертывания. Если вы хотите независимо создавать версии и развертывать эти части, имеет смысл пойти по этому пути. Но это часто вариант использования фреймворков, а не корпоративных приложений. Entity Framework - хороший пример. Он состоит из нескольких сборок, каждая из которых выполняет различные функции. У нас есть одна основная сборка, которая включает в себя основные артефакты, у нас есть еще одна сборка для общения с базой данных SQL Server, еще одна для SQLite и так далее. Благодаря этой модульной архитектуре мы можем ссылаться и загружать только те части, которые нам нужны.
Представьте себе, если бы Entity Framework была только одной сборкой! Это будет одна гигантская сборка с большим количеством кода, который нам не понадобится. Кроме того, каждый раз, когда группа поддержки добавляла новую функцию или исправляла ошибку, всю монолитную сборку приходилось скомпилировать и развернуть. Это сделало бы эту сборку очень хрупкой. Если мы используем Entity Framework поверх SQL Server, почему обновление из-за исправления ошибки SQLite должно влиять на наше приложение? Не должно быть! Вот почему он разработан по модульному принципу.
В большинстве существующих веб-приложений мы версируем и развертываем все эти сборки (Web, BLL и DAL) вместе. Итак, разделение проекта на 3 проекта не добавляет никаких значений.
Слои концептуальны. У них нет физического представления в коде. Наличие папки или сборки под названием BLL или DAL не означает, что вы правильно разложили свое приложение на уровни, и не означает, что вы улучшили ремонтопригодность. Ремонтопригодность - это чистый код, небольшие методы, небольшие классы, каждый из которых несет единственную ответственность, и ограниченную связь между этими классами. Разделение проекта с жирными классами и жирными методами на проекты BLL / DAL не улучшает ремонтопригодность вашего программного обеспечения. Сборки - это единицы управления версиями и развертывания. Разделите проект на несколько проектов, если вы хотите повторно использовать определенные его части в других проектах или если вы хотите независимо создавать версии и развертывать каждый проект.
Во-первых, владение. Если у вас есть разработчики, отвечающие за разные части кода, то разделение проекта на части - естественный поступок. Можно было бы также разделить проекты по функциональности. Это уменьшает конфликты и сложность. Если он увеличивается, это просто означает отсутствие общения, а вы просто делаете это неправильно.
Вместо того, чтобы подвергать сомнению ценность кода в нескольких сборках, подвергайте сомнению ценность объединения всего кода в одном месте.
Вы бы поместили все на кухне в один шкаф?
Циклические ссылки - это циклические ссылки, независимо от того, происходят ли они между сборками или внутри них. Конструкция проблемных компонентов, скорее всего, не оптимальна; По иронии судьбы отказ от организации через сборки мешает компилятору определить ситуацию за вас.
Я не понимаю утверждения, что вы можете организовать код с помощью папок так же хорошо, как и с проектами. Если бы это было правдой, в наших операционных системах не было бы концепции отдельных дисков; у них будет только одна гигантская структура папок. Организационные паттерны высшего порядка выражают намерения, отличные от простых папок.
В проектах говорится: «Эти концепции тесно связаны и только периферийно связаны с другими концепциями».
Здесь есть несколько хороших ответов, поэтому я постараюсь не повторяться.
Одним из преимуществ разделения кода на собственный проект является повторное использование сборки в нескольких приложениях.
Мне также понравился упомянутый функциональный подход (например, инвентаризация, доставка и т. Д. Могут иметь свои собственные проекты). Другая идея - рассмотреть модель развертывания. Код, совместно используемый слоями, уровнями или серверами, вероятно, должен находиться в собственном общем проекте (или в наборе проектов, если требуется более тонкий контроль). Код, предназначенный для определенного уровня, может находиться в собственном проекте. например если бы у вас был отдельный веб-сервер и сервер приложений, вы бы не захотели развертывать код пользовательского интерфейса на сервере приложений.
Еще одна причина разделения может заключаться в том, чтобы разрешить небольшие инкрементные развертывания, когда приложение находится в производстве. Допустим, у вас возникла аварийная производственная ошибка, которую необходимо исправить. Если небольшое изменение требует перестройки всего приложения (одного проекта), вам может быть сложно оправдать небольшой цикл тестирования для QA. Вам было бы легче продать, если бы вы развертывали только одну сборку с меньшим набором функций.
