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.

Jeg har længe søgt efter en relativ generisk måde hvorpå jeg kan strukturere mit repositoryinterface og jeg er efterhånden kommet frem til et repository interface, som dækker de fleste af mine behov for CRUD og listeudlæsninger.

void Load(FO, id); 
void Save(FO); 
void Delete(id); 
IEnumerable<FO> GetList(count, page, out total, criteria);

Load modtager et instantieret forretningsobjekt (her betegnet FO, men skal have den konkrete type eller et interface) og fylder objektet med data fra repository med det angivne id. Hvis data ikke findes rejses en kørselsfejl, for at undgå at objektet skal implementere en sporing af, om data er indlæst eller ej. Alternativt kan Load returnere en boolsk falsk.

Save tager data i FO og oprette eller opdatere data i repository. Id i FO opdateres til at modsvare data i repository, hvis der er tale om en oprettelse i repository.

Delete sletter data for FO i repository og nulstiller FO's id, således dette kan gemmes igen og dermed foranledige en oprettelse, hvis dette skulle findes nødvendigt.

GetList modtager nogle parametre som hjælper med paginering af udtrækket. Count er det antal elementer der skal udtrækkes og page er den side i det total udtræk (jf. de øvrige parametre i criteria-objektet), hvorfra elementerne skal udtrækkes. Total er det antal elementer der total set er i udtrækket. Criteria indeholder et (variabelt) antal parametre, som er relevante for det aktuelle FO's kontekst. Dette kunne f.eks. være søgetekst eller hvorvidt de udtrukne FO skal have en bestemt status. Det er helt op til kravene til FO og systemet.

I praksis

Et eksempel på hvordan dette kan tage sig ud i praksis kunne se ud som vist i det følgende.

Præmisserne her er, at data gemmes i en SQL Server og ORM er LinqToSql. Der tages udgangspunkt i et personregister, hvor hver person har registreret nogle oplysninger omkring sig, der giver lidt muligheder for at udforske metoden omkring søgning og paginering. Forretningsobjektet spejler i dette eksempel tabellen person databasen, så definitionen af databasen er undladt her.

Først defineres FO:

public class Person
{
   public int Id { get; set; }
   public string Navn { get; set; }
   public string Adresse { get; set; }
   public string Postnr { get; set; }
   public string Bynavn { get; set; }
   public string Email { get; set; }
   public string Telefonnr { get; set; }
}

Kriterieobjektet kunne se således ud:

public class PersonSearchCriteria
{
   public string searchText { get; set; }
}

Dernæst defineres repositoryobjektet:

public class PersonRepository
{
   public void Load(Person person, int id)
   {
      using(var db = new personDataContext())
      {
         var dbPerson = db.person.SingleOrDefault(p => p.Id == id);
         if(dbPerson != null)
            throw new Exception("Person ikke fundet");

         person.Id = dbPerson.Id;
         person.Navn = dbPerson.Navn;
         person.Adresse = dbPerson.Adresse;
         person.Postnr = dbPerson.Postnr;
         person.Bynavn = dbPerson.Bynavn;
         person.Email = dbPerson.Email;
         person.Telefonnr = dbPerson.Telefonnr;
      }
   }

   public void Save(Person person)
   {
      using(var db = new personDataContext())
      {
         var dbPerson = 
                 db.person.SingleeOrDefault(p => p.Id == person.Id);
         if(dbPerson == null)
         {
            dbPerson = new person();
            db.person.InsertOnSubmit(dbPerson);
         }
         dbPerson.Navn = person.Navn;
         dbPerson.Adresse = person.Adresse;
         dbPerson.Postnr = person.Postnr;
         dbPerson.Bynavn = person.Bynavn;
         dbPerson.Email = person.Email;
         dbPerson.Telefonnr = person.Telefonnr;

         db.SubmitChanges();

         person.Id = dbPerson.Id;
      }
   }

   public void Delete(int it)
   {
      using(var db = new personDataContext())
      {
         var dbPerson = db.person.SingleOrDefault(p => p.Id == id);
         if(dbPerson != null)
         {
            db.person.DeleteOnSubmit(dbPerson);
            db.SubmitChanges();
         }
      }
   }

   public IEnumerable<Person> GetList(
         int count, 
         int page, 
         out int total, 
         PersonSearchCriteria criteria
      )
   {
      using(var db = new personDataContext())
      {
         var list = db.person.AsQueryable();

         if(!String.IsNullOrWhiteSpace(criteria.searchText))
         {
            var txt = criteria.searchText;
            list = db.person.Where(p => 
                     p.Navn.Contains(txt)
                     || p.Adresse.Contains(txt)
                     || p.Postnr.Contains(txt)
                     || p.Bynavn.contains(txt)
                     || p.Email.Contains(txt)
                     || p.Telefonnr.Contains(txt));
         }

         total = list.Count();

         if(count > 0)
         {
            if(page > 1)
               list = list.Skip((page - 1) * count);

            list = list.Take(count);
         }

         return 
            from p in list
            select new Person {
               Id = dbPerson.Id,
               Navn = dbPerson.Navn,
               Adresse = dbPerson.Adresse,
               Postnr = dbPerson.Postnr,
               Bynavn = dbPerson.Bynavn,
               Email = dbPerson.Email,
               Telefonnr = dbPerson.Telefonnr
            };
      }
   }
}

Med dette kan man udtrække en liste af alle personer i databasen eller en liste af personer som møder visse kriterier, her et ord som indgår i navn, adresse, postnr, by, email eller telefonnr. Kriterierne kan udvides efter behov og selve kaldet til databasen bliver aldrig mere komplekst end der er behov for, fordi kriterierne undlades, hvis der ikke er specificeret nogen søgetekst. På samme måde undlades paginering, hvis count, dvs. det ønskede antal personer, er mindre end 1 (reglen er implicit eller pr. konvention om man vil).

Brugen af repository kunne se således ud og ligge som en static metode på Personobjektet eller i en factoryklasse til Person.

Factoryklassen kunne se såleds ud:

public class PersonFactory
{
   private readonly PersonRepository _repository;

   public PersonFactory(PersonRepository repository)
   {
      _repository = repository;
   }

   public IEnumerable<Person> GetAll(
         int count, 
         int page, 
         out int total
      )
   {
      return _repository.GetList(count, page, total, null);
   }

   public IEnumerable<Person> Search(
         int count, 
         int page, 
         out int total, 
         string searchText
      )
   {
      var criteria = new PersonSearchCriteria { 
            searchText = searchText 
         };
      return _repository.GetList(count, page, total, criteria);
   }
}

Som det kan ses, implementerer factoryklassen et mere specialiseret interface der ligger tættere på forretningskravene og som er mere ligetil at benytte. Dette sker uden at repository-interfacet bliver forplumret af flere metoder.

Hvis man ønsker at implementere flere kriterier med tiden, skal disse blot lægges i PersonSearchCriteria-objektet og derefter skal GetList-metoden ændres så de nye kriterier håndteres. Dermed ændres der ikke på repositoryinterfacet og man sparer derfor, at skulle rette i evt. andre klienter som er afhængige af respositoryklassen.

Se også

En artikel om et generisk repository, som kan gøre hele arbejdet med repositories noget enklere.