Организация вспомогательных или служебных классов проектов c#

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

23
.net c# helper helpermethods

6 ответов

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

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

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

Edit: возможно, я ответил на "большой" вопрос.

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

2

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

2

большинство из нас просто бросают их в папку "помощники".

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

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

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

1

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

1

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

1