What is the Best place to store constants in n-tiers asp.net App?

Question

I wonder what is the best place to store the enums I should use like constants in my n-tiers Application.

So I have an application with a DAL(connect to database), a BLL(Business processes), a Data Transfert object "Layer" (classes without any methods but just fields, this one is reacheable by all the others) and the interface layer with the asp pages.

My question is : I have a enum:

 public enum ID_FOO : uint
 {
     ALL = 1,
     FOOOne= 2,
     FOOTwo= 3
 }

Where can I put this enum(and all the others) to be clean? Not in the Data Access Layer the Interface layer will not see the struct, not in the Business Logic Layer, this is not really business.. Maybe in the Data Transfert Object but is it really a "Transfert object"? Should I Create an another layer??

Thanks for all responses!..

Answer 1

I think it depends on what layers will access this struct.

You say it will be accessed by DAL and DTOs. If used by DTOs, I feel it will also be exposed to any layer that uses DTO layer.

If you feel its not part of BAL, create a seperate assembly (Common) to share such types and reference to that assembly instead. This will keep it clean.

Answer 2

It sounds like this enum (as well as other constants) is part of your domain's ubiquitous language, and therefore should be available everywhere. Ideally, the components which make up the ubiquitous language would be in their own assembly (their own project) which is referenced by all other projects in the domain, regardless of tier.

Based on your description, it sounds like your DTOs are also part of the ubiquitous language. (Think of them as anemic models, quite often necessary in a domain with hard service boundaries.) Devoid of any other dependencies, these things should make up a core assembly which all other projects reference.

Answer 3

I'd suggest a "cross-cutting" layer that contains code that could be shared among any layer in your structure. This could be where you put this kind of thing, along with logging, security, or other things that might be needed across layers.

Answer 4

I store these kinds of things in the layers that make the most contextual sense. If an enum or struct blatantly belongs to a particular domain in your application, based on its context, then I would put it in the relevant layer. However, if it lands up being one that can potentially span across multiple domains, then by all means whack it in its own layer. Just be sure to organize them all in such a manner that makes contextual sense to your application.

Answer 5

What you are showing there is not a struct, but an enum, which I assume will be used by all other layers and would go in your "Transfert" layer. (NOTE: I have never heard of a transfert layer before)

Answer 6

I personally would put this in the Business level because I would be using these enums with other classes in my business layer.

Answer 7

We usually have a CompanyName.ProjectName.Core library project, where we are storing our enums, utility, constants etc. in it. This dll is referenced in almost every project included in this solution.