Ich versuche, ein minimales generisches Repository-Muster in meiner Anwendung zu implementieren. Ich habe eine wirklich kleine Schnittstelle zum Abfragen und Speichern von Daten:Minimale Repository-Implementierung mit Entity Framework
public interface IRepository
{
IQueryable<TEntity> Query<TEntity>()
where TEntity: BaseEntity;
void Save<TEntity>(TEntity entity)
where TEntity : BaseEntity;
}
BaseEntity
ist eine Basisklasse für alle Objekte, die ich in meinem Repository gespeichert werden:
public abstract class BaseEntity
{
public Guid Id { get; set; }
public DateTime CreatedDate { get; set; }
public DateTime UpdatedDate { get; set; }
}
Ich habe versucht, eine funktionierende Implementierung zu finden von solch einem einfachen Repository mit Entity Framework, aber es war überraschend schwer zu finden (Leute verwenden UnitOfWork
und andere Dinge, die die Implementierung komplexer als ich will).
Also habe ich die absolut minimale Implementierung ich einfiel:
public class EfRepository : DbContext, IRepository
{
public IQueryable<TEntity> Query<TEntity>() where TEntity : BaseEntity
{
return this.Set<TEntity>();
}
public void Save<TEntity>(TEntity entity) where TEntity : BaseEntity
{
if (entity.Id == default(Guid))
{
entity.Id = Guid.NewGuid();
this.Set<TEntity>().Add(entity);
}
else
{
this.Entry(entity).State = EntityState.Modified;
}
this.SaveChanges();
}
public DbSet<User> Users { get; set; } // User is a subclass of BaseEntity
//Other DbSet's...
}
Jetzt ist meine Frage, ob eine solche Implementierung korrekt ist. Ich frage, weil ich mit Entity Framework neu bin und ich mache mir Sorgen über mögliche Leistungsprobleme oder Dinge, die möglicherweise bei der Verwendung eines solchen Repositories schief gehen könnten.
Hinweis: Ich versuche, all dies aus 2 Gründen zu tun:
- Für Testzwecke, so dass ich ein Modell des Endlagers in meinen Unit-Tests erstellen kann Projekte
- Es ist möglich, dass ich Ich werde in Zukunft zu einem anderen ORM wechseln müssen, und ich möchte diesen Übergang so einfach wie möglich machen.
Es kann sich lohnen zu überlegen, ob EF das richtige ORM ist, wenn Sie nach einer leichten Berührung Probleme mit der Leistung haben.Aus persönlicher Erfahrung habe ich nicht gefunden, dass EF in irgendeinem der Projekte, in denen ich es benutzt habe, sehr performant ist, und es ist ein wenig klobig, seine Zuordnungen in Übereinstimmung mit der DB oder dem Code zu halten (abhängig davon, welchen Pfad du wählst, Code oder DB zuerst). Jeder, den ich kenne, der in Umgebungen mit hohem Durchsatz arbeitet, krümmt sich physisch, wenn jemand EF erwähnt. –
Die Frage ist wirklich: seit EF * bereits * implementiert das Repository ('DbSet') und Unit-of-Work ('DbContext') Muster - warum neu erfinden das Rad mit noch einer anderen Schicht darüber? –
@marc_s, ich habe 2 Gründe :) Bitte, siehe meine edit –