Организация c # проекта вспомогательных или служебных классов - PullRequest
24 голосов
/ 29 июля 2010

Каковы некоторые рекомендации, для которых вы должны иметь вспомогательные классы в проекте .NET?Ссылаясь на классы, отделенные от вещей бизнес-уровня, но от презентаций и приложений, таких как appSetting config manager и другой код, который иногда зависит от модуля или иногда используется во всем приложении.

Ответы [ 6 ]

19 голосов
/ 29 июля 2010

Я всегда позволяю вещам, подобным этому, быть довольно плавными. Это сказало:

  1. Я тестирую "вспомогательные" классы так же, как и любой другой класс. Это делает их, как правило, не статичными.
  2. Я могу начать с создания этих помощников как отдельных методов, когда это необходимо. Поскольку я считаю, что они нужны более чем в одном классе, я перенесу их в их собственный класс или класс «Утилиты» в том же проекте.
  3. Если я нахожу, что они нужны более чем в одном проекте, я перемещаю их выше в «иерархии»: от проекта к решению, от решения к подсистеме, от подсистемы к приложению, от приложения к библиотеке или инфраструктуре и т. Д. .
2 голосов
/ 29 июля 2010

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

2 голосов
/ 29 июля 2010

У меня почти всегда есть библиотека классов MyProject.Core в моем решении, куда я помещаю подобные вещи.

Редактировать: Я мог бы ответить на "больший" вопрос.

В одном проекте все зависит от размера проекта. В Руководстве по проектированию Microsoft говорится, что вам не следует создавать пространство имен, если в нем меньше пяти типов (поправьте меня, если я ошибаюсь в этом числе).

1 голос
/ 29 июля 2010

Мы помещаем такие классы в сборку под названием Common, например, предназначенную для ссылки на все проекты, которые в ней нуждаются, за исключением случаев, когда помощнику нужно использовать некоторые объекты бизнеса или базовые объекты.

1 голос
/ 29 июля 2010

Я склонен помещать их в пространство имен утилит. Либо в пространстве имен основного проекта, если они довольно общие, например MyProject.Utils.MyHelperClass, или, если они более конкретны, то подпространство имен MyProject.CRM.Utils.MyCRMHelperClass.

1 голос
/ 29 июля 2010

Большинство из нас просто выбрасывают их в папку «Помощники».

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

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

Даже тогда, пересмотреть.

...