Организация сборки (сборка) в C#

Question

Скажите, что вы пишете приложение, такое как Photoshop, где у вас есть эффекты (фильтры) и т. Д., Следует ли сделать каждый из этих фильтров отдельной сборкой с использованием отдельного проекта?

Основная идея состоит в том, чтобы каждый из этих фильтров, как узлы, так что думать о нем, как:

sourceImage -> Sharpen -> Darken -> Contrast -> Blur ... 

Мне кажется, что было бы целесообразно иметь DLL файлы, такие как:

[Filters folder] 
Sharpen.dll 
Darken.dll 
Contrast.dll 
Blur.dll 

Но было бы сложно управлять ими так, и это помешало бы мне использовать ключевое слово internal для членов класса, не так ли?

Так что прямо сейчас у меня есть только 1 dll для всех фильтров.

Каковы наилучшие методы организации сборок?

Answer 1

Я бы не ограничился одним фильтром на сборку. Возможно, вам захочется сгруппировать сборки, которые реализуют аналогичную функциональность - например. цвет/контраст, сохраняя при этом их отдельные фильтры очень разных типов (например, усиливающие края).

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

Answer 2

Я думаю, что лучший способ может быть, чтобы иметь сборки фильтров с Sharpen, Darken, Contrast и Blur пространств имен для типов в этой сборке. На самом деле все зависит от того, насколько модульным вам нужен каждый бит функциональности.

Answer 3

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

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

Answer 4

Patrick Smacchia автор инструмента NDepend предлагает, чтобы количество сборок поддерживалось на низком уровне. Посмотрите here. Это также подразумевает определенный уровень, который вы используете NDepend для управления зависимостями между пространствами имен. Кроме того, компиляция выполняется быстрее, если у вас меньше сборок и развертывание проще.

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

Answer 5

Причины иметь отдельные узлы:

• Вы можете развернуть их по отдельности и загружать их во время выполнения с помощью отражения (то есть плагины). Но убедитесь, что этот уровень дополнительной сложности стоит того.
• Вы можете отделить свою бизнес-логику от своего пользовательского интерфейса и теоретически (иногда на практике) иметь отдельный интерфейс.
• У вас есть библиотека служебных классов, которую вы можете использовать как в Windows Forms, так и в приложении ASP.NET.
• Вы можете поместить свою бизнес-логику в DLL, а затем иметь DLL модульных тестов для реализации этого кода.
• Наряду с последним моментом вы можете настроить некоторые сборки только для работы в режиме отладки или выпуска. Таким образом, вы можете собрать свою тестовую сборку только в режиме отладки и не отправлять ее в режиме деблокирования. Или у вас может быть дополнительная вспомогательная программа (возможно, для установки), которая только строит для Release.

Причины, чтобы избежать отдельных сборок:

• Это добавляет сложности. Не размещайте свой код на нескольких сборках только на основе теоретического «моделирования» вашей программы. Удостоверьтесь, что дополнительная сложность фактически приобретает вам некоторую большую ценность.
• Он замедляет сбор/сборку.
• Вы не можете иметь круглые ссылки между сборками, поэтому вам нужно перепрыгнуть через множество обручей и «аббревиатуры водопровода», если вы обнаружите, что ваша сборка должна получить доступ к классам и методам из сборки более высокого уровня. Например, если ваша сборка Windows Forms UI (.exe) вызывается в DLL бизнес-логики, DLL не может ссылаться на классы пользовательского интерфейса без большого взаимодействия с интерфейсами и передачи ссылок по уровням.

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