Where to store class files? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

I usually make a separate class library for my projects and then break it up into folders

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

Data
 - Mapping 
   - nhibernate mapping files

Domain
  - domain files

I also create other folders like for instance I am doing stuff with foursquare so for all the class files for it are in a folder called "foursquare"

but what I don't know where to put one off class files. Like for instance I have "HtmlWhiteList" class what is the only kind of white list.

I don't think it should have it's own folder since it is just one file but at the same time I don't like just having it in the root.

Any suggestions where to put class files that don't deserve their own folder?

Answer 1

As a general rule of thumb, I put new class files just in the root of the other class calling it. If I get 5 or more similar classes, I'll create a folder and put them in the folder on that same level.

Answer 2

Sometimes I've created a "Utilities" folder that holds other stuff. Things normally go there and then migrate somewhere else once they have other classes that are similar... but sometimes they stay there. Certainly this is very subjective to personal preference.

Answer 3

I would just put it in with the classes of the code that call it. Otherwise just give it its own folder, there's no guarantee that it will always be the only class that belongs there. I think this is more an opinion question than one with a concrete answer, though.

Answer 4

We stopped using this kind of structure. It ended up in having folders like "enums", "interfaces", "entities". When you write code for a feature, lets say the feature "orders", you need all namespaces to get the types you need, because orders-related classes are distributed all over the place. So we changed to a feature oriented structure with namespaces like "orders", "articles", "users" and so on.

There is an advise in the .Net naming guidelines, Names of Namespaces:

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

To which feature belongs the HtmlWhiteList? To security? To the client sessions? I can't tell you, because I don't know what it is.

Answer 5

If you dont know what it does or who uses it and therefore you dont know where to put it, or the thing it does is trivial so it does not deserve having a place, then remove it completely.

If you do not think it is deemed to be removed, then it deserves a place.

If it is used scarcely, then you should exactly know who uses it and what is it's impact on them - then you should instantly know where to put it: somewhere near them.

If there is no such place, create it and live with it. As the project grows, when a better place gets materialized, you can always move it there. Looking at your project structure, if it is true utility, then Service is for not for "BusinessLogic", but for Services and Utilities. If yo umodel your BL as a "service", then that's your choice, but that does not mean the all services are BL.

If there are so many scattered users of this class so that you cannot decide who is more important or more relevant, then create it as a new module/library/folder since it is heavily used and in fact important.