Project structure with C# and EfCore
-
Hi, I'm currently learning how to use Entity Framework Core and I'm trying to create a "more advanced" application divided into multiple projects. When I was using ADO.NET, I would usually make: - Project.DatabaseAccess - for managing connection strings, - Project.Shared - base classes and interfaces (which implement INotifyPropertyChanged) - for example Project.Customers - models for customer-related stuff and a static class with CRUD methods for them. Customers would then reference the Shared and DatabaseAccess projects. When using EfCore, I wanted to achieve similar structure, so: - Project.DatabaseAccess - managing connection strings, main DbContext - Project.Shared, - Project.Customers - models for customer-related stuff and repositories for them (with DbContext provided in the constructor) The problem with that approach is that Customers reference to the DatabaseAccess (for accessing DbContext), and DatabaseAccess needs to reference to the Customers (because it has DbSet). Unfortunately, you can't make A<-->B references in the Visual Studio. What other project structures do you recommend? I know that there is something called CleanArchitecture (Application, Domain, Infrastructure), but it doesn't provide the separation between different spheres of my program (Project.Customers, Project.Planning, Project.Mailing, etc.) Thank you in advance!
-
Hi, I'm currently learning how to use Entity Framework Core and I'm trying to create a "more advanced" application divided into multiple projects. When I was using ADO.NET, I would usually make: - Project.DatabaseAccess - for managing connection strings, - Project.Shared - base classes and interfaces (which implement INotifyPropertyChanged) - for example Project.Customers - models for customer-related stuff and a static class with CRUD methods for them. Customers would then reference the Shared and DatabaseAccess projects. When using EfCore, I wanted to achieve similar structure, so: - Project.DatabaseAccess - managing connection strings, main DbContext - Project.Shared, - Project.Customers - models for customer-related stuff and repositories for them (with DbContext provided in the constructor) The problem with that approach is that Customers reference to the DatabaseAccess (for accessing DbContext), and DatabaseAccess needs to reference to the Customers (because it has DbSet). Unfortunately, you can't make A<-->B references in the Visual Studio. What other project structures do you recommend? I know that there is something called CleanArchitecture (Application, Domain, Infrastructure), but it doesn't provide the separation between different spheres of my program (Project.Customers, Project.Planning, Project.Mailing, etc.) Thank you in advance!
nwbkn wrote:
you can't make A<-->B references in the Visual Studio
You can use interfaces for circular references.
nwbkn wrote:
Customers reference to the DatabaseAccess
Your Data API layer accepts DTOs (Data Transfer Object) and returns DTOs. So 'Customer' is a DTO which the CustomerDB class uses. Although you can choose your own names for the classes. Create Data Transfer Objects (DTOs) | Microsoft Learn[^] Be very careful about what you put in a DTO. Probably to start out you should have nothing but properties.
-
nwbkn wrote:
you can't make A<-->B references in the Visual Studio
You can use interfaces for circular references.
nwbkn wrote:
Customers reference to the DatabaseAccess
Your Data API layer accepts DTOs (Data Transfer Object) and returns DTOs. So 'Customer' is a DTO which the CustomerDB class uses. Although you can choose your own names for the classes. Create Data Transfer Objects (DTOs) | Microsoft Learn[^] Be very careful about what you put in a DTO. Probably to start out you should have nothing but properties.
-
nwbkn wrote:
you can't make A<-->B references in the Visual Studio
You can use interfaces for circular references.
nwbkn wrote:
Customers reference to the DatabaseAccess
Your Data API layer accepts DTOs (Data Transfer Object) and returns DTOs. So 'Customer' is a DTO which the CustomerDB class uses. Although you can choose your own names for the classes. Create Data Transfer Objects (DTOs) | Microsoft Learn[^] Be very careful about what you put in a DTO. Probably to start out you should have nothing but properties.
jschell wrote:
You can use interfaces for circular references.
I learn something new every time I visit this website!
The difficult we do right away... ...the impossible takes slightly longer.
-
jschell wrote:
You can use interfaces for circular references.
I learn something new every time I visit this website!
The difficult we do right away... ...the impossible takes slightly longer.
difficulties gives us new challenges and something new to learn.
