I wanted to write a quick post about using query filters and automatically populating audit columns in Entity Framework Core since I see a lot of people doing this manually still. A common scenario in most applications is to do soft deletes on everything, typically with a column like “IsDeleted”. Another common scenario that is found almost universally in every system are audit columns like “DateCreated” and “DateUpdated”. This is actually very simple to implement, so this is going to be a fairly short post.
Continue reading “Query Filters and Automated Audit Columns”
Entity Framework Core query performance is something that comes up often when working on projects that rely on it heavily. I have often heard that Entity Framework is not performant enough which then leads to everything being written as a stored procedure. Usually this happens for two main reasons: developers aren’t familiar with how to write queries in a performant manner and developers that are more comfortable with SQL want to develop everything in their technology of choice. Entity Framework is not a silver bullet for everything. There are times when it simply can’t deliver the performance needed or when it is simply functionally incapable of doing what is necessary due to limitations of the framework. That being said, there is no reason you can’t write the vast majority of your application with it and reap all the benefits it provides.
Continue reading “Maximizing Entity Framework Core Query Performance”
In part one we set up our IdentityServer4 project and our data and core projects. If you haven’t read part one, you can do so here. In part two we’re going to add in an Angular web application using the implicit flow and an API that the web app will interact with. You can see the full source code here.
Continue reading “IdentityServer4 in ASP.NET Core Part 2”
Continue reading “IdentityServer4 in ASP.NET Core Part 1”
Continue reading “Using an Angular Shared Service”
Continue reading “Angular Interceptors”
Let me preface this blog post by saying that there are still times when a DTO makes sense. Also, this post is written from a .NET perspective, so some things may be different on your platform. What I want to address though is the tendency of many developers to just automatically create a set of DTOs for each layer for each domain model. As I mentioned in other blog posts, you should always think about why you are doing something before you are doing it. Continue reading “Think Before You Use The DTO Pattern”
That is, it’s dead if you are using Entity Framework Core. If you’re still using straight ADO.NET, or even just dapper, then the repository pattern still probably makes sense for you. If you’re using Entity Framework, then you really aren’t gaining much from doing so anymore. Five years ago, you could reasonably argue that it was beneficial to use the repository pattern, or some form of abstraction, over entity framework for the following reasons:
Continue reading “The Repository Pattern is Dead If You Use Entity Framework”
If you’ve worked with Asp.Net Core to create APIs then you have more than likely run into situations where you needed to return different sets of data for the same model. One way to accomplish this is request post processing using an ActionFilter. Lets start with a common scenario. We have an internal enterprise application and we have different types of users in the system. Users can call our API to get data on other users depending on their permission levels. We have three different types of users: Admin, HelpDesk, and Employee. Our class looks like this:
Continue reading “ASP.NET Core Request Post Processing”
I’ve always found validation to be one of the most difficult and tedious aspects of writing enterprise software. No matter how you organize your rules, you are going to usually end up with duplication. To make matters worse, the rules aren’t written by developers, they are created by the business. This causes a disconnect between knowledge and domain experts, and the people who are implementing the validation in the code. As the rules change over time, and as the developers who originally worked on the system move on, the validation becomes increasingly difficult to manage. As the system matures, it ultimately ends up becoming a significant source of pain for all those involved. That’s assuming, of course, that you even have validation in the first place.
Continue reading “Dealing with Validation – Domain vs Contextual”