Когда разделять код на новые сборки (DLL)

Question

Я работаю в команде, создающей корпоративное приложение, которое будет использоваться в новом приложении Windows на C # .NET и в таком же веб-приложении.Один из других разработчиков любит разделять вещи на отдельные проекты немного больше, чем я. Его ответ всегда «отдельный от проблем», с которыми я не уверен, что согласен.

Моя теория заключается в том, что вы создаете отдельные сборки, когда этот код может использоваться другими пользователями.Разделение проблем должно обрабатываться пространствами имен.Это может быть дополнительным усилием / вызовом / кошмаром для распространения приложения с большим количеством сборок от управления версиями, запутывания и т. Д. Так что это касается меня, и я пытаюсь выяснить, для чего нужно практическое правило, когда код нарушенв свою собственную сборку.

Каково ваше практическое правило для разделения кода на другие сборки по сравнению с использованием пространств имен и других методов организации в приложении?Есть ли какие-либо указания по этому поводу или образцы / практики, которые я могу прочитать, чтобы сказать «да, он прав» или «пожалуйста, прочитайте это».

Спасибо.

Answer 1

Я думаю, что у вас есть проблема со связью или проблема с номенклатурой, потому что разделение интересов, как правило, означает нечто иное.

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

Некоторыми примерами разделения интересов являются шаблоны абстракции представления и модели, такие как MVC или MVVM.В тех случаях, когда каждый компонент, будь то представление или модель, имеет дело с абстракцией пользовательского интерфейса или данными и проверкой, но не обоими.

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

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

Answer 2

Частично из-за рассуждений, уже предоставленных Shark (управление версиями и перекомпиляция / замена выбранных сборок, используемых более крупным приложением). Но я также склонен создавать сборки, когда они образуют независимо полезную и законченную единицу кода.

Например, я мог бы создать модуль синтаксического анализа для разбора HTML (глупое поручение, я знаю ... это пример!) Для использования в более крупном приложении. Если функциональность HTMLParsingUnit является относительно полной (другими словами, не специфичной для более крупного приложения), то я, скорее всего, создам ее в своей сборке как для повторного использования другим кодом, так и для инкапсуляции версий / изменений.

Точно так же мне когда-то приходилось создавать сопоставление и предоставлять классы типов данных от типов ASNI SQL до .NET CLR. Я создал для этого независимую DLL, так как подумал, что это может пригодиться в других проектах. Очевидно, что это означало бы абстрагирование компонентов сборки, но это облегчило обслуживание. В конечном счете, я повторно использовал эту сборку в нескольких разных проектах.

Только мои два цента. , ,

Answer 3

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

Но другое соображение для меня связано с версионированием. Если группировка кода будет часто улучшаться / масштабироваться, для меня легче иметь это как отдельную DLL, поэтому другие DLL / exe в проекте абсолютно не знают об изменениях, если только вызовы также не изменены.

Я думаю, что это две основные причины разделения кода на разные библиотеки DLL.