ardalis / SmartEnum

A base class for quickly and easily creating strongly typed enum replacements in C#.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

parameterless constructor

hanslai opened this issue · comments

Commit #16's parameterless constructor is not in the source code anymore. Is there a reason for this?

In order to put the smartEnum into a EF Core Table, now I need to do the following for the constructor

// base("default", "default") should not be needed.  and it adds confusion for programmer I think.
protected BaseOptionType() : base("default", "default")  
     {
         IsRequired = false;
     }

EF Core Value Conversions does not work for me, because I do want to save both name and value into the database, so user can add record to it later as well.

related issues
#16
#15

I think it was removed because the class is abstract, so you would never create it directly anyway. Any child type you create can have its own parameterless constructor in order to support EF/EF Core. I see you're doing that - is the issue just that you have to pass so much code into it or what?

It is fine that the child type add its own parameterless constructor.
but it bothers me that the child type need to pass in two random strings into its base class
protected BaseOptionType() : base("default", "default")

I think that it is unnecessary noise for the programmers, two empty strings won't pass the compiler, protected BaseOptionType() : base("", "") we have to input some some strings. in our case, I choice the word "default", but whoever need to work this code will wonder, what does "default" do? what does it mean? is there another string option there?

so, I feel that it is more clear and clean for the child type if SmartEnum's abstract class provide the parameterless constructor.

Thank you for you reply.

By the way, I learn my DDD concept form you course. It helps me a lot. Thank you. :)

Is this still an issue and if so how would you recommend implementing a constructor in the base abstract class? Should it just do nothing and leave its name and value fields uninitialized?

#16 works fine I believed, It require less noise code in the child type when people need to use EF Core. Yet, it is fine that if you decide not to add it back. Feel feel to close this issue.