This article mainly introduces in detail the custom paging effect based on Entity Framework, the general implementation of additions, deletions and modifications. It has certain reference value. Interested friends can refer to it
Introduction
I previously wrote a paging implementation based on Dapper, and now I will write a paging implementation based on Entity Framework, as well as a universal implementation of additions, deletions and modifications.
Code
How to run the example
Still as before:
1. Clone the code first and decompress Database.7z
2 in Database. Attach it to Sql Server LocalDB. If you are not using LocalDB of Sql Server, you need to change the connection string in App.Config.
3. Ctrl + F5, run the sample program.
Repository base class - query
Common\AbstractRepository.cs is the base class of Repository, which implements addition, deletion and modification Some methods of query, for example:
public virtual Tuple<IEnumerable<T>, int> Find(Expression<Func<T, bool>> criteria , int pageIndex , int pageSize , string[] asc , string[] desc , params Expression<Func<T, object>>[] includeProperties)
This method is one of the AbstractRepository query methods, used for custom paging query, where criteria is an expression, as the query Conditions, parameters pageIndex, pageSize, asc, desc are paging related parameters;
About multiple tables (associated tables):
includeProperties are the tables associated with Join when there are multiple tables. Because EF defaults to Lazy Loading, the associated tables are not loaded immediately by default, so sometimes if you are not careful when writing code, you may loop through n word tables in a for loop. Use the includeProperties parameter to join the related table during query.
Repository base class - addition, deletion and modification
AbstractRepository has implemented the addition, deletion and modification method using generics:
public virtual T Create(T entity)
public virtual T Update(T entity)
public virtual T CreateOrUpdate(T entity)
public virtual void Delete(TId id)
In addition, about the implementation of transaction , I used the Unit of Work mode, multiple Repositories share a DBContext, about UOW, please find it in Common\UnitOfWork.cs.
When calling UOW, it is basically similar to this:
var uow = new EFUnitOfWork(); var repo = uow.GetLogRepository(); repo.Create(new Log { LevelId = 1, Thread = "", Location = "Manual Creation", Message = "This is manually created log.", CreateTime = DateTimeOffset.Now, Date = DateTime.Now }); uow.Commit();
Get one or more Repository from UnitOfWork, share DBContext, and perform addition, deletion and modification operations. Finally uow unifies SaveChanges.
Derived classes of Repository
Since there is already AbstractRepository, many methods of adding, deleting, modifying and checking are implemented, so derived classes, such as LogRepository in the sample project It can basically become very simple, mainly implementing some specific business logic. In the example project, because there is no special business logic, it will be very simple:
public class LogRepository : AbstractRepository<Log, int> { public LogRepository(EFContext context) : base(context) { } }
About Entity generation
I prefer Database First implementation, first design the database, and then use edmx reverse engineering to generate POCO. You can refer to the relevant files in the Entity directory.
Of course, if you like Code First, there is no problem, the implementation of this article still applies.
Use Logging logs to track EF SQL
When using Entity Framework, it is best to pay attention to the SQL generated by EF, so that it can be discovered during the development stage There are some potential performance issues to avoid being overwhelmed in the production environment:)
In Common\EFContext.cs, there is a configuration item EnableTraceSql. If it is true, then the SQL generated by EF will be recorded by nlog. I configured nlog logs to the database. That is to say, when you run the sample project, every time you query, a new log record will be added, and the content is the SQL generated during the query:
Specification Pattern
In the query method, there is an overload that accepts an ISpecification example. This implementation can effectively control the business logic. For interfaces written to be called by others, you can Clearly determine the query parameters, for example:
public class LogSearchSpecification : ISpecification<Log> { public string LevelName { get; set; } public string Message { get; set; } public Expression<Func<Log, bool>> ToExpression() { return log => (log.Level.Name == LevelName || LevelName == "") && (log.Message.Contains(Message) || Message == ""); } public bool IsSatisfiedBy(Log entity) { return (entity.Level.Name == LevelName || LevelName == "") && (entity.Message.Contains(Message) || Message == ""); } }
Then, the code that calls this query method can clearly know that my query conditions are LevelName and Message. As for LevelName, it is equal to And the Message is Like is implemented in LogSearchSpeficiation, which is well encapsulated.
Finally
This set of implementations has been slowly accumulated over the past few years and has been practiced, so it should be used as a certain reference. Of course, in In specific projects, you can use some DI to get the Repository, etc. This is beyond the scope of this article. You can use it freely. I hope it can be helpful to everyone. Thank you.
The above is the detailed content of Describe in detail the implementation method of Entity Framework custom paging effect. For more information, please follow other related articles on the PHP Chinese website!