Fluent API instead of MapValue attribute

Hi,

is it possible to define enum mappings WITHOUT using attributes, maybe with some kind of fluent API? The only possibility I see right now is to use the MapValue attribute:

public enum Gender
{
	[MapValue("M")] Male,
	[MapValue("F")] Female,
	[MapValue("U")] Unknown,
	[MapValue("O")] Other,
}

But I don’t like this approach (see my longer explanation below). Thank you in advance for any kind of help! Best regards,

Boris Turk

Our team is developing a bigger ERP system and we decided to use the onion architecture (together with dependency injection):

https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/

The inner part of our onion architecture are so-called domain objects. These are more or less just simple DTO classes (like Article, Address, Service) and some common enums, e.g.:

public enum DocumentPostingFlag
{
	[StorageValue(" ")]
	None,

	[StorageValue("O")]
	Open,

	[StorageValue("V")]
	Posted,
}

StorageValue is our own attribute, basically the same thing as MapValue. And here comes the problem: we would like to keep our core assemblies (like domain objects) independent of linq2db assembly. This kind of architectural rule looks quite restrictive at first glance, but it pays off in the long term. Most of our domain logic stays decoupled from a specific persistence technology. One day we might be forced to switch to another ORM provider and it will be easier to do that if we don’t make the majority of our system dependent on third-party code.

We were initially playing with the idea that we let our core assemblies depend on linq2db, but ensure that we keep the dependencies at minimum - i.e. only use the MapValue attributes and keep the rest of linq2db initialization (fluent API rules) in one of the marginal assemblies, at the boundary of onion architecture. But I don’t like this approach as it requires us to constantly monitor that the dependencies did not go out of control. This is hard to ensure in a team of 10 developers.

Let me point out that we were already able to isolate the majority of linq2db specifics into its own assembly which is defined at the boundary of our architecture. The only part of the puzzle that is still causing problems is MapValue.

[MaceWindu]

Not at all. Completely forgot about it and you reminded me to fix it

[dotarj]

Wow, thanks for the amazingly fast response! And sorry for not checking out the issues before asking.