Example
One interesting way that Entity Framework uses shadow properties is in a one-to-many relationship.
Let’s take a look at an example. (images shown below)

We have two entity classes, a Student entity and a Course entity.
In our case, one student can attend only one course but a course can have more than one student.
The entity class representation will be shown in the images below.
If we create the migrations, update the database and check the Students table, we can see a column named “CourseId”.
Entity Framework creates that column and uses it as a shadow property. That column isn’t exposed in the Student class.

If we now add students to a course, the CourseId of those students will be updated accordingly.
This way Entity Framework knows which student is part of which course without exposing the CourseId property in the Student class.

Can we add custom shadow properties?
We can do that by using the FluentAPI and overriding the OnModelCreating method like this:

modelBuilder.Entity<Student>().Property<string>(“ShadowProperty”);

We add a new migration, update the database and we can see that a new column, “ShadowProperty” has been added to the Students table but it isn’t present on the Student model.

Can we access the value of the shadow property?
Yes, we can. Shadow property values can be obtained and changed through the ChangeTracker API like this:

Student student = dbContext.Students.First();
dbContext.Entry(student).Property(“ShadowProperty”).CurrentValue = “It’s a shadow property!”;

They can also be referenced in LINQ queries via the EF.Property static method:

ICollection<Student> students = dbContext.Students.Where(student => EF.Property<string>(student, “ShadowProperty”) != null).ToArray();

TLDR; Shadow properties are useful when there’s data in the database that shouldn’t be exposed on the mapped entity types. We can add custom shadow properties by using the FluentAPI and overriding the OnModelCreating method.
The value of the property can be obtained and changed through the ChangeTracker API, and shadow properties can be referenced in LINQ queries via the EF.Property static method.

Was this helpful?
If you still need expert help, leave us a message here and tell us what’s bothering you.

The post What are Shadow Properties in Entity Framework appeared first on Pontis Technology.

In this blog post, we’ll have a quick overview of Tasks and ValueTasks in C#. Prepare to optimize your code and unlock the full potential of asynchronous programming!

What is a task?
In short, a Task is a class that is used for asynchronous programming to execute a single operation. If the operation needs to return a result, the class Task<TResult> is used.

What is a ValueTask?
A ValueTask is a struct wrapper for the Task class. It basically has two fields, a field to store the Task/Task<TResult> and a field to store the TResult.

The difference
Since Task is a class, when it’s instantiated, it is stored on the heap. That means that, eventually, the garbage collector will be called to free the memory of the instantiated Task class after use.

ValueTask is a struct and, therefore, is stored on the stack. The benefit of this is that, as soon as the ValueTask is used, it is removed from the stack and that memory is freed.

When should ValueTask be used instead of Task?
ValueTask should be used only when you expect an asynchronous method to run synchronously most of the time.

In the image provided as part of this post, you can see the code and the benchmark results for the same operation performed by the Task and ValueTask. We can see that, in this case, less memory is used by using ValueTask.

There are a few guidelines to follow when using ValueTask:

• ValueTask is a one-and-done deal. Don’t await the same ValueTask more than once as it may result in undefined behavior.
• ValueTask cannot be used with WhenAny(), WhenAll() methods. For that to work, we have to convert the ValueTask into a Task using AsTask().
• The same instance should not be awaited concurrently.

Tldr; ValueTask is good when used for asynchronous methods that will run synchronously most of the time since it can save memory. But it shouldn’t be awaited multiple times, it cannot be used with WhenAll(), WhenAny() methods and the same instance should not be awaited concurrently.

Hopefully this has been helpful to you.
However, if you still need expert help, leave us a message here and tell us what’s bothering you.

The post A quick guide through Tasks and ValueTasks in C# appeared first on Pontis Technology.