Вы храните свои классы помощника в отдельном блоке?
Я просто хочу знать, хранит ли кто-либо их классы помощника или методы в отдельном блоке и почему... только для чистого управления ими? Я видел столько сообщений об использовании папки помощника в Вашем проекте MVC, и это возвращает меня грязным былым временам в ASP.NET, где люди использовали папку App_code вместо того, чтобы чисто выделить вещи физически как это в ее собственный проект.
И аналогично никто делающий реальную архитектуру не собирается поместить модели в некоторую папку в Вашем веб-блоке MVC. Они вошли бы в MyApp. Блок DataLayer или MyApp. Модели или что-то вроде этого.
5 ответов
Я использую проекты для разделения различных уровней в моих веб-приложениях или приложениях с формами. Это позволяет мне лучше соблюдать бизнес-правила. Кроме того, мне легче отследить, куда мне нужно идти, если я хочу внести изменения.
Но я видел, как люди используют папки, обозначающие слои в решении, но я думаю, что это немного беспорядочно.
Да, но по обычным причинам также с другими сборками
- Легко подключается к любому другому проекту (может потребоваться несколько редакций).
- Многоразовый
- Легко улучшать
- Легко рефрактировать
- Поскольку это не часть проекта, а сам проект , его легко документировать и легко понять разработчикам
- Очищает
Но, несмотря на все вышесказанное, ваша сборка, когда она будет готова, должна быть «хорошо сделанной» , в противном случае лучше оставить вспомогательные классы там, где они принадлежат .
У нас есть несколько помощников в отдельном проекте и несколько в веб-проекте. Я думаю, вы обнаружите, что некоторые из ваших помощников должны использовать абстракции, которые вы определили в вашем веб-проекте. И это часто заставит вас поместить эти хелперы в веб-проект, потому что вряд ли желательно иметь какой-то другой проект, имеющий ссылку на веб-проект. Я не считаю это тем же самым, что и использование App_Code. Это файлы, которые компилируются во время компиляции в вашей IDE, без особой "магии", которая применяется к App_Code.
Да, потому что они являются частью бизнес-уровня. Два больших преимущества:
- Возможность повторного использования
- Тестируемость
Имейте в виду, что ваши служебные функции и вспомогательные классы, вероятно, будут одними из наиболее часто используемых компонентов всей вашей системы. Без полного тестирования BICEP вы подвергаетесь действительно неприемлемому риску.
Большинство помощников, которые я создаю, обычно привязаны к конкретному слою, поэтому я стараюсь сохранить их вместе со сборкой базовой сборки, которая в них нуждается. Я не вижу причин добавлять в другой проект для хранения большого количества конкретных вспомогательных классов.