How to implement layered architecture?

fatih uyanık 80

Hello

I started working on layered architecture to write some more professional code in C#. As a result of research on the internet, I saw that each person implements layered architecture differently. This caused confusion.

I use the MVVM pattern in my projects. For this, I created DAL, BL and PL layers respectively. If I'm not mistaken, PL should use the BL layer, and the BL layer should use the DAL layer, respectively.

Now I created database configurations and entities against tables with EF in the DAL layer. In the BL layer, I created jobs that would add, update and delete data using the structure in the DAL layer. I also use dependency injection. Accordingly, when I add the DAL layer to the dependency container on the PL side, it uses the DAL layer directly. Exactly what kind of structure should I set up? Can you share information about this?

Thanks.

1 answer

Hui Liu-MSFT 38,256 Reputation points Microsoft Vendor

2024-04-11T06:32:47.64+00:00

Hi,@ fatih uyanık. Welcome to Microsoft Q&A.

It sounds like you're on the right track with your layered architecture using the MVVM pattern.

Presentation Layer (PL):

This layer contains your WPF views (XAML files) and their corresponding view models (C# classes).

Views are responsible for displaying UI elements and interacting with the user.

View models handle the logic and data binding between the views and the business logic layer (BL).

Views should not contain any business logic; they should delegate that responsibility to the view models.

Business Logic Layer (BL):

This layer contains the business logic of your application, including validation, calculations, and data manipulation.

It should be independent of any specific UI technology (e.g., WPF) and should focus solely on implementing business rules.

The BL layer interacts with the data access layer (DAL) to retrieve and persist data.

Data Access Layer (DAL):

This layer is responsible for interacting with the database or any other data source.

It contains classes that encapsulate database operations, such as querying, inserting, updating, and deleting data.

The DAL layer abstracts the details of database access, allowing the BL layer to work with data in a more abstract and business-focused way.

Dependency Injection (DI):

Use DI to inject dependencies (e.g., services, repositories) into your view models and other components.

Configure DI container at the composition root of your application (e.g., App.xaml.cs) to register dependencies and resolve them as needed.

Inject dependencies into your view models using constructor injection, property injection, or method injection.

Regarding the structure and setup of your project:

DAL: Contains database configurations, entities (EF models), and data access classes (repositories, data services).

BL: Contains business logic classes and interfaces. It should depend on the DAL but should not depend on the PL.

PL: Contains views, view models, and any UI-related components. It depends on the BL but should not depend on the DAL directly.

To ensure loose coupling and maintainability:

Define interfaces in the BL layer for services and repositories.

Implement these interfaces in the DAL layer.

Use dependency injection to inject concrete implementations of these interfaces into your view models.

The following are documents you can refer to.

Implementing the MVVM Pattern (focus on structure)

Create a simple data application with WPF and Entity Framework 6

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Please sign in to rate this answer.
fatih uyanık 80 Reputation points

2024-04-11T11:23:35.73+00:00

Hello @Hui Liu-MSFT

I plan to use the ones in the BL layer by registering them as services. But when saving data on the PL side, I need to create an instance of the Person object. At this point, I have to add the DAL layer as a reference to the PL layer. Can you give information at this point?

Thanks.

fatih uyanık 80 Reputation points

2024-04-11T11:26:24.7633333+00:00

Hello @Hui Liu-MSFT

I plan to use the ones in the BL layer by registering them as services. But when saving data on the PL side, I need to create an instance of the Person object. At this point, I have to add the DAL layer as a reference to the PL layer. Can you give information at this point?

Thanks.

Hui Liu-MSFT 38,256 Reputation points Microsoft Vendor

2024-04-12T07:38:00.4166667+00:00

Hi,@fatih uyanık. Regarding referencing the DAL layer from the PL layer, you could refer to the description below.

1.Dependency Inversion Principle (DIP) principle suggests that high-level modules (PL) should not depend on low-level modules (DAL) directly. Instead, both should depend on abstractions (interfaces or abstract classes). This allows for flexibility and easier testing.

2.As you mentioned, you plan to use DI to inject dependencies into your components. This is the right approach. By registering services in your DI container (usually at the composition root), you can inject interfaces from the BL layer into your PL layer without directly referencing the DAL.

Here's how you can achieve this:

Define interfaces for your BL services and repositories in the BL layer.

Implement these interfaces in the DAL layer.

Register these implementations as services in your DI container in the PL layer's composition root.

You can try to refer to the following examples.

DAL layer

namespace DataAccessLayer { public class Person { public int Id { get; set; } public string Name { get; set; } } public interface IPersonRepository { void AddPerson(Person person); } }

BL layer

using DataAccessLayer; namespace BusinessLogicLayer { public class PersonService : IPersonRepository { public void AddPerson(Person person) { // Implement the logic to add a person (e.g., save to database) // For demonstration, we'll just print the person's name Console.WriteLine($"Adding person: {person.Name}"); } } }

PL layer

using BusinessLogicLayer; using DataAccessLayer; using System.ComponentModel; using System.Windows.Input; namespace PresentationLayer { public class MainViewModel : INotifyPropertyChanged { private readonly IPersonRepository _personRepository; public MainViewModel(IPersonRepository personRepository) { _personRepository = personRepository; AddPersonCommand = new RelayCommand(AddPerson); } public event PropertyChangedEventHandler PropertyChanged; public ICommand AddPersonCommand { get; } private string _personName; public string PersonName { get { return _personName; } set { if (_personName != value) { _personName = value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(PersonName))); } } } private void AddPerson() { // Create a Person object and add it using the repository var person = new Person { Name = PersonName }; _personRepository.AddPerson(person); } } }

Register services in the PL layer's composition root (e.g., App.xaml.cs).

PL layer

using BusinessLogicLayer; using Microsoft.Extensions.DependencyInjection; using System.Windows; namespace PresentationLayer { public partial class App : Application { protected override void OnStartup(StartupEventArgs e) { base.OnStartup(e); // Setup DI container var services = new ServiceCollection(); ConfigureServices(services); var serviceProvider = services.BuildServiceProvider(); // Resolve the main view model and show the main window var mainWindow = new MainWindow(); var viewModel = serviceProvider.GetRequiredService<MainViewModel>(); mainWindow.DataContext = viewModel; mainWindow.Show(); } private void ConfigureServices(IServiceCollection services) { // Register services services.AddSingleton<IPersonRepository, PersonService>(); // Register view models services.AddSingleton<MainViewModel>(); } } }

View: PL layer

<StackPanel Margin="10"> <TextBlock Text="Enter Person Name:"/> <TextBox Text="{Binding PersonName, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" Margin="0 5"/> <Button Content="Add Person" Command="{Binding AddPersonCommand}" Margin="0 10"/> </StackPanel>

fatih uyanık 80 Reputation points

2024-04-15T10:04:39.9133333+00:00

Hello @Hui Liu-MSFT

First of all, I apologize for replying late. Then, as I understand it, I will define the interfaces for models and repositories in the DAL layer and then implement this interface on the class that will do the job in the BL layer. Finally, I will use the class that does the work in the BL layer in the PL layer via the service. By the way, will it not cause any contradiction to sample the model in the DAL layer to create an instance of the model for recording?

Hui Liu-MSFT 38,256 Reputation points Microsoft Vendor

2024-04-16T06:04:08.1766667+00:00

Hi,@fatih uyanık. No, it won't cause a contradiction to sample the model in the DAL layer to create an instance of the model for recording. In fact, it's a common practice to define your data models (entities) in the DAL layer and then use them throughout your application.

fatih uyanık 80 Reputation points

2024-04-16T10:23:36.7833333+00:00

Hello @Hui Liu-MSFT

With your permission, I would like to ask one last thing.

There is more than one way to define data context. I usually set it in the OnConfiguring context method of the data class. After this adjustment, I add it as services.AddDbContext. I wonder what should be the common usage and the most correct usage?

Thanks.

Hui Liu-MSFT 38,256 Reputation points Microsoft Vendor

2024-04-17T02:27:03.1833333+00:00

Hi,@fatih uyanık.

Both setting the data context in the OnConfiguring method and registering it with services.AddDbContext are valid approaches in Entity Framework Core applications.

Setting Data Context in OnConfiguring Method is suitable for small applications or when there's a single data context used throughout the application.

Adding Data Context using services.AddDbContext allows for configuring multiple data contexts, which can be beneficial in larger applications.

For simple applications with a single database context and straightforward configuration, setting the data context in OnConfiguring may be sufficient and convenient.

For larger applications or applications that need to support multiple database contexts or environments, registering the context with services.AddDbContext is often preferred for better maintainability and flexibility.

fatih uyanık 80 Reputation points

2024-04-17T09:21:18.6933333+00:00

Hello @Hui Liu-MSFT

Then, after setting the connection clause in OnConfiguring, I will use it in a small-scale project by adding the data context as a service? Is it true? Or I will create and save a data access class that performs add, delete and update functions. More precisely, then it will be necessary to save the data context again to use it everywhere in the application? So I can take the data context via constructor method and inject it into the class in data access operations?

You helped me a lot. Thank you very much.

Hui Liu-MSFT 38,256 Reputation points Microsoft Vendor

2024-04-18T07:42:05.57+00:00

Hi,@fatih uyanık. In a WPF application, the approach you take for managing the DbContext depends on the architecture and requirements of your project.

You could refer to this documentation to better understand your issues related to OnConfiguring.
Sign in to comment