Blazor wasm, net core hosted, with authentication, relationships between applicationuser and my models in the shared project

user_3621272 0
Viewed 523

I'm studying Net Core and Blazor and I'm facing the following problem.

I created a new Blazor web assembly solution, net core hosted with user authentication. The solution is split in three projects by default: client, server and shared. I put my models in the shared project but now I need to set relationships (one-to-many, many-to-many, ... as described here: https://docs.microsoft.com/en-us/ef/core/modeling/relationships ) between my models and the ApplicationUser model which lives inside the server project.

Inside my model I can't put

public ApplicationUser User { get; set; }

because I cannot do this

using mysolutionname.server;

because the server project depends on shared and shared cannot depend on server (circular dependency).

How do I solve this?

blazor-client-side blazor c#
2 Answers

The Shared project should contain only objects that are shared by the Client and the Server projects. As for instance, the WeatherForecast class, used by the Client and Server projects in the default Visual Studio Template, resides in the Shared project, as both projects make use of this class. But objects such as the ApplicationUser (or ApplicationDbContext) are only used on the server, must not and cannot be used on the Client project, and their current location as produced by the default template should not be changed in the way you thought.

Hope this helps...

user_61528910

If you get issues with circular dependency it mostly means there is something off in your application architecture.

In your case it's not a good practice to have data objects defined at different locations, in all popular software patterns the data model is seperated from other components.

If the ApplicationUser basically is a database object, it needs to live in your database layer and the application uses this database layer.

Keeping those layers seperately has many benefits. Just to name some examples:

  • You can maintain your projects seperately without them depending on each other.
  • No circular dependencies
  • You can share the model without sharing other parts
  • If there is some change to the database layer you have one central place where to change it.

If you need a child applicationuser from another library, you should reference the library in your database layer.

user_30859850
Related