1

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!..

bAN
  • 13,375
  • 16
  • 60
  • 93

7 Answers7

7

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.

decyclone
  • 30,394
  • 6
  • 63
  • 80
  • 1
    Create a project Named Common where you can hold all your globally shared members. I am fully agree with [decyclone]. By doing this so will allow you to use your constants and variables to be accessed any where , any layer of the app without recreating every thing. –  Dec 31 '10 at 15:02
  • +1 Agreed, it will allow you to manage dependencies and abstraction more easily. – Adrian K Jan 01 '11 at 01:45
  • Ok, so a kind of 'transversal' layer referenced by all the others? – bAN Jan 02 '11 at 14:51
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.

David
  • 208,112
  • 36
  • 198
  • 279
2

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.

Mariusz
  • 1,409
  • 12
  • 25
1

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.

Joe Enos
  • 39,478
  • 11
  • 80
  • 136
1

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.

Marlon
  • 346
  • 4
  • 12
0

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)

tster
  • 17,883
  • 5
  • 53
  • 72
  • Ok thanks for mention me I was wrong I speak about structs but it is well enum, I edit my post.. Thanks – bAN Dec 31 '10 at 14:37
0

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

Andrew Sehr
  • 342
  • 1
  • 4
  • 13
  • BLL will be the more practical place (center) but is this really clean? Enum is not really a business component.. – bAN Dec 31 '10 at 14:44
  • Yes I believe this is the cleanest place to place the Enum because it's going to be used throughout the business level. That is just my personal preference. – Andrew Sehr Dec 31 '10 at 14:46