I believe that all tutorials showing how to use Blazor are using the ADO.NET Entity Framework weather that be a Blazor Web server-side or client-side solution, which would probably be using the generic repository pattern. I am not a fan of the generic repository pattern becuase it is too inflexible to change. And besides, the repository pattern is a domain pattern not a data persistence pattern. Also, EF is already using the Repository pattern, and it's not good to repeat the pattern over EF.
https://martinfowler.com/eaaCatalog/repository.html
https://www.infoworld.com/article/3117713/design-patterns-that-i-often-avoid-repository-pattern.html
https://programmingwithmosh.com/net/common-mistakes-with-the-repository-pattern/
I only bring up the Repository pattern, becuase that's what all the tutorials concerning an ASP.NET anything or the Blazor client-side teach. :)
Some developers like to use Dapper, a micro ORM, for queries and use EF for data persistence in the same solution.
You talk about the DAL, and if you go in that direction, I like to use the DAO pattern in the DAL using EF.
.https://javarevisited.blogspot.com/2013/01/data-access-object-dao-design-pattern-java-tutorial-example.html
DTO(s) travel through layers, tiers or services and not the ORM model objects.
https://www.codeproject.com/Articles/1050468/Data-Transfer-Object-Design-Pattern-in-Csharp
Now if were me, I would consider having an ASP.NET WebAPI with the DAL sitting behind it using EF for CRUD.
No, I wouldn't have a Blazor solution client-side a desktop solution, a big solution, becuase it's too heavy of a footprint on the Windows O/S desktop, and anything can go wrong that could cause problems.
I would have the Blazor client-side make the calls for CRUD with the database using an ASP.NET WebAPI. The WebAPI is static on a Web server for the most part using the DAL doing CRUD using EF is kind of static too instead of having to push EF changes out with Blazor client-side solution to every machine, IMHO.
HTH