Причины разделить проект на несколько проектов?
Каковы общие причины разделения проекта разработки (например, приложения ASP.NET MVC) на несколько проектов? Организовать код можно также с помощью папок. Многочисленные проекты имеют тенденцию генерировать конфликты циклических ссылок и увеличивать сложность, имея необходимость управлять / разрешать их.
Так почему же?
8 ответов
Некоторые причины
Инкапсуляция - упаковывая набор подпрограмм в другую библиотеку, в виде статической библиотеки или набора библиотек, он становится черным ящиком. Чтобы это был хороший черный ящик, все, что вам нужно сделать, это убедиться, что вы даете правильные входы и получаете правильные выходы. Это помогает при повторном использовании этой библиотеки. Он также обеспечивает соблюдение определенных правил и предотвращает программирование с помощью хаков ("хм... я пока сделаю функцию-член публичной")
Сокращает время компиляции - библиотека уже собрана; вам не нужно перестраивать его во время компиляции, просто ссылку на него (при условии, что вы делаете C++).
Разделение - объединяя ваши классы в автономные библиотеки, вы можете уменьшить сцепление и позволить вам повторно использовать библиотеку для других целей. Аналогично, до тех пор, пока интерфейс библиотеки не изменяется, вы можете вносить изменения в библиотеку так, как вам нравится, и другим, кто ссылается на нее или ссылается на нее, вообще не нужно менять свой код. Библиотеки DLL полезны в этом аспекте, так как повторная компиляция не требуется, но с ними сложно работать, если многие приложения устанавливают разные версии одних и тех же библиотек DLL. Вы можете обновлять библиотеки, не влияя на код клиента. Хотя вы можете сделать то же самое только с папками, не существует явного механизма для принудительного такого поведения.
Кроме того, практикуя эту дисциплину наличия разных библиотек, вы также можете убедиться, что написанное вами является общим и отделенным от реализации.
Лицензирование / коммерциализация - ну, я думаю, это совершенно очевидно.
Одна возможность состоит в том, чтобы иметь систему, с которой данная группа (или один разработчик) может работать независимо от остальной части кода. Другой - выделить общий код утилит, в котором нуждается остальная часть системы - на ум приходят такие вещи, как обработка ошибок, ведение журнала и общие утилиты.
Конечно, просто думать о том, что происходит в конкретной функции / классе / файле, где находятся границы, - дело искусства, а не науки.
Несколько советов по разделению вашего проекта на несколько проектов:
Одной из причин разделения проекта на несколько библиотек классов является возможность повторного использования. Я еще не видел, как 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 не улучшает возможности сопровождения вашего программного обеспечения. Сборки являются единицами управления версиями и развертывания. Разделите проект на несколько проектов, если вы хотите повторно использовать определенные части этого в других проектах, или если вы хотите независимо версии и развертывания каждого проекта.
Один пример, который я могу вспомнить, заключается в том, что при разработке одного проекта вы можете найти библиотеку, которая может иметь более общее использование и которая заслуживает того, чтобы быть ее собственным проектом. Например, возможно, вы работаете над видеоигрой, и в итоге вы пишете аудио библиотеку, которая никоим образом не связана конкретно с игровым проектом.
Повторное использование кода. Допустим, у вас есть проект A, и вы начинаете новый проект B, который имеет многие из тех же функций, что и проект A. Имеет смысл извлечь общие части A и превратить их в библиотеку, которая может использоваться как A, так и B Это позволяет вам иметь код в обоих без необходимости поддерживать один и тот же код в двух местах.
Повторное использование кода, перевернутый. Допустим, у вас есть проект, который работает на одной платформе. Теперь вы хотите, чтобы он работал на двух платформах. Если вы можете отделить зависимый от платформы код, вы можете запустить разные проекты для каждой зависимой от платформы библиотеки, а затем скомпилировать свою центральную кодовую базу с различными библиотеками для разных платформ.
Вместо того, чтобы ставить под сомнение значение кода в нескольких сборках, поставьте под сомнение значение объединения всего кода в одном месте.
Вы бы положили все на своей кухне в один шкаф?
Циркулярные ссылки являются круговыми ссылками, независимо от того, происходят ли они между сборками или внутри них. Дизайн неисправных компонентов, скорее всего, неоптимален; Отказ от организации с помощью сборок, по иронии судьбы, не позволяет компилятору определить ситуацию для вас.
Я не понимаю утверждения, что вы можете организовать код так же хорошо, как и папки, и проекты. Если бы это было правдой, в наших операционных системах не было бы концепции отдельных дисков; у них была бы только одна гигантская структура папок. Организационные шаблоны более высокого порядка выражают иной тип намерений, чем простые папки.
Проекты говорят: "Эти понятия тесно связаны, и только периферийно связаны с другими понятиями".
Здесь есть несколько хороших ответов, поэтому я постараюсь не повторяться.
Одним из преимуществ разделения кода на собственный проект является повторное использование сборки в нескольких приложениях.
Мне также понравился упомянутый функциональный подход (например, Inventory, Shipping и т. Д. Могут получить свои собственные проекты). Другая идея - рассмотреть модель развертывания. Код, совместно используемый слоями, уровнями или серверами, вероятно, должен находиться в его собственном общем проекте (или в наборе проектов, если требуется более точное управление). Код, предназначенный для определенного уровня, может быть в его собственном проекте. Например, если у вас есть отдельный веб-сервер и сервер приложений, вы не захотите развертывать код пользовательского интерфейса на сервере приложений.
Другая причина разделения может состоять в том, чтобы разрешить небольшие инкрементные развертывания после запуска приложения. Допустим, вы получили аварийную ошибку производства, которую необходимо исправить. Если небольшое изменение требует перестройки всего (одного проекта) приложения, вам может быть трудно оправдать небольшой цикл тестирования QA. Возможно, вам будет проще продавать, если вы развертываете только одну сборку с меньшим набором функций.
Владение с одной стороны. Если у вас есть разработчики, отвечающие за разные части базы кода, то разделение проекта - это естественная вещь. Можно также разделить проекты по функциональности. Это уменьшает конфликты и сложность. Если оно увеличивается, это просто означает отсутствие общения, и вы просто делаете это неправильно.