For years we (a lot of people I know and myself included) have been using the Unit of Work and Repository pattern combined with each other. This makes quite a lot of sense as, in most cases, they both have something to do with your database calls.

When searching for both of these patterns you’ll often be directed to a popular article on the Microsoft documentation site. The sample code over there has a very detailed implementation on how you can implement both of these patterns for accessing and working with your database. I kind of like this post as it goes in great length to describe both the unit of work- and repository pattern and the advantages of using them. I see a lot of projects/companies having implemented the pattern combo like described in the Microsoft article. I can’t really blame them as it’s one of the top hits when you search for it in any search engine.

There is a downside to this sample though. It violates the Open/Closed principle which states

software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

Whenever you need to add a new repository to your database context, you also need to add this repository to your unit of work, therefore violating the open/closed principle.

In m’n database maak ik gebruik van een idenity veld dat bestaat uit een Guid. Deze guid wordt automatisch gegenereerd binnen SQL Server door middel van de newsequentialid() functie (dit kan uiteraard ook met newid()). Dit betekend dus dat ik in m’n code niet een guid hoef aan te maken, omdat SQL dit al zelf doet. In de op te slaan entity vul ik het ID veld dus ook niet.

Nadat het insert commando is uitgevoerd verwachtte ik dat het ID veld zou worden gevuld met de nieuw aangemaakte guid, maar niets is minder waar. Het blijft een Guid.Empty (00000000-0000-0000-0000-000000000000). In het EF1.0 werkte dit inderdaad niet, daar was helemaal geen support voor Guid identity velden. Er was echter beloofd om dit wel op te lossen in het EF4.0. Na een kleine zoektocht kom ik op allerlei pagina’s en sites die het hebben over EF1.0 en Linq-to-Sql, iets waar ik in het verleden ook al dit probleem heb gehad.

Met de ervaring die ik uit het verleden had, heb ik ook al even zelf zitten klikken en zag dat de StoreGeneratedPattern op None stond. Deze heb ik op Identity en op Computed gezet. Beide keren was dit niet de oplossing.

Momenteel ben ik met een project bezig dat met 2 tiers werkt (de database even niet meegerekend). Er is een presentatie laag (MVP) en deze staat in verbinding met een WCF service, de 2e tier. Deze 2e tier heeft dus een service laag, maar ook een business- (BL) en een data access laag (DAL). Dit is tegenwoordig een redelijk standaard design.

Omdat ik het Entity Framework wil gebruiken (https://jan-v.nl/post/entity-framework-4.0-in-een-n-tier-applicatie-met-wcf-implementeren/) zal alleen de DAL toegang moeten hebben tot het Model. De verschillende Entities worden wel in alle projecten gelinkt (service layer, busines layer en data access layer).

Het design heb ik al een tijd goed werkend, echter toen ik het geheel wilde gaan testen liep ik tegen problemen aan. De eerste fout die ik tegen kwam was de volgende:

ArgumentException: The specified named connection is either not found in the configuration, not intented tob e used with EntityClient provider, or not valid

Dit was al snel opgelost door de connectiestring in de web.config van de service te plaatsen.

Nadat ik dat had gedaan kwam er een vervelende fout naar voren, namelijk:

MetadataException: Unable to load the specified metadata resource.

Er is hier veel over te vinden op het internet en komt er op neer dat de metadata van de edmx niet in de dll zijn meegenomen, of dat de referenties in de connectiestring niet correct zijn.

Momenteel ben ik bezig om een nieuw project op te zetten waar ik gebruik wil gaan maken van het Entity Framework 4.0 en WCF. Aangezien .NET 4.0 net uit is, zou dit geen probleem meer moeten zijn.
Nu heb ik nog niet eerder goed met het EF gewerkt, dus is het allemaal nog redelijk nieuw voor mij. Gelukkig zijn er veel mensen die hier al het een en ander over hebben geschreven en ook duidelijke voorbeelden hebben gemaakt hoe het kan worden geimplementeerd.

Omdat ik toch graag een n-layer applicatie wil opzetten liep ik (onder andere) tegen het probleem aan dat het database model niet direct bekend is zijn op de client (de website). De verschillende objecten/entities zullen dus moeten worden geserialized om op de website te kunnen gebruiken. Dit is natuurlijk iets waar al menig ander tegenaan is gelopen, dus heb ik gezocht naar mogelijke oplossingen.

De eerste nuttige hit die ik heb gevonden was een post van Eliska Flasko uit het MSDN Magazine van April 2010 (https://msdn.microsoft.com/en-us/magazine/ee336128.aspx).
Een heel duidelijk stuk waar mij de grote lijnen wel duidelijk werden. Tijdens het doorlopen van dit stuk zag ik dat ze hier gebruik maken van het ADO.NET EntityObject Generator template en niet de Self-Tracking variant.