Где хранить файлы классов?

Question

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

Services 
-all my .cs files that are service(business logic) 

Data 
- Mapping 
    - nhibernate mapping files 

Domain 
    - domain files 

Я также создавать другие папки, такие как, например, я делаю вещи с квадратным так для всех в class files для нее в папка под названием "foursquare"

но то, что я не знаю, где положить one off class files. Например, у меня есть "HtmlWhiteList" class, что является единственным видом белого списка.

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

Любые предложения, куда класть файлы классов, которые не заслуживают собственной папки?

Answer 1

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

Answer 2

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

Answer 3

Иногда я создал папку «Утилиты», в которой хранятся другие материалы. Вещи обычно идут туда, а затем мигрируют где-то еще, когда у них есть другие классы, которые похожи ... но иногда они остаются там. Конечно, это очень субъективно для личных предпочтений.

Answer 4

Мы прекратили использовать этот вид конструкции. В итоге у него были папки, такие как «перечисления», «интерфейсы», «сущности». Когда вы пишете код для функции, скажем, функция «заказы», ​​вам нужны все пространства имен, чтобы получить нужные вам типы, потому что классы, связанные с заказами, распределены повсеместно. Таким образом, мы изменили структуру, ориентированную на объекты, с такими пространствами имен, как «заказы», ​​«статьи», «пользователи» и т. Д.

Существует посоветуете в .Net naming guidelines, Names of Namespaces:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>] 

К особенностью которой принадлежит HtmlWhiteList? К безопасности? К клиентским сеансам? Я не могу сказать, потому что я не знаю, что это.

Answer 5

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

Если вы не считаете, что это считается удаленным, то оно заслуживает места.

Если он используется редко, то вы должны точно знать, кто его использует и каково его влияние на них, - тогда вы должны немедленно узнать, куда его поместить: где-то рядом с ними.

Если такого места нет, создайте его и живите вместе с ним. По мере роста проекта, когда лучшее место материализуется, вы всегда можете его переместить. Если посмотреть на свою структуру проекта, если это настоящая утилита, то служба предназначена не для «BusinessLogic», а для «Службы и утилиты». Если yo umodel ваш BL как «услуга», то это ваш выбор, но это не значит, что все сервисы BL.

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