Heim > Artikel > Backend-Entwicklung > Tutorial zur Implementierung des benutzerdefinierten Paging-Effekts von Entity Framework
Dieser Artikel stellt hauptsächlich die allgemeine Implementierung von benutzerdefinierten Paging-Effekten, Ergänzungen, Löschungen und Änderungen basierend auf Entity Framework vor. Interessierte Freunde können darauf verweisen
Einführung
Ich habe zuvor eine Paging-Implementierung basierend auf Dapper geschrieben, und jetzt werde ich eine Paging-Implementierung basierend auf Entity Framework sowie eine universelle Implementierung von Hinzufügungen, Löschungen und Änderungen schreiben.
Code
Beginnen wir mit dem Code: https://github.com/jinweijie/EF.GenericRepository
So führen Sie das Beispiel aus
wie zuvor:
1. Klonen Sie zuerst den Code und dekomprimieren Sie Database.7z in Database
2 SQL Server LocalDB. Wenn Sie LocalDB von SQL Server nicht verwenden, müssen Sie die Verbindungszeichenfolge in App.Config ändern.
3. Strg + F5, führen Sie das Beispielprogramm aus.
Repository-Basisklasse – Abfrage
CommonAbstractRepository.cs ist die Basisklasse von Repository, die das Hinzufügen und Löschen implementiert , Änderung und Abfrage. Einige Methoden, wie zum Beispiel:
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)
Diese Methode ist eine der AbstractRepository-Abfragemethoden und wird zum Anpassen von Paging-Abfragen verwendet, wobei Kriterien ein sind Ausdruck als Abfragebedingungen, Parameter pageIndex, pageSize, asc, desc sind pagingbezogene Parameter;
In Bezug auf mehrere Tabellen (zugeordnete Tabellen):
includeProperties ist die mit Join verknüpfte Tabelle, wenn mehrere vorhanden sind Tische. Da EF standardmäßig Lazy Loading verwendet, werden die zugehörigen Tabellen standardmäßig nicht sofort geladen. Wenn Sie also beim Schreiben von Code nicht vorsichtig sind, kann es vorkommen, dass Sie in einer for-Schleife n-Wort-Tabellen durchlaufen. Verwenden Sie den Parameter „includeProperties“, um die zugehörige Tabelle während der Abfrage zu verknüpfen.
Repository-Basisklasse – Hinzufügen, Löschen und Ändern
AbstractRepository hat die Methoden zum Hinzufügen, Löschen und Ändern mithilfe von Generika implementiert:
public virtuelles T erstellen(T-Entität)
öffentliches virtuelles T-Update(T-Entität)
öffentliches virtuelles T erstellenOrUpdate(T-Entität)
öffentliches virtuelles Leere löschen(TId-ID)
In Darüber hinaus habe ich zur Implementierung der Transaktion den Unit of Work-Modus verwendet. Mehrere Repositorys teilen sich einen DBContext. Informationen zu UOW finden Sie in CommonUnitOfWork.cs.
Beim Aufruf von UOW ist es im Grunde ähnlich wie folgt:
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();
Rufen Sie ein oder mehrere Repositorys von UnitOfWork ab, geben Sie DBContext frei und fügen Sie es hinzu und löschen Sie es , und Änderungsvorgang, und schließlich vereinheitlicht uow SaveChanges.
Abgeleitete Klassen von Repository
Da es bereits AbstractRepository gibt, sind viele Methoden zum Hinzufügen, Löschen, Ändern und Überprüfen implementiert, sodass abgeleitete Klassen, wie z LogRepository im Beispielprojekt Es kann grundsätzlich sehr einfach werden, hauptsächlich durch die Implementierung einer bestimmten Geschäftslogik. Da es im Beispielprojekt keine spezielle Geschäftslogik gibt, wird es sehr einfach sein:
public class LogRepository : AbstractRepository<Log, int> { public LogRepository(EFContext context) : base(context) { } }
Über die Entitätsgenerierung
Ich bevorzuge die Datenbank-First-Implementierung. Ich entwerfe zuerst die Datenbank und verwende dann edmx Reverse Engineering, um POCO zu generieren. Sie können auf die relevanten Dateien im Entity-Verzeichnis verweisen.
Wenn Ihnen Code First gefällt, ist das natürlich kein Problem und die Umsetzung dieses Artikels gilt weiterhin.
Verwenden Sie die Protokollierung, um EF SQL zu verfolgen
Bei der Verwendung von Entity Framework ist es am besten, auf das von EF generierte SQL zu achten, damit dies möglich ist Während der Entwicklungsphase entdeckt Einige potenzielle Leistungsprobleme können eine Überlastung in der Produktionsumgebung vermeiden:)
In CommonEFContext.cs gibt es ein Konfigurationselement EnableTraceSql. Wenn es wahr ist, wird die von EF generierte SQL aufgezeichnet von nlog. Ich habe NLOG-Protokolle für die Datenbank konfiguriert. Das heißt, wenn Sie das Beispielprojekt ausführen, wird bei jeder Abfrage ein neuer Protokolldatensatz hinzugefügt, und der Inhalt ist die während der Abfrage generierte SQL:
Spezifikationsmuster
In der Abfragemethode gibt es eine Überladung, die ein ISpecification-Beispiel akzeptiert. Diese Implementierung kann die Geschäftslogik effektiv steuern, damit sie von anderen aufgerufen werden kann. Sie können die Abfrageparameter eindeutig bestimmen, zum Beispiel:
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 == ""); } }
Dann kann der Code, der diese Abfragemethode aufruft, eindeutig erkennen, dass meine Abfragebedingungen LevelName und Message sind. LevelName Is equal to und Message is Like werden in LogSearchSpeficiation implementiert, wodurch eine gute Kapselung erreicht wird.
Das obige ist der detaillierte Inhalt vonTutorial zur Implementierung des benutzerdefinierten Paging-Effekts von Entity Framework. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!