I have an application that requires the use of a lot of different enumerations. The application can be devided into various layers. For the sake of the example let's assume three layers: a 3rd party analytics library, the application business logic and the UI/presentation logic.
In many cases all layers may have the need for an enum representing the same concept. Let's take a payment frequency for instance. (e.g. annual, semi-annual, quarterly etc...). The 3rd party library provides its own enum, the various classes in the business logic layer would need a similar enum, and finally the UI layer may need it for presenting various choices in dropdowns etc...
Now, normally I'd like to shield the user of each layer from its internal dependencies and implementation details by not exposing types from internal dependcies in the public interfaces of the layer. That means that even though the interaction with the 3rd party lib requires the use of its own "Frequency" enum, I'd need to create an equivalent "Frequency" enum for the business layer and potencially another one for the UI layer...
All of this requires a lot of mapping back and forth, with potencially lot of additional mapper classes. The adventage on the other hand is that each layer may decide to exclude values it does not need or support from its own version of the enum...
Now since I have to deal with a lot of enums, I was just wondering if this is generally a good thing to do, or am I just overcomplicating things?
I would say you're overcomplicating things. Why not have a separate project for shared entities like this? You can then have each assembly reference your Common
project to reference the necessary enums and still have them all totally independent of each other.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With