This is the 8th 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 originally written by Webmote and originally published by CSDN.
  • 📢 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. If you are interested in the first three principles, please refer to the first article.

🎏 1. Warehousing

We can access the database in a number of different ways and hide the EF access layer from other applications. In the figure below, I show four different data access patterns.The four types of database access modes are:

  • Repository + Unit of Work (Repo + UOW) : This hides all the EF Core behind the code that provides the different interfaces to the EF. You can replace EF with another database access framework without changing the method that calls Repo + UOW.
  • EF repository: This is a repository pattern that does not attempt to hide the EF code as the Repo + UOW pattern does. The EF repository assumes that you, as a developer, know the rules of EF, such as using traced entities and calling SaveChanges for updates, so you will follow them.
  • Query objects: Query objects encapsulate the code for database queries (that is, database reads). They hold the entire code for the query, or complex queries that contain parts of the query. Query objects are typically built using IQueryable inputs and outputs as extension methods, so that they can be linked together to build more complex queries.
  • Call EF directly. This means that you’re just putting the required EF code in the method that needs it.

The Repo + UOW mode, although recommended by many, is too heavy to be recommended. Calling EF directly does not separate concerns and is generally not recommended.

Therefore, having excluded both extremes, I propose:

  • Query objects, typically breaking large queries into a series of query objects
  • For “Create, Update, and Delete,” I use DDD-style access methods, that is, I create a method in the entity class to update a property or relationship. This isolates the EF code and makes refactoring or performance tuning easier.
public class ChangePubDateService : IChangePubDateService
{
    private readonly EfCoreContext _context;
 
    public ChangePubDateService(EfCoreContext context)
    {
        _context = context;
    }
 
    public ChangePubDateDto GetOriginal(int id)    
    {
        return _context.Books
            .Select(p => new ChangePubDateDto      
            {                                      
                BookId = p.BookId,                 
                Title = p.Title,                   
                PublishedOn = p.PublishedOn        
            })                                     
            .Single(k => k.BookId == id);          
    }
 
    public Book UpdateBook(ChangePubDateDto dto)   
    {
        var book = _context.Books.Find(dto.BookId);
        book.PublishedOn = dto.PublishedOn;        
        _context.SaveChanges();                    
        returnbook; }}Copy the code

🎏2. Dependency injection

NetCore fully supports dependency injection (DI), so you should get with The Times.

  • Place each database access code in the repository.
  • Add an interface for each EF repository class.
  • Register the EF repository class against its interface in the DI provider.
  • You then need to inject it into the front-end methods that need it.
[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult ChangePubDate(ChangePubDateDto dto, [FromServices]IChangePubDateService service)
   {
      service.UpdateBook(dto);
      return View("BookUpdated"."Successfully changed publication date");
}
Copy the code

🎏3. Set up the service logic

Practical applications are built to provide a service, ranging from saving files on a computer to managing a nuclear reactor.

Every different problem in the real world has a set of rules, often called business rules or, more generically, domain rules.

Too many people talk about DDD, you can look up a lot of practical articles, but here’s just one:

The business problem you are trying to solve must drive the entire development.

There is a lot of debate about whether EF Core is appropriate for DDD methods, because the business logic code is usually separate from the EF entity classes mapped to the database. One of our principles in development was: “Don’t fight your framework, look for ways to maintain domain-driven design, and give up details when the framework is hostile.”

  • Focus on business logic, define the database structure, and resolve the discrepancy between domain model and EF model.
  • Business logic should not be distracted. Writing business logic itself is difficult and isolated from all other application layers except entity classes. When writing business logic, you only need to think about the business problem to be solved.
  • The business logic should assume that it is processing in-memory data
  • Isolate the database access code into a separate project
  • The business logic should not call the EF Core’s SaveChanges directly

🎏4. Make your EF code work, and then optimize it as needed.

The principle of development is to make it work!

Either way, these principles suggest that we should leave performance tuning to the last minute and only tune performance when needed.

Fast developing complex database access in EF – at least five times faster than using ADO.NET or Dapper. The downside is that EF doesn’t always produce the best performing SQL commands: sometimes it’s because EF doesn’t provide good SQL transformations, and sometimes it’s because THE LINQ code I write isn’t as efficient as I’d like.

The question is: Does it matter?

Optimization comes at a cost, of course, and the following shows how improvements can be made in a series of phases, each of which becomes more complex and takes more development time:

  • Improve the basic EF commands by rearranging or refining the EF code?
  • Convert some or all of the EF code to direct SQL commands, computed columns, stored procedures, etc.?
  • Can you change the database structure (for example, de-canonicalize the database) to improve search performance?

Plan for possible performance adjustments

While I fully agree with the idea of tuning too early, it’s wise to plan ahead for your possible performance tuning.

🎏 5. Conclusion

Every technology gets harder and harder, because learning any new technology takes some time to smooth it out.

There have been many great software thinkers, and some great principles and practices. So the next time we want to do something better, let’s look at what other people think.

Oh oh, have fun coding!

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 👓?