Since publishing my first post on the topic over a year ago, I've continued to look for easy ways to tackle this problem. In the last post, I ended up recommending the excellent DelegateDecompiler library to help convert plain unmapped properties to expression trees that LINQ to Entities can use. I still like this approach, but I've also been searching for a way to make this process a little more transparent and use a little less magic.
If you're using an ORM, it's not uncommon to have computed properties in addition to the ones that are stored directly in the database. Unfortunatly, these computed properties don't work with Entity Framework out of the box. In this post I'm going to discuss the problem and suggest various ways of mitigating it.
In my last post I discussed how to inherit from the
EntityTypeConfiguration class and use reflection to dynamically configure Entity Framework. In this post I'll expand on that technique by using a custom interface, reflection, and several helper classes to automatically apply Entity Framework configurations from arbitrary classes.
One of the things I really like about Entity Framework Code First is the way you can mix declarative configuration (I.e., by using Data Annotation attributes) with programmatic configuration for more complicated cases (I.e., by using the fluent API). The one aspect of this that really bothers me though is that in normal usage the fluent API commands end up being placed inside your
DbContext class removed from your actual entity. If you change some aspect of an entity that uses the fluent API for configuration, you have to remember to go check the
OnModelCreating() method to ensure you don't need to modify the code-based configuration. It would be much better (in my opinion) if all configuration, declarative and programmatic, were located close to the entity and/or encapsulated within it. This article explains one way of accomplishing this.