
Dead simple auditing for ASP.NET Core apps
I wanted a reusable way of auditing database changes that required minimal setup, but would allow me to see what happened to an entity when it was changed.
I finally got around to creating one.
A personal Blazor blog.
Showing posts tagged Entity Framework.

I wanted a reusable way of auditing database changes that required minimal setup, but would allow me to see what happened to an entity when it was changed.
I finally got around to creating one.

Note:  This assumes you have read and understood the fab articles How to turbocharge your Entity Framework queries - Part 1  and Knowing the difference between IEnumerable<T> and IQueryable<T> . If not, please read them first.
It is important to understand where your code is executed when querying with Entity Framework, as this can make a big difference to the time required to execute your queries.

Like many, our database has rather a lot of naughty nullable columns that really should be non-nullable, so we end up with null data issues all over the place. One way to avoid this is to modify the property in the .edmx file to add a default value. However, this is slow and painful, and easy to forget.
As there is no use case we can foresee where you would want a null string property, we have taken the step of adding a constructor to the entity (generated in the T4 template) that initialises every string property to an empty string. This means that whenever you create a new entity, any string properties will be initialised, avoiding any null values.
However, this leaves you with a problem if you want to set a (non-empty) default value for a string.

Many of the extension methods that we use have a signature that takes an Expression<Func<TSource, bool>> rather than just a Func<TSource, bool> ? Ever wondered why? Do you even know what the difference is? No, nor do most people, but it's worth getting to know, as it can be useful.
It seems we aren't the only ones to find filtering and sorting child entity collections unnecessarily painful. Someone has been kind enough to write a Nuget package (part of a suite of them by the looks of things) that simplifies your code significantly.
This package removes the need for some of the tortuous hoops we had to negotiate before.
A fairly standard set up for me is to have a solution in which I have a Data project that contains an EF6 .edmx file, generated from an existing database. I then split the entities into a separate Entities project, and have a Repositories project that references them both.
The problem was, I wanted to write unit tests against the code, but couldn't work out how to do it. This post shows what didn't work, and then what did.
Update (15th May '18) : I have done something similar recently, and discovered that you don't seem to need to set EXEC permission on the stored procedure any more. not sure if this is because we upgra…
I previously blogged about a seemingly innocent LINQ problem that had me baffled for ages, which was how you sort or filter an entity’s child collection in Linq. For example, if you want to pull a collection of customers, and include all of their orders from this year, but none from earlier, then there doesn’t seem to be a simple way to do this in Linq. You need to do the query in two stages, the first which builds an anonymous type, and the second which links the to parts of it together. See that post for more details.
I also blogged about the problem of Linq not including child entities when doing joins, which requires you to cast the query to an ObjectQuery so you can use the Include() method on it.
The problem comes when you want to combine the two methods, meaning that your query needs to be constructed in two stages to ensure that the sorting or filtering of the child collection is done correctly, but you also need to cast the final result to an ObjectQuery before you send it out over WCF. The problem arises because you need to enumerate the query before doing the Include(), as that is the only way to ensure that the sorting is done, but calling AsEnumerable() gives you an IEnumerable (reasonably enough), which can't be cast to an ObjectQuery! So what's a fellow to do? Good question, and one that had me going for ages.
I came across an innocent-looking Linq problem the other day that really had me baffled for some time.
It's easiest explained using the ubiquitous Northwind database (although just about any other relational database would probably do). Suppose you want a list of customers with their orders. Pretty easy eh?
Erm no, it wasn't!
Linq is great for grabbing entity objects. The code is simple, and you end up with known objects that you can use.
But, when you want to deal with anything slightly off the beaten track, it gets a bit harder. For example, if you have a Linq query that returns an anonymous type, you can easily manipulate it in the same code block.
Here I detail an early exploration into the world of anonymous types