This is the seventh day of my participation in the August More text Challenge. For details, see:August is more challenging

  • 📢 welcome to like: 👍 collect ⭐ message 📝 If there is any mistake please correct it, send roses, hand left fragrance!
  • 📢 This article was written by Webmote
  • 📢 author’s motto: life lies in tossing about, when you do not toss about life, life will start tossing you, let us work together! 💪 💪 💪

Preface 🎏

As we all know, ORM (Entity Relationship Mapping Model) can help us build applications quickly, and Microsoft Entity Framework Core (EF Core) is the preferred database access Framework for building applications when working with the.NET technology stack. Here we talk about software principles and patterns that many of you are familiar with.

🎏 1. Six principle modes:

  1. Separation of concerns – building the right architecture;
  2. Services layer – separates data operations from presentation operations;
  3. Warehousing – Select the correct database access mode;
  4. Dependency injection – transforming your database code into a service;
  5. Building business logic — using domain driven design with EF;
  6. Performance tuning – if needed, make it work faster.

Everyone has their own ideas about software principles and patterns.

The software world is changing so fast, but thankfully, some things have not changed. Some very smart people have been thinking about programming science, and they are always recommending patterns, which I think are the essence and shortcuts to mastering software development.

The idea of learning directly from the big guy is great, but the boring theory needs to be put into practice to become a Buddha. Therefore, this paper combines some software ideas with my years of learning, hoping to understand the essence of the big guy.

Note: I assume you already know entity Framework; if not, I recommend you take a look at Microsoft’s EF Core documentation, which includes a number of sample applications.

🎏 2. Separation of concerns

What is separation of Concerns (SoC)? I know all the characters, but it’s hard to understand them together.

Focus: Literally the place where you focus your attention. This can be a library, a package, a class, or even a function. Separation: Divide vertically or horizontally, either according to functional responsibilities or business semantics.

This principle requires you to: Code with similar or related functionality should be grouped together and can be understood as being placed in separate projects. This is called cohesion. To make each team/project as independent as possible, each piece of code should have a clear interface and scope of work, with other callers changing the way they work and less likely to change the code, which is also known as low coupling.

Most EF code examples on the network tend to be called directly from whatever application type it uses. This does not follow SoC and is not truly representative of how real applications should be written. The design hierarchy that truly conforms to SoC principles is as follows:The layered approach works well for small to medium sized applications, and is well suited for cloud platform development, where it is possible to launch more instance load of a Web application under high load conditions, known by design as scale-out or automatic scale-out.

The following figure shows how the SoC is applied to the database access code. All the EF database access code is highlighted as a bubble. The size of the bubble is related to the number of EF codes you find in each layer. ASP.NET Core and BizLogic projects have no EF Core query/update code at all.

🎏 3. Service layer

Microsoft.NET: Architectural Applications for the Enterprise. This book introduced me to the use of the service layer.

The principle of the service layer is boundary issues. The service layer “sets a boundary between the two interface layers,” but how does that help my application? My understanding is that the service layer acts as the adapter.

In a hierarchical architecture, there is often a data mismatch between the database/business logic and the presentation layer. There is a similar view in DDD, where the database and business logic should focus on business rules, while the presentation layer should provide a good user experience for the user or provide standard and simple API services.

Therefore, the service layer becomes a critical layer because it can be the layer that understands both sides and can transform data between the two worlds. This allows the business logic and database to be unencumbered by the presentation requirements.

Look at the picture belowEF provides a way to build queries calledselect loading, which can “pick” the relevant columns from each table and combine them into a DTO/ViewModel class that fits the user view perfectly. I applied this transformation to the service layer along with other sorting, filtering, and paging capabilities. The code is as follows:

public static IQueryable<BookListDto> 
    MapBookToDto(this IQueryable<Book> books)   
{
    return books.Select(p => new BookListDto
    {
        BookId = p.BookId,                      
        Title = p.Title,                        
        Price = p.Price,                        
        PublishedOn = p.PublishedOn,            
        ActualPrice = p.Promotion == null      
                ? p.Price : p.Promotion.NewPrice,         
        PromotionPromotionalText =              
                p.Promotion == null            
                  ? null : p.Promotion.PromotionalText,
        AuthorsOrdered = string.Join(",",      
                p.AuthorsLink                   
                .OrderBy(q => q.Order)          
                .Select(q => q.Author.Name)),   
        ReviewsCount = p.Reviews.Count,         
        ReviewsAverageVotes = p.Reviews.Select(y =>
                (double?). y.NumStars).Average() }); }Copy the code

Yes, the code is complex, we need to extract data from many different places and do some calculations simultaneously, of course you can build your own GenericServices library to reduce the complexity of the operation.

4 🎏 summary

We’re not done yet. We’ll continue tomorrow. Routine summary, rational view.

👓 all see this, still care to point a like?

👓 all points like, still care about a collection?

Do you care about a comment when you have collected 👓?