Skip to main content

Azure Application Insights Logging and EF Core in a Domain Driven Design

Logging is one of the core pillars of application development. .NET Core has fantastic support for rich contextual logging which spans across distributed system using its Activity API. Azure Application Insights SDK offers extensive logging out of the box without writing a single line of code. Just wire up the SDK and you are good to go. However there may be situations where you may want more fine grained control over the logging experience. Fortunately, its as simple as writing:

Activity activity = new Activity("Test Message");
var operation = telemetryClient.StartOperation<DependencyTelemetry>(activity);

This TelemetryClient is injected in your application when you wire up Application Insights.

services.AddApplicationInsightsTelemetry(options => options.InstrumentationKey = "YOUR_AI_KEY");

This works seamlessly till you hit the road block of Domain Driven Design and Entity Framework Core. In DDD, entities represent a real-world business object and performs equivalent operations. To use these objects with EF Core, they must have a parameter-less public constructor. So how will we inject our TelemetryClient?

Fortunately EF Core allows injecting DbContext in entity classes. So in the highly contrived example in the linked Github repository, you can create a public property for TelemetryClient in your DbContext class.

public class SchoolContext : DbContext
        public TelemetryClient AppInsightsClient { get; }
        public DbSet<Student> Students { get; set; }
        public DbSet<Course> Courses { get; set; }

        public SchoolContext(TelemetryClient telemetryClient)
            this.AppInsightsClient = telemetryClient;

        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)

Now this telemetry client can be accessed in your entity classes like this:

public class Student
        private readonly TelemetryClient telemetryClient;
        public int StudentId { get; set; }
        public string Name { get; set; }

        public Student()


        public Student(TelemetryClient client)
            this.telemetryClient = client;

        private Student(SchoolContext context)
            this.telemetryClient = context.AppInsightsClient;

         //Snip for brevity

This allows the Entity classes to still have an instance of TelemetryClient while still preserving the principles of DDD and allowing direct consumers of your class to instantiate it without any issue.

Also with the magic of .NET Core Activity API, logs generated in a single request are grouped together in a nice visual representation in Application Insights without you having to do anything.

Application Insights Structured Logs

If you have a better way of doing this, dear reader, please let me know in the comments!


Popular posts from this blog

Integrating React with SonarQube using Azure DevOps Pipelines

In the world of automation, code quality is of paramount importance. SonarQube and Azure DevOps are two tools which solve this problem in a continuous and automated way. They play well for a majority of languages and frameworks. However, to make the integration work for React applications still remains a challenge. In this post we will explore how we can integrate a React application to SonarQube using Azure DevOps pipelines to continuously build and assess code quality. Creating the React Application Let's start at the beginning. We will use npx to create a Typescript based React app. Why Typescript? I find it easier to work and more maintainable owing to its strongly-typed behavior. You can very well follow this guide for jsx based applications too. We will use the fantastic Create-React-App (CRA) tool to create a React application called ' sonar-azuredevops-app '. > npx create-react-app sonar-azuredevops-app --template typescript Once the project creation is done, we

Centralized Configuration for .NET Core using Azure Cosmos DB and Narad

We are living in a micro services world. All these services are generally hosted in Docker container which are ephemeral. Moreover these service need to start themselves up, talk to each other, etc. All this needs configuration and there are many commercially available configuration providers like Spring Cloud Config Server, Consul etc. These are excellent tools which provide a lot more functionality than just storing configuration data. However all these have a weakness - they have a single point of failure - their storage mechanism be it a file system, database etc. There are ways to work around those but if you want a really simple place to store configuration values and at the same time make it highly available, with guaranteed global availability and millisecond reads, what can be a better tool than Azure Cosmos DB! So I set forth on this journey for ASP.NET Core projects to talk to Cosmos DB to retrieve their configuration data. For inspiration I looked at Steeltoe Con

Proud to be a Bihari?

After nearly an year, this December I had a chance to visit Bihar. My visits normally consist of resting in my home in Patna and occasional visits to my uncle's place. But this time it was different. I had to go to Gaya to attend my cousin sister's marriage ceremony. Stepping out of Patna made me question - Am I really proud to be a Bihari? Patna is like any other city in India, struggling with pollution, traffic jams, crime, etc. Being snuggled in my bed in Patna had made me forget the reality of what Bihar really is; after all its been nearly 10 years since I had traveled to any town outside of Patna in Bihar. So, the illusion was broken the moment my uncle's brand new Maruti A-Star moved out of outskirts of Patna, to what is supposedly the "National Highway". If you haven't guessed it already, its an apology of a road.