Вы храните свои вспомогательные классы в отдельной сборке?

Question

Я просто хочу знать, хранит ли кто-нибудь свои вспомогательные классы или методы в отдельной сборке и почему ... только для чистого управления ими? Я видел очень много сообщений об использовании вспомогательной папки внутри вашего MVC-проекта, и это возвращает меня к грязным старым временам в ASP.NET, где люди использовали папку App_code вместо того, чтобы просто физически разделить вещи, как это, в свой собственный проект. .

И, кроме того, никто, занимающийся реальной архитектурой, не собирается помещать модели в какую-либо папку в вашей веб-сборке MVC. Они будут идти в сборке MyApp.DataLayer или MyApp.Models или что-то вроде этого.

Answer 1

Да, но по причинам, которые являются общими и для других сборок

• Становится легко подключаться к любому другому проекту. (Может потребоваться несколько выпусков).
• Многоразовые
• Легко улучшить
• Легко преломляется
• Как не часть проекта, а проект само по себе, это легко документировать и легко понять разработчикам
• Устраняет некоторые беспорядок

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

Answer 2

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

Answer 3

Да, потому что они являются частью бизнес-уровня. Две большие выплаты:

• Возможность повторного использования
• Тестируемость

Имейте в виду, что ваши служебные функции и вспомогательные классы, вероятно, будут одними из наиболее интенсивно используемых компонентов всей вашей системы. Без полного тестирования BICEP вы рискуете получить неприемлемый риск.

Answer 4

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

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

Answer 5

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