Entity Framework

Computed Properties and Entity Framework (Revisited)

Another way to use your computed properties in predicates and projections.

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.


Computed Properties and Entity Framework

How to use your computed properties in predicates and projections.

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.


Custom Entity Type Configurations in Entity Framework Code First (Part 2)

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.


Custom Entity Type Configurations in Entity Framework Code First (Part 1)

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.


open source (18) ASP.NET (15) ASP.NET MVC (14) static site generator (9) programming (8) Azure (7) Wyam (7) Roslyn (7) NuGet (6) devops (5) .NET Compiler Platform (5) Razor (4) personal (4) Vue.js (4) Entity Framework (4) LINQ (4) database (4) KendoUI (4) KendoUI MVC (4) grid (4) csharp (3) scripting (3) meta (3) T4 (3) XML (3) Mono (3) GtkSharp (3) tools (2) Cake (2) msbuild (2) magic strings (2) Azure Cosmos DB (2) Azure Functions (2) LINQ to Entities (2) strings (2) algorithms (2) LINQPad (2) blog (2) CSS (2) export (2) CSV (2) HtmlHelper (2) Entity Framework Code First (2) Nxdb (2) XQuery (2) Blazor (1) WebAssembly (1) Netlify (1) FTP (1) documentation (1) configuration (1) DSL (1) enum (1) stdin (1) stream (1) console (1) cli (1) npm (1) node (1) microdependencies (1) collections (1) concurrent (1) HashSet (1) Twitter (1) Serilog (1) MiniProfiler (1) logging (1) OWIN (1) templating (1) design (1) web (1) JavaScript (1) API (1) IIS (1) debugging (1) LINQ to SQL (1) FluentBootstrap (1) Bootstrap (1) RazorDatabase (1) GitHub (1) AppVeyor (1) fluent interfaces (1) method chaining (1) style (1) conventions (1) PDF (1) Acrobat (1) Excel (1) checkbox (1) postback (1) icon fonts (1) icons (1) SQL (1) SQL Server (1) round robin (1) DotNet (1) Dictionary (1) MultiDictionary (1) data annotations (1) persistence (1) object persistence (1) NiceThreads (1) Threading (1) Monitor (1) ReaderWriterLockSlim (1) locking (1) ILocker (1) networkdays (1) weekdays (1) ButtonPressEvent (1) Context Menu (1) ContextMenuHelper (1) Menu (1) Popup (1) Popup Menu (1) CellRenderer (1) TreeModel (1) TreeView (1) TreeViewColumn (1)