Zijn ze hetzelfde? Net klaar met het bekijken van Rob Connery’s Storefront-tutorialen ze lijken vergelijkbare technieken te zijn. Ik bedoel, wanneer ik een DAL-object implementeer, heb ik de methoden GetStuff, Add/Delete enz. en ik schrijf altijd eerst de interface, zodat ik later van db kan wisselen.
Verwar ik dingen?
Antwoord 1, autoriteit 100%
Jij bent zeker niet degene die dingen door elkaar haalt. 🙂
Ik denk dat het antwoord op de vraag afhangt van hoeveel purist je wilt zijn.
Als je een strikt DDD-standpunt wilt, kom je op één pad. Als je de repository ziet als een patroon dat ons heeft geholpen de interface te standaardiseren van de laag die de services en de database scheidt, zal het je naar een andere brengen.
De repository is vanuit mijn perspectief slechts een duidelijk gespecificeerde toegangslaag tot gegevens. Of met andere woorden een gestandaardiseerde manier om uw gegevenstoegangslaag te implementeren. Er zijn enkele verschillen tussen verschillende repository-implementaties, maar het concept is hetzelfde.
Sommige mensen zullen meer DDD-beperkingen op de repository leggen, terwijl anderen de repository zullen gebruiken als een handige bemiddelaar tussen de database en de servicelaag. Een repository zoals een DAL isoleert de servicelaag van specifieke gegevenstoegang.
Een implementatieprobleem dat ze anders lijkt te maken, is dat een repository vaak wordt gemaakt met methoden die een specificatie vereisen. De repository retourneert gegevens die aan die specificatie voldoen. De meeste traditionele DAL’s die ik heb gezien, zullen een grotere set methoden hebben waarbij de methode een willekeurig aantal parameters nodig heeft. Hoewel dit misschien als een klein verschil klinkt, is het een groot probleem wanneer je de rijken van Linq en Expressions betreedt.
Onze standaard repository-interface ziet er als volgt uit:
public interface IRepository : IDisposable
{
T[] GetAll<T>();
T[] GetAll<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors);
void Delete<T>(T entity);
void Add<T>(T entity);
int SaveChanges();
DbTransaction BeginTransaction();
}
Is dit een DAL of een repository? In dit geval denk ik dat het beide is.
Kim
Antwoord 2, autoriteit 49%
Een repository is een patroon dat op veel verschillende manieren kan worden toegepast, terwijl de gegevenstoegangslaag een zeer duidelijke verantwoordelijkheid heeft: de DAL moet weten hoe hij verbinding moet maken met uw gegevensopslag om CRUD-bewerkingen uit te voeren.
Een repository kaneen DAL zijn, maar het kan ook voor de DAL zitten en fungeren als een brug tussen de bedrijfsobjectlaag en de gegevenslaag. Welke implementatie wordt gebruikt, verschilt van project tot project.
Antwoord 3, autoriteit 26%
Een groot verschil is dat een DAO een algemene manier is om met persistentie om te gaan voor elke entiteit in uw domein. Een repository daarentegen houdt zich alleen bezig met geaggregeerde wortels.
Antwoord 4, autoriteit 13%
Ik was op zoek naar een antwoord op een vergelijkbare vraag en ben het eens met de twee hoogst gerangschikte antwoorden. Toen ik dit voor mezelf probeerde te verduidelijken, ontdekte ik dat alsspecificaties, die hand in hand gaan met het Repository-patroon, worden geïmplementeerd als eersteklas leden van het domeinmodel, dan kan ik
- hergebruikSpecificatiedefinities met verschillende parameters,
- manipulerenparameters van bestaande specificatie-instanties (bijvoorbeeld om zich te specialiseren),
- combineerze,
- voer bedrijfslogica uitop hen zonder ooit enige toegang tot de database te hoeven doen,
- en, natuurlijk, unit-testze onafhankelijk van daadwerkelijke Repository-implementaties.
Ik kan zelfs zo ver gaan en stellen dat tenzijhet Repository-patroon samen met het Specificatie-patroon wordt gebruikt, het niet echt “Repository”, maar een DAL is. Een gekunsteld voorbeeld in pseudo-code:
specification100 = new AccountHasMoreOrdersThan(100)
specification200 = new AccountHasMoreOrdersThan(200)
assert that specification200.isSpecialCaseOf(specification100)
specificationAge = new AccountIsOlderThan('2000-01-01')
combinedSpec = new CompositeSpecification(
SpecificationOperator.And, specification200, specificationAge)
for each account in Repository<Account>.GetAllSatisfying(combinedSpec)
assert that account.Created < '2000-01-01'
assert that account.Orders.Count > 200
Zie Fowler’s specificatie-essayvoor details (daarop heb ik het bovenstaande gebaseerd).
Een DAL zou gespecialiseerde methoden hebben zoals
IoCManager.InstanceFor<IAccountDAO>()
.GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')
Je kunt zien hoe dit snel omslachtig kan worden, vooral omdat je elk van de DAL/DAO-interfaces met deze aanpak moet definiëren ende DAL-querymethode moet implementeren.
In .NET kunnen LINQ-query’s een manierzijn om specificaties te implementeren, maar het combineren van Specificatie (expressies) gaat misschien niet zo soepel als bij een oplossing van eigen bodem. Enkele ideeën daarvoor worden beschreven in deze SO-vraag.
Antwoord 5, autoriteit 2%
Mijn persoonlijke mening is dat het allemaal om mapping gaat, zie: http://www. martinfowler.com/eaaCatalog/repository.html. Dus de uitvoer/invoer van de repository zijn domeinobjecten, wat op de DAL van alles kan zijn. Voor mij is dat een belangrijke toevoeging/beperking, omdat je een repository-implementatie voor een database/service/wat dan ook kunt toevoegen met een andere lay-out, en je een duidelijke plek hebt om je te concentreren op het maken van de mapping. Als u die beperking niet zou gebruiken en de toewijzing ergens anders zou hebben, kan het hebben van verschillende manieren om gegevens weer te geven van invloed zijn op de code op plaatsen waar deze niet zou moeten veranderen.
Antwoord 6
Het draait allemaal om interpretatie en context. Ze kunnen erg op elkaar lijken of zelfs heel verschillend, maar zolang de oplossing werkt, wat zegt de naam!
Antwoord 7
In de externe wereld (d.w.z. klantcode) is de repository hetzelfde als DAL, behalve:
(1) it’s insert/update/delete methodes zijn beperkt tot het hebben van het data container object als parameter.
(2) voor een leesbewerking kan een eenvoudige specificatie nodig zijn, zoals een DAL (bijvoorbeeld GetByPK) of een geavanceerde specificatie.
Intern werkt het met een Data Mapper Layer (bijvoorbeeld de context van het entiteitsframework, enz.) om de eigenlijke CRUD-bewerking uit te voeren.
Wat Repository-patroon niet betekent:-
Ik heb ook gezien dat mensen vaak in de war raken om een ​​aparte Save-methode te hebben als de voorbeeldimplementatie van het repositorypatroon, naast de Insert/Update/Delete-methoden die alle in-memory wijzigingen die door de insert/update/delete-methoden zijn uitgevoerd, doorvoeren naar databank. We kunnen zeker een Save-methode in een repository hebben, maar dat is niet de verantwoordelijkheid van de repository om in-memory CUD (Create, Update, Delete) en persistentiemethoden (die de eigenlijke schrijf-/wijzigingsbewerking in de database uitvoert) te isoleren. verantwoordelijkheid van werkeenheidpatroon.
Hopelijk helpt dit!
Antwoord 8
Repository is een patroon, dit is een manier om de dingen op een gestandaardiseerde manier te implementeren om de code zo goed mogelijk te hergebruiken.
Antwoord 9
Het voordeel van het gebruik van een repository-patroon is om uw gegevenstoegangslaag te spotten, zodat u de code van uw bedrijfslaag kunt testen zonder DAL-code aan te roepen. Er zijn nog andere grote voordelen, maar dit lijkt mij erg belangrijk.
Antwoord 10
Voor zover ik heb begrepen kunnen ze in principe hetzelfde betekenen, maar de naamgeving varieert op basis van de context.
U kunt bijvoorbeeld een Dal/Dao-klasse hebben die een IRepository-interface implementeert.
Dal/Dao is een datalaagterm; de hogere niveaus van uw applicatie denken in termen van repositories.
Antwoord 11
Dus in de meeste (eenvoudige) gevallen is DAO een implementatie van Repository?
Voor zover ik begrijp, lijkt het erop dat DAO precies omgaat met db-toegang (CRUD – Geen selecties?!) ).
Ben ik op de goede weg?
Antwoord 12
Je zou kunnen stellen dat een “repository” een specifieke klasse is en een “DAL” de volledige laag is die bestaat uit de repositories, DTO’s, utility-klassen en al het andere dat nodig is.