I am currently in the process of abstracting and refactoring out EF for Dapper with Dapper.Contrib and the entity class definitions from EF are currently being generated by a T4 template. I have not swapped out the entities entirely for generic POCO base classes as yet as the EF implementation is functioning correctly and is serving as a reference implementation at this point in time.

As anyone who has worked with T4 templates will tell you, T4 likes to regenerate the associated code classes quite frequently, so decorating an auto-generated class is out of the question.

Using Dapper.Contrib, I need to decorate my class and key property definitions with attributes to enable the automatic CRUD operation functionality where object definitions don't conform to Dapper.Contrib's property naming convention. At the moment, the business logic layer works exclusively with the EF entity class definitions and refactoring this out at this point in time has been deemed not worth the time effort/cost.

This led to the decision to implement Dapper-specific objects that derive from the EF entity classes as a stop-gap until the Dapper implementation is proved to function correctly at which point, the EF classes can be refactored into plain POCO classes (and perhaps decorated with the Dapper.Contrib attributes as we'll only use Dapper from then onwards).

Code for review:

As mentioned, I am deriving from auto-generated EF entity classes and am wondering whether a more elegant or "better" solution exists for the following:

//Automatically generated class - cannot be changed
public class EFEntity
   public int EFEntityID { get; set; }

public class DapperEntity : EFEntity
   public DapperEntity()

   public DapperEntity(EFEntity efEntity)
       //Copy constructor implementation based on reflection.

   public new int EFEntityID
       get { return base.EFEntityID; }
       set { base.EFEntityID = value; }


Is there a better way to handle the derivation/overriding of this class for decorating its properties with attributes?

  • \$\begingroup\$ I don't know dapper, but check if it generates parial classes - I guess so - then this would be the preferred way to extend them. If they are EF models then definitely yes - but I'm confused about your question. You can also create a partial context and override the OnModelCreating method and configure your models there. \$\endgroup\$
    – t3chb0t
    Sep 7 '16 at 8:19
  • \$\begingroup\$ You can't change the access modifiers of an existing property in a partial class, so I'm not understanding what you are suggesting. \$\endgroup\$
    – toadflakz
    Sep 7 '16 at 8:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.