How to Implement Strongly Typed IDs with EF Core and ASP.NET Core Razor Pages

Related videos:

Do you pass strings and ints around your application? Nah, that's a primitive obsession!
Do you exchange enums between classes? Nah, that's an anemic domain model!
Then, why would one send raw ID values between classes and to the UI? Those raw IDs look that way because the database is fine with them, not because they are good in the domain model!
This video dissects the problem of ensuring strong typing when assigning ID values through all the application layers: in Entity Framework Core mappings, in the domain model and all the calls inside it, to Razor pages and HTML generation.
You will learn how to work with autoincrement numbers, common GUIDs, and lexicographically sortable UUIDs, each separately wrapped into a strong ID type that preserves assignment safety, including model binding to and from HTML.

⌚ 00:00 Intro
⌚ 01:14 Implementing a strong ID
⌚ 06:51 Mapping to EF Core and Razor pages
⌚ 10:55 Strongly typed model binding
⌚ 12:48 Using sortable UUIDs
⌚ 14:48 Using autoincrement IDs
⌚ 15:45 Demonstrating strongly typed IDs
⌚ 16:56 Outro

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
⚡️COPYRIGHT NOTICE:
The Copyright Laws of the United States recognize a “fair use” of copyrighted content. Section 107 of the U.S. Copyright Act states: “Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phono records or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright." This video and our youtube channel, in general, may contain certain copyrighted works that were not specifically authorized to be used by the copyright holder(s), but which we believe in good faith are protected by federal law and the Fair use doctrine for one or more of the reasons noted above.

#csharp #dotnet #entityframeworkcore

[FSEAirboss]

Thanks for these. I always learn something, or at minimum refresh reasoning for specific design decisions.

[mannetjie]

this is lovely! i got lots of work to do now, things to change ❤

[tmjones]

Can't tell you how many times I've used the wrong type of ID and somehow it's never occurred to me to do this. Not a super proud moment for me

[bogdanpavlovic]

Keep going with great stuff Zoki! :) Cheers!

[utubekade]

Great video, and important techniques demonstrated. I think if an app already uses strongly typed ids, then changing the implementation details of said ids becomes trivial, without ever touching most of the related code. For instance going from int to guid, or varchar to int...etc.

[Rick]

In which situations would you use this? It does feel like additional complexity which might not be worth it in alot of simple scenario's.

[IcaroFelix]

Are you using some kind of library of functional extensions to CSharp ? If yes, could you say which is it ?

[JonathanPeel]

Something that I have been wondering lately....

Do you include Value Types (BookID, Address, FullName, etc.) as properties on DTOs, or should DTOs be "simplified" into strings or other primitives?
I can see pros and cons for ether situation.
One negative I see, having these types in the DTO might "bypass" some validations that are placed when creating/parsing these values.

[ivancavlek]

Hi, Zoran. Considering the implementation of strongly typed ids, could you comment on Vladimir Khorikov's blog post from 2020 on "C# 9 Records as DDD Value Objects" (I can't post a link, unfortunately)?
He states some valid arguments against using records as DDD Value Objects, but this may be before the time of readonly record structs.
Does that make a difference?

[metallixbrother]

I thought that this was an interesting video. That said, I feel like exposing elements of your domain model directly to the API and database code might end up being a trap further down the line.

Obviously, your approach is faster to develop than, for example, having the API DTOs, domain models and DB models isolated with the own logic and mapping between them. However, I think that such an approach has the advantage that you make the objects as “plain” as possible, and being able to rely on the tooling to handle well established types. I also believe that this approach gives us greater visibility on any such mapping, whereas the approach suggested here is powerful, I worry that it ends up obfuscating what’s going on to a less knowledgeable developer.

[facundoferrero]

So we can't have an Entity Base for this kind of model?

[allannielsen]

But isn't Id a database concern? Why not hide them in Shadow properties (if using EF) and expose real business keys as "Id"s, like ISBN? If it's in the domain, shouldn't we be speaking the domain's language? Let me play devil's advocate for a second and suggest this is stored in a No-SQL data store where Ids are not generated (or required) because everything related to the aggregate is contained within it, then do these Ids still make sense? If not, should they be in the domain in the first place?