Причины разделить проект на несколько проектов?

Question

Каковы общие причины разделения проекта разработки (например, приложения ASP.NET MVC) на несколько проектов? Организовать код можно также с помощью папок. Несколько проектов, как правило, создают конфликты циклических ссылок и усложняют необходимость управлять ими / разрешать их.

Итак, почему?

Answer 1

Некоторые причины

Инкапсуляция - упаковывая набор подпрограмм в другую библиотеку, в виде статической библиотеки или набора библиотек, он становится черным ящиком. Чтобы это был хороший черный ящик, все, что вам нужно сделать, это убедиться, что вы даете правильные входы и получаете правильные выходы. Это помогает при повторном использовании этой библиотеки. Он также обеспечивает соблюдение определенных правил и предотвращает программирование с помощью хаков («хм ... я пока сделаю этот элемент открытым для всех»)

Сокращает время компиляции - библиотека уже собрана; вам не нужно перестраивать его во время компиляции, просто ссылку на него (при условии, что вы делаете C ++).

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

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

Лицензирование / коммерциализация - ну, я думаю, это совершенно очевидно.

Answer 2

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

Конечно, просто думать о том, что происходит в конкретной функции / классе / файле, где находятся границы, - дело искусства, а не науки.

Answer 3

Несколько советов по разделению вашего проекта на несколько проектов:

Одной из причин разделения проекта на несколько библиотек классов является возможность повторного использования. Я еще не видел, как часть приложения 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 не улучшают ремонтопригодность вашего программного обеспечения. Сборки являются единицами управления версиями и развертывание. Разделите проект на несколько проектов, если хотите повторно использовать определенные части этого в других проектах, или если вы хотите независимо версии и развертывания каждого проекта.

Источник: https://programmingwithmosh.com/csharp/should-you-split-your-asp-net-mvc-project-into-multiple-projects/

Answer 4

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

Вы бы поместили все на своей кухне в один шкаф?

Циркулярные ссылки являются круговыми ссылками, независимо от того, происходят ли они между сборками или внутри них. Конструкция неисправных компонентов, скорее всего, не оптимальна; Отказ от организации через сборки по иронии судьбы мешает компилятору определить ситуацию для вас.

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

Проекты говорят: «Эти понятия тесно связаны, и только периферийно связаны с другими понятиями».

Answer 5

1. Повторное использование кода. Допустим, у вас есть проект A, и вы начинаете новый проект B, который имеет много тех же функций, что и проект A. Имеет смысл извлечь общие части A и превратить их в библиотеку, которая может использоваться как A, так и B Это позволяет вам иметь код в обоих без необходимости поддерживать один и тот же код в двух местах.

2. Повторное использование кода, инвертировано. Допустим, у вас есть проект, который работает на одной платформе. Теперь вы хотите, чтобы он работал на двух платформах. Если вы можете отделить зависимый от платформы код, вы можете запустить разные проекты для каждой зависимой от платформы библиотеки, а затем скомпилировать свою центральную кодовую базу с различными библиотеками для разных платформ.

Answer 6

Один пример, который я могу вспомнить, заключается в том, что при разработке одного проекта вы можете найти библиотеку, которая может иметь более общее использование и которая заслуживает того, чтобы быть ее собственным проектом. Например, возможно, вы работаете над видеоигрой, и в итоге вы пишете аудио библиотеку, которая никоим образом не связана конкретно с игровым проектом.

Answer 7

Здесь есть несколько хороших ответов, поэтому я постараюсь не повторяться.

Одним из преимуществ разделения кода на собственный проект является повторное использование сборки в нескольких приложениях.

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

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

Answer 8

Владение за одну вещь. Если у вас есть разработчики, ответственные за разные части базы кода, то разделение проекта - это естественная вещь. Можно также разделить проекты по функциональности. Это уменьшает конфликты и сложность. Если оно увеличивается, это просто означает отсутствие общения, и вы просто делаете это неправильно.