I mit arbejde med at udvikle systemer har jeg indtil videre
håndkodet repositories, altså integration til databasen via en
klasse, der skal sørge for at afskærme resten af applikationen fra
databasevalget. Dette har som sådan fungerert OK, men det er, for
en stor del, en triviel opgave og derfor kedeligt i længden. Det
ville altså være rart kun, at skulle kode samme logik én gang,
altså følge DRY-princippet.
Jeg er i forbindelse med, at jeg er dykket ned i EF 5 og Code
First, blevet introduceret for et
generisk repository, hvilket har åbnet mine øjne for
mulighederne i Generic (som efterhånden har nogle år på bagen i
.NET). Dog har jeg ikke mulighed for at benytte EF 5 i mine gamle
projekter, dels fordi disse i høj grad baserer sig på Linq to SQL,
dels fordi disse er implementeret i .NET 3.5. Derfor jeg har søgt
efter et alternativ, som kunne bruges ifm. det miljø... og når man
søger, skal man som bekendt finde (om ikke andet inspiration),
hvilket jeg gjorde i denne artikel:
"A generic implementation of the Repository Pattern for LINQ to
SQL"
Jeg vil ikke påstå jeg forstår koden fuldt ud, men jeg kan dog
godt se de smarte i, at jeg kan smide et hvilket som helst
Entity-objekt ned i halsen på repositoryklassen og få udført de
relevante handlinger på dette. Såvidt jeg kan se, skal
forretningsobjekterne implementere et interface for at dette kan
fungere. Dette er jeg som udgangspunkt ikke specielt interesseret
i, da jeg gerne vil have adskilt mine repositories helt fra
forretningsobjekterne (som man kan med EF + mapping-klasser +
fluent API til definering af dataskema).
Derfor har jeg et alternativt forslag til, hvordan man kan opnå
dette. Det kræver dog, at man implementerer lidt ekstra kode mhp.
mapning mellem database-entities og forretningsobjekter. Jeg har
valgt at implementere denne mapning af data bag et interface, som
det generiske repository kan gøre brug af (strategy pattern). Mere
om det senere i artiklen.
Først til udgangspunktet, nemlig forretningsobjekterne.
Forretningsobjekterne
Dette er i min verden logikken omkring forretningen, dvs. her
skal ikke være nogen kendskab til hvordan objektet materialiseres
eller gemmes, men kun regler og data vedr. objektet.
Et "rent" forretningsobjekt kunne f.eks. se således ud:
public class Person
{
public int Id { get; set; }
public string Navn { get; set; }
public string Email { get; set; }
}
Det kan så diskuteres om ikke Id er en databasespecifik
egenskab, men her vælger jeg så ikke at blive alt for puristisk
(til trods for det jo var et af argumenterne for, at lave den
løsning jeg her præsenterer :-)). Id er relevant andre steder i
systemet, da det er en bekvem måde at identificere objektets data
på.
Transport af data til databasen
Jeg vil gerne have mine data gemt i en database, så jeg kan
arbejde videre med dem på et senere tidspunkt, så derfor har jeg
lavet en tabel i min database, som ser nogenlunde således ud:
person =
id int
+ navn nvarchar(50)
+ email nvarchar(250)
Når dette kværnes igennem LINQ To SQL's ORM i Visual Studio,
resulterer det i et objekt, der i korte træk ser nogenlunde således
ud:
public partial class person
{
public int id { get; set; }
public string navn { get; set; }
public string email { get; set; }
}
Nu bliver udfordringen så, at få mit forretningsobjekt
transporteret frem og tilbage til hhv. fra databasen. Dertil har
jeg mit repositoryobjekt.
Repositoryklasserne
Normalt ville jeg implementere en klasse med flg. struktur:
public class PersonRepository
{
public Person Get(Person obj) { }
public IEnumerable<Person> FindAll(
FindPersonKriterier kriterier
) {}
public IEnumerable<Person> Find(
out int total,
FindPersonKriterier kriterier
) {}
public Person Create(Person obj) { }
public Person Update(Person obj) { }
public Pesron Delete(Person obj) { }
}
Det er så her jeg udvikler min dovenskab lidt, for sådan et
skulle jeg jo i så fald lave for hvert eneste
forretningsobjekt (og har gjort det indtil videre), hvilket
som sagt er noget omstændigt.
Ud over jeg skulle implementere denne klasse for hver
forretningsobjekt, skulle jeg også implementere en
FindForretningsobjektKriterier, der skulle holde på alle mine
søgekriterier for den pågældende klasse.
Generics redder dagen
Derfor vil jeg i stedet kaste mig ud i Generics og flikke en
respositoryklasse sammen, som kan bruges i (næsten) alle
sammenhænge. Den kunne se således ud:
public class GenericRepository<TEntity, TDoamin>
{
private readonly dataContext _context;
private readonly IDomainDBMapper<TEntity, TDomain> _mapper;
public GenericRepository(
dataContext db,
IDomainDBMapper<TEntity, TDomain> mapper
)
{
_context = db;
_mapper = mapper;
}
private Table<TEntity> GetTable
{
get { return _context.GetTable<TEntity>; }
}
public TDomain Get(
Expression<Func<TEntity, bool>> idFilter
)
{
var dbo = GetTable.SingleOrDefault(idFilter);
return _mapper.DbToObject(dbo, null);
}
public IEnumerable<TDomain> FindAll(
Expression<Func<TEntity, bool>> filter,
Func<IQueryable<TEntity>,
IOrderedQueryable<TEntity>> orderBy
)
{
var total = 0;
return Find(out total, filter, orderBy, 0, 1);
}
public IEnumerable<TDomain> Find(
out int total,
Expression<Func<TEntity, bool>> filter,
Func<IQueryable<TEntity>,
IOrderedQueryable<TEntity>> orderBy
int pageSize,
int page
)
{
IQueryable<TEntity> res = GetTable;
if(filter != null)
res = res.Where(filter);
if (orderBy != null)
res = orderBy(res);
total = res.Count();
if(pageSize > 0)
{
if(page > 1)
res = res.Skip((page - 1) * pageSize);
res = res.Take(pageSize);
}
return
(
from q in res
select mapper.DBToDomain(q, null)
).ToList<TDomain>();
}
public TEntity Create(TDomain obj)
{
var dbObj = CreateEntity(obj);
GetTable.InsertOnSubmit(dbObj);
return dbObj;
}
public TEntity Update(
TDomain obj,
Expression<Func<TEntity, bool>> idFilter
)
{
var dbObj = GetTable.SingleOrDefault(idFilter);
if(dbObj == null)
throw new NullReferenceException();
mapper.ObjectToDB(obj, dbObj);
return dbObj;
}
public TEntity Delete(Expression<Func<TEntity, bool>> idFilter)
{
var dbObj = GetTable.SingleOrDefault(idFilter);
if(dbObj != null)
GetTable.DeleteOnSubmit((TEntity)dbObj);
return dbObj;
}
public TEntity CreateEntity(TDomain obj)
{
var dbObj = CreateInstance<TEntity>();
mapper.ObjectToDB(obj, dbObj);
return dbObj;
}
protected T CreateInstance<T>()
{
return Activator.CreateInstance<T>();
}
}
Klassen holder en reference til datakonteksten og kender som
sådan ikke noget til processen at oprette dette objekt. Der
foretages heller ikke nogen commit (SubmitChanges) i
repositoryklassen, da dette skal ske hos den kaldende part (f.eks.
Unit of Work). Repositoryklassen ved, som udgangspunkt, ikke,
hvornår klienten er klar til at committe sig til de foretagne
ændringer. Se senere i afsnittet om Unit of Work-klassen for at se,
hvordan det kan anvendes i praksis.
Insert/Update/Delete
Disse metoder tager sig helt basalt af, at oprette, opdatere og
slette data.
For såvidt angår Update og Delete, medsendes der, af den
kaldende part, et lambda-udtryk, som specificerer hvordan
repository-klassen skal identificerer den række der skal opdateres
hhv. slettes.
Update og Delete har brug for at kunne identificere den række
der skal opdateres hhv. slettes og dette sker ved at den kaldende
part medsender et lambda-udtryk, som angiver hvordan rækken
findes.
Get
Henter en given række i databasen baseret på rækkens id-kolonne.
Id'et findes ved at den kaldende part medsender et lambda-udtryk,
der specificerer hvordan repository-klassen skal identificere
rækken der skal hentes.
FindAll/Find
Disse to metoder finder frem til data på grundlag af et filter
(som også er et lambda-udtryk). Dette filter kan som sådan være
mere eller mindre komplekst. Pointen her er, at man filtrerer
direkte i databasen, dvs. transporten af data er minimal og dermed
godt for både netværk og hukommelsesforbruget.
Find stiller yderligere muligheden for, at paginere resultatet,
til rådighed. Dette sker ligeledes direkte i databasen og fremmer
dermed ovenstående pointe yderligere. Desuden returnerer Find også
det totale antal poster fundet ved søgningen, sammen med det
paginerede resultat. Således har man mulighed for at foretage
yderligere tilpasning ifm. præsentationen af data (f.eks. lave en
"pager").
Udover filtrering og paginering, giver begge metoder mulighed
for, at sortere resultatet. Dette sker ligeledes i databasen. På
samme måde som med filteret, sendes sorteringsbetingelserne også
med som et lambda-udtryk.
CreateEntity
Metoden benyttes til at skabe et database entity-objekt, der
afspejler forretningsobjektet. Dette kan bruges i sammenhænge, hvor
man har brug for at splitte indsættelsesprocessen op i flere trin.
Se eksempel herpå i forbindelse med Ordre + Ordrelinjer sidst i
artiklen.
Støttemetoder
Ud over det faktiske interface, er der metoder til, at oprette
en instans af forretningsobjekter og databaseobjekter
(CreateInstance), samt en metode til, at hente table-klassen for
det givne databaseobjekt (GetTable). Disse er behagelighedsmetoder
og kunne som sådan godt undværes. De gør bare resten af koden
lettere at læse.
Som det kan ses, er den generiske respositoryklasse ikke i sig
selv afskærmende i forhold til omverdenen, dvs. Linq To SQL's
entiteter kendes også af den kaldende part. Min tanke er dog, at
Unit of Work-klassen skal være denne afskærmning, således Unit of
Work-klassen kun kommunikerer forretningsobjekter i sit interface,
men internt er næd til at arbejde med og kende til
databaseobjekterne. Dette er nødvendigt for at Unit of Work-klssen
kan foretage handlinger på tværs af flere forskellige repositories
i én transaktion. Læs mere om denne konstruktion senere i
artiklen.
Udfordringen herfra er nu, at få data transporteret fra det ene
format (forretningsobjektet) over i det andet (databasenobjektet)
og til dette formål skal jeg bruge en mapper-klasse
Mapperklassen som adapter
Da der er tale om et generisk repository, kendes de typer der
arbejdes med, ikke på forhånd, så repositoryklassen kan ikke selv
stå for mapning af data (med mindre man kaster sig over
Reflection). Derfor uddelegeres dette arbejde til en mapperklasse.
Denne mapperklasser implementerer et interface, som
repositoryklassen kan få lov til at kende på compile tidspunktet,
nemlig IDomainDBMapper. Dette interface definerer to metoder, en
der kopierer data fra databaseklassen til forretningsobjektet og en
der kopierer data den anden vej. Det kunne se således ud:
public interface IDomainDBMapper<TEntity, TDomain>
{
TEntity DomainToDB(TDomain, TEntity);
TDomain DBToDomain(TEntity, TDomain);
}
Den specifikke mapperklasse implementerer, som nævnt, interfacet
ovenfor og kan se således ud:
public class PersonMapper
: IDomainDBMapper<person, Person>
{
public Person DBToDomain(
person dbObj,
Person obj
)
{
if(obj == null)
obj = Activator.CreateInstance<Person>();
obj.Id = dbObj.id;
obj.Navn = dbObj.navn;
obj.Email = dbObj.email;
return obj;
}
public void DomainToDB(
Person obj,
person dbObj
)
{
dbObj.navn = obj.Navn;
dbObj.email = obj.Email;
return dbObj;
}
}
Som det ses, er dette en relativ simpel klasse, som burde være
let at teste og som ikke burde give de store problemer at
implementere.
Herfra kunne man faktisk godt gå igang med at bruge det
generiske repository, men det ville med nogen sandsynlighed blive
et sammenfiltret system med bindinger langt ned i databaselaget
helt oppe fra GUI. Dette er ikke ønskeværdigt, så derfor bør det
overvejes, om repository-klasserne skal pakkes ind. Det kan f.eks.
gøres ved at lave et lag, som håndterer alt logik der omhandler
lagring og læsning af data. Ind fra højre kommer Unit of
Work...
Unit of Work-klassen (UoW)
Denne klasse pakker repositoryklassen (eller -klasserne) ind og
er, som sådan, et transaktionslag mellem forretningsobjekterne og
databasen via en række handlinger, der sørger for at udføre
specifikke handlinger med data. Disse handlinger kunne f.eks. være
at hente en liste af et forretningsobjekt, eller gemme en samling
af objekter af samme eller forskellig type. UoW-klassen definerer
det antal repository-klasser der er behov for, for at håndtere de
opgaver der skal løses. Det kunne f.eks. se således ud:
public class PersonUnitOfWork : IDisposable
{
private readonly dataContext _context;
private readonly GenericRepository<person,Person> _repository;
public PersonUnitOfWork()
{
_context = new dataContext();
_repository =
new GenericRepository<person,Person>(
_context,
new PersonMapper()
);
}
public void Dispose()
{
_context.Dispose();
}
public List<Person> SoegPaaNavn(string navn)
{
var lowerNavn = navn.ToLower();
return _repository.FindAll(
o => o.navn.ToLower().Contains(lowerNavn),
q => q.OrderBy(ob => ob.navn)
).ToList();
}
public Person Hent(int id)
{
return _repository.Get(o => o.id == id);
}
public void Gem(Person obj)
{
person dbObj = null;
var isNew = obj.Id == 0;
if(isNew)
dbObj = _repository.Insert(obj);
else
dbObj = _repository.Update(obj, o => o.id == obj.Id);
_context.SubmitChanges();
if(isNew)
obj.Id = dbObj.id;
}
public void Slet(Person obj)
{
_repository.Delete(o => o.id == obj.Id);
_context.SubmitChanges();
obj.Id = 0;
}
}
Ovenstående UoW-klasse er helt simpel, men den viser alligevel
nogle af de elementer man skal arbejde med i forbindelse med det
generiske respository. Desuden kan man "pakke den ned" sammen med
resten af databaselaget, da interfacet til databasen hermed er
afskærmet, idet der kun arbejdes med forretningsobjekter
udadtil.
Jeg er klar over det kan være fristende, at lægge
forretningslogik i repository-laget, men UoW-klassen skal opfattes,
som en adapter mellem databasen og forretningsobjekterne. Derfor
skal UoW-objekterne kun håndtere den logik der omhandler, at
fordele data ud i de rigtige repositories, alt andet logik skal
ligge i forretningsobjektet eller et separat serviceobjekt.
Anvendelse af UoW i praksis
UoW-klassen kan bruges således:
using(var uow = new PersonUnitOfWork())
{
var personListe = uow.SoegPaaNavn("Hansen");
repeaterPersoner.DataSource = personListe;
repeaterPersoner.DataBind();
}
Her søges der efter alle personer, hvor efternavnet Hansen er en
del af deres navn. Resultatet bindes til en repeater, der
forventes, at findes på siden.
Bemærk, at UoW implementerer IDisposable for at kunne frigive
resurser ifm. Garbage Collection. Derfor vælger jeg også at benytte
mig at using-konstruktionen ifm. brugen af UoW.
Mere komplekse anvendelsesområder for UoW
Eksemplerne i denne artikel er noget simple, men Unit of Work
kommer for alvor til sin ret, når man skal håndtere større
objekthierarkier, hvor data skal gemmes som et samlet hele (dvs. en
transaktion), idet man med den illustrerede UoW-struktur, kan
opdatere flere repositories inden SubmitChanges kaldes på
DataContext-objektet. Det er værd at bide mærke i, at
dataContext-objektet styres af UoW-klassen og at det dermed er her
beslutningen om kald af SubmitChanges tages.
Eksempelvis kunne en ordre i et shopsystem, der typisk kan
indeholde flere ordrelinjer, gemmes ved først at oprette en ordre i
ordretabellen, og derefter tilføje ordrelinjer i
ordrelinjetabellen. Til sidst kan SubmitChanges kaldes for at
effektuere selve lagringen.
public class OrdreUnitOfWork : IDisposable
{
private readonly dataContext _context;
private readonly
GenericRepository<ordre,Ordre> _ordreRepository;
private readonly
GenericRepository<ordrelinje,Ordrelinje>
_ordrelinjeRepository;
public OrdreUnitOfWork()
{
_context = new dataContext();
_ordreRepository =
new GenericRepository<ordre,Ordre>(
_context,
new OrdreMapper()
);
_ordrelinjeRepository =
new GenericRepository<ordrelinje,Ordrelinje>(
_context,
new OrdrelinjeMapper()
);
}
// øvrige metoder udeladt...
public void Gem(Ordre obj)
{
if (obj.Id == 0)
{
var dbObj = _ordreRepository.Insert(obj);
foreach(var ol in obj.Ordrelinjer)
{
dbObj.ordrelinje.Add(
_ordrelinjeRepository.CreateEntity(ol));
}
_context.SubmitChanges();
if(dbObj != null)
obj.Id = dbObj.id;
}
else
{
_repository.Update(obj, o => o.id == obj.Id);
foreach(var ol in obj.Ordrelinjer)
{
if(ol.Id == 0)
dbObj.ordrelinje.Add(
_ordrelinjeRepository.CreateEntity(ol));
else
_ordrelinjeRepository.Update(ol);
}
_context.SubmitChanges();
}
}
// øvrige metoder udeladt...
}
Som det ses, håndteres ordrelinjer specielt, da disse skal
gemmes i den rigtige rækkefølge ifht. ordren (ordren skal først
oprettes og have et id tildelt, før ordrelinjerne kan relateres til
ordren). Dette klarer Linq To SQL for os, hvis blot ordrelinjerne
tilknyttes på den korrekte måde, dvs. via Add-metoden på dbOrdre's
ordrelinje-liste.
Håndteringen af ordrelinjer kunne i princippet også håndteres i
mapperklassen, hvis der er lavet en relation mellem ordren og
ordrelinjerne i databaseskemaet (hvilket der jo nok typisk er).
Jeg håber dette kan være med til, at hjælpe dig på vej til mere
overkommeligt liv med repository-pattern og forretningsobjekter.
Smid gerne en kommentar, hvis du har forslag til forbedringer eller
sprøgsmål til implementeringen.
