Developing Data Access Solutions with Microsoft Visual Studio 2010 Examen 70-516
ADO.Net Zonder Object Relational Mapping (ORM) en interessant tot en met .Net framework 2.0. ADO.Net ondersteund SQL Server, Oracle, ODBC en OLEDB. Met SQLConnection, SQLCommand, SqlDataReader, SqlDataAdapter, DataSet en DataTable kun je zelf data ophalen uit de database: - SQLCommand.ExecuteDataReader() levert tabeldata op, specifiek voor Select acties. - SQLCommand.ExecuteScalar() levert een 1 bij 1 tabeldata op, oftewel 1 value. - SQLCommand.ExecuteNonQuery() levert geen data op, maar de number of rows effected. Voor Insert, Update en Delete acties. Daarnaast kun je ook een dataadapter gebruiken: - SQLDataAdapter.Fill(DataTable) haalt de data ook op en vult de DataTable en opent en sluit de Connection, specifiek voor Select acties. - SQLDataAdapter.Update(DataTable) update de database. De Insert, Update en Delete Commands moeten wel gedefinieerd worden, anders weet de Update() functie niet hoe de data weggeschreven moet worden. Veel controls zoals een combobox hebben een ValueMember en een DisplayMember property. Om de ID en de toonwaarde te definieren. Een DataTable kan dan aan de DataSource gekoppeld worden. Je kunt ook werken met Typed DataSets, een XSD met code erachter voor intellisense en compile type type safety. Typed DataSets kun je maken op 2 manieren: - met de Data Source Configuration Wizard in Visual Studio - met de XSD.exe command line tool
Linq to SQL Linq to SQL is de ORM introductie na ADO.Net, maar wordt ook niet meer ondersteund. Alleen voor SQL Server. De XSD met code behind voor intellisense en compile type type safety zit in een .dbml file. - een db Tabel is een Linq to SQL entity class - een db Column is een Linq to SQL class member - een db foreign key is een Linq to SQL Association - een db Stored procedure of function is een Linq to SQL method Alle onderdelen moeten eerst in de .dbml gesleept worden in de designer vanuit de Server Explorer window vanuit de data connections. De .dbml file beschrijft ook de sqlConnection, dus met de DataContext van de .dbml kun je ook meteen data ophalen. Met DataContext.ObjectTrackingEnabled = false; gebruik je een ReadOnly DataContext. Met Linq kun je querien op de DataContext. In Linq kun je een enkele rij pakken met .Single(p => p.id = 1), bij meerdere krijg je een exception. Met SingleOrDefault, geeft ie bij niks een default terug. Met .First pak je TOP(1), altijd de eerste. Met FirstOrDefault, geeft ie bij niks een default terug. Een default is altijd NULL, 0 of false. Aanpassen van data kan voor de update op het object zelf. Inserten en Deleten met DataContext.object.InsertOnSubmit() en .DeleteOnSubmit(). Met DataContext.SubmitChanges() persisteer je alle wijzigingen naar de database. De DataContext.GetChangeSet() retourneerd een ChangeSet object. met .Deletes, .Inserts en .Updates kun je zien welke data er in de database gepersisteerd gaat worden. Met de DataContext.Log property kun je bij het debuggen zien welke Linq to SQL commands er gegenereert worden. Concurrency fouten kunnen worden opgelost met de Refreshmode enumerator: KeepCurrentValues overschrijft de db / OverwriteCurrentValues overschrijft memory / KeepChanges merged.
Entity Framework Models Het .Net Entity Framework is parallel ontwikkelt en is het uiteindelijk geworden. Ondersteund ook andere platformen, zoals SQL Server, Oracle, ODBC en OLEDB. Het ADO.Net Entity Data Model levert een .edmx file op. Er zijn 3 Entity Framework Models: - Physical Model, de data is opgeslagen in de database - Logical Model, beschrijft hoe de data is opgeslagen in de database op basis van keys - Conceptual Model, de gemapte business object view zonder joins. Hier is het Microsoft .Net Entity Framework op gebaseerd. Te zien in code als het Entity object. In de .edmx file staan 3 XML secties: - CSDL, zoals de business objecten heten: Person.Voornaam - SSDL, hoe de data is opgeslagen in de database: Person.FirstName - MSL, hoe de mapping is gedefinieerd: Person.Voornaam = Person.FirstName Deze secties zijn gevisualiseerd in de Entity Data Model Browser. Eventuele mappings zijn te zijn in de Entity Data Model Mapping Details. - een db Tabel is in het Entity Framework een Entity class - een db foreign key is in het Entity Framework een Association - een db Stored procedure of function is in het Entity Framework een Function Imports Met het .Net Entity Framwork kun je Database First en Model First designen en de andere genereren. Er zijn 2 Wizards: - Update Model from Database. Dit is een subtiele wizard waarin je kan kiezen welke tables, views en stored procedures je wilt importeren. De wizard heeft respect voor de bestaande mappings in de .edmx file. - Generate Database from Model. Dit is een heel lang sql script zonder opties en overschrijft je .edmx file ook geheel aan het einde. Entity splitting betekent dat er 1 entiteit in de business objecten gemapt is op 2 verschillende database tabellen. Dit zou logisch zijn voor 1 business object met 2 database tabellen: een actuele tabel en een history tabel. Daarnaast kun je ook meerdere business objecten hebben op 1 database tabel. Dit zou logisch zijn als de database tabel een auto type heeft, en je een business object type safe maakt per type. Dan maak je een Condition aan op dat type. Een stored procedure kun je ook inladen in je .edmx. Je ziet hem niet maar met rechtermuis > View model is hij wel te zien. Een stored procedure moet je zelf eerst mappen op een Function Imports. Dan wordt die functie ter beschikking gesteld op je Entity object.
Querying Een ObjectContext creer je op basis van de Entity Framework connection string. De Entity Framework connection string is het conceptuele model met de CSDL business objecten. Die praat weer met de database. De ObjectContext is een Entities Cache. Hier worden alle Entities in geladen. Bij de dispose wordt deze weer weggegooid. Linq querying doe je op basis van deze ObjectContext. Denk na over het gemak van een lange Cache VS concurrency problemen. Een Cache kun je ook refreshen met ObjectContext.Refresh(RefreshMode, object); De RefreshMode enumerator kan met .ClientWins en .StoreWins. De data houdt altijd de oude en de nieuwe waarde vast. Bij ClientWins wordt de oude waarde overschreven door de database om ondertussen ontstane concurrency problemen te verwijderen. Bij StoreWins wordt zowel de oude waarde als de nieuwe waarde overschreven door de database om ondertussen ontstane concurrency problemen te verwijderen en de nieuwe gewijzigde waarde te vergeten. Met Linq queries kun je Querien op de entiteiten. De waarden worden niet opgehaald bij de Linq Query, maar pas opgehaald bij het gebruiken van de data, bijvoorbeeld: query.ToList(); het zogenaamde Materializen. Het opbouwen van de Entity objecten in de ObjectContext. Met de ((ObjectQuery)linqquery).ToTraceString(); kun je zien welke database SQL Linq uiteindelijk genereert om de database te benaderen. Je kunt ook querien met Entity SQL tegen het Entity Model, net iets anders dan database SQL, want je praat tegen objecten en niet tegen tabellen. Wat je dan nodig hebt zijn de EntityClient objecten: EntityConnection, EntityCommand, EntityParameter, EntityDataReader en EntityTransaction. Een voorbeeld van een Entity SQL query is: “SELECT VALUE e FROM entitymodel.entityname as e WHERE
[email protected]” Een EntityConnection kun je creeren op basis van de connnectionstring in de web.config van het Entity Model met new EntityConnection(“name=entitymodelname”); Deze Entity SQL query kun je meegeven aan het EntityCommand(“entitysql” EntityConnection) object, maar je kunt ook op de ObjectContext.CreateQuery(“entitysql”) aanroepen om een query te maken als concurrent van een Linq Query. Tevens kun je stored procedures geimporteerd als import function aanroepen op het entity model en gebruiken in code.
Updating Updaten oftewel persisteren van data uit het Entity model naar de database kan met .SaveChanges(). Inserten van een object in het ObjectContext kan met .AddObject(). Deleten van een object in het ObjectContext kan met .DeleteObject(). Het update van een object kan door een property van het ObjectContext aan te passen. Indien je nog steeds beschikking hebt over de ObjectContext kun je simpelweg de ObjectContext.SaveChanges() aanroepen en daarmee persisteer je data naar de database. Ook kun je bijvoorbeeld een Product toevoegen, een ProductCategory erachter toevoegen en het geheel persisteren naar de database. Het Entity Framework insert dit allemaal in de database en verzorgt ook de foreign key relaties met id’s. Echter, als je niet meer de beschikking hebt over de ObjectContext omdat de UI-Tier architectureel geen beschikking heeft over het Entity Framework en de ObjectContext en er komt een geupdate gedetached Business Object terug. - Creer dan eerst een Entity Key op basis van de gedetachede Business Object, dit doet hij intern op de primairy key van de database die ook in het object zit. - Doe daarna een .TryGetObjectByKey(entitykey) om een Entity attached object te creeren - Om vervolgens een ApplyCurrentValues(gedetached Business Object) de nieuwe waarden bekend te laten maken. Updaten van een object in het Entity model kan met ObjectContext.ApplyCurrentValues(). Deze overschrijft de nieuwe waarde over de oude waarde heen in de eigen ObjectContext. Deze functie gaat niet naar de database. - Of een DeleteObject(attached Entity object) te doen. - Als laatste kunnen de nieuwe waarden gepersisteerd worden met ObjectContext.SaveChanges() Wil je de ModifiedDate ophogen, een log file bijschrijven, niet alle of juist extra velden wegschrijven bij een aanpassing, of andere custom acties bij het persisteren? Maak een stored procedure voor Insert / Update / Delete en hang die in je Entity Model onder een Entity.
Als je de Linq query eerst cast naar een ObjectQuery, met ((ObjectQuery)linqquery) dan krijg je extra opties, zoals dat je de MergeOption kan zetten op de query. De MergeOption bepaald hoe de data wordt geladen in de Entity ObjectContext Cache. Mogelijkheden van de MergeOption: - Detached: NoTracking: Geen oude waarden bijhouden, bijvoorbeeld omwille van performance. Alleen de nieuwe waarden worden bijgehouden, om later te kunnen persisteren. - Attached: PreserveChanges: van entiteiten die al geladen waren, wordt de oude waarde opgehaald en overschreven, nieuwe waarde wordt gerespecteerd. - Attached: OverwriteChanges: van entiteiten die al geladen waren, wordt zowel de oude waarde als de nieuwe waarde opgehaald en overschreven - Attached: AppendOnly: Default, als een entiteit al is opgehaald, haalt ie die niet nog eens op. Hij laat alle oude en nieuwe waarden voor die entiteit staan. Nadien kun je met ObjectContext.Detach(object) nog naar Notracking (alleen nieuwe waarde, geen oude waarde) en met ObjectContext.Attach(object) weer naar Attached modus, de oude waarde en de nieuwe waarde worden dan de nieuwe waarde. Change Tracking: Er is een Object State Manager beschikbaar op de ObjectContext waarin alle changes getracked kunnen worden, bijvoorbeeld het bekijken van de original values: ObjectContext.ObjectStateManager.GetObjectStateEntry(entiteit).OriginalValues[“”]
Concurrency & Transactions Pessimistic Concurrency betekent locks op de database tussen het lezen en het wijzigen. SQL Server Default. Optimistic Concurrency betekent geen locks op de database vanaf het lezen. Entity Framework Default. Het Entity Framework overschrijft standaard altijd, de laatste wijziging wint. Als je op alle kolommen in het Entity Model Concurrency Mode=Fixed zet, of op een Modified Date kolom per Entity, dan eist de gegenereerde SQL onder het Entity Framework dat de oude waarde nog bestaat voordat de nieuwe waarde weggeschreven wordt met een WHERE clause met de oude waarde bij de UPDATE. Pas als Concurrency Mode=Fixed is gezet en de oude waarde klopt niet meer, pas dan kan er een Optimistic Concurrency Exception optreden. Elke ObjectContext.SaveChanges() is impliciet 1 transactie. Bij 8 wijzigingen en 1 Concurrency Exception, zullen alle 8 wijzigingen gerollbacked worden. Uit een Optimistic Concurrency Exception kun je vissen wat de huidige database waarde is en wat de oude en nieuwe waarde van de ObjectContex.SaveChanges() was. Dan kun je de gebruiker Functioneel notificeren over wat er gebeurt is en het invoer scherm opnieuw aanbieden.
Je kunt Transacties beginnen met SQLTransaction t=connection.BeginTransaction() en meegeven op elke SQLCommand in de transactie en afsluiten met t.Commit() of t.Rollback(). Een transactionScope is een apart object over meerdere connections heen. Binnen het using block van de transactionScope vallen alle ObjectContex.SaveChanges() binnen 1 transactie. Aan het einde komt dan een scope.Complete(). Wil je een transactie scope rollbacken doe dan een scope.Dispose(). Als een ObjectContext.SaveChanges() binnen een transactie mislukt en gerollbacked wordt, denkt de ObjectContext standaard dat het wel gelukt is en werkt de ObjectContext Cache bij als zijnde gelukt. Wil je dit standaard gedrag niet, geef dan aangepaste SaveOptions.None mee bij de ObjectContext.SaveChanges( SaveOptions.None ). Dan wordt de ObjectContext Cache helemaal niet meer bijgewerkt. Doe dit dan zelf, alleen bij een geslaagde transactie, door ObjectContext.AcceptAllChanges(). Om transacties te kunnen gebruiken moet je nog een reference adden vanuit je Visual Studio project naar System.Transactions. De transaction isolationlevel kun je zetten: - ReadUnCommitted, transacties kunnen elkaars uncommitted data lezen. - ReadCommitted, transacties kunnen alleen elkaars committed data lezen. - RepeatableRead, een transactie locked alle data die die leest. - Serializable, een transactie locked alle data van een tabel die gebruikt wordt. Dit is Default. Er zijn 3 soorten transacties: - Implicit, bijvoorbeeld ObjectContext.SaveChanges(), waar geen code voor geschreven hoeft te worden. - Explicit, code schrijven om de transactie te beginnen en te eindigen. - Distributed, hetzelfde als expliciet, maar dan over meerdere datasources heen.
Optimization De performance van het Entity Framework kun je optimaliseren op verschillende manieren: Je kunt de ObjectContext.Connection.Open() en Close() handmatig doen, en daartussen meerdere .SaveChanges(). om de connectie open te houden en extra performance te bereiken. Je .edmx Entity Model handmatig creeren met EdmGen.exe. Dit betekent een .cs file maken van je ssdl, csdl en msl binnen de .edmx file. IIS doet dit bij de allereerste keer zelf, maar deze stap kun je er dus tussenuit halen om dit designtime zelf te doen. Je kunt NoTracking instellen. Geen oude en nieuwe waarden bijhouden binnen de ObjectContext. Je kunt Compiled queries gebruiken. Normaal gesproken moet een Linq query vertaald worden naar Database SQL. Met een een compiled query genereert hij die niet elke keer runtime, maar eenmalig en staat de Database SQL al klaar. Zet deze compiled query in de Application_Onstart en beschikbaar voor de gehele applicatie en ziehier de performance winst. De syntax is: static Func<EntityModel, IQueryable<Entity>> compiledQuery = CompiledQuery.Compile<EntityModel, IQueryable<Entity>> (ent => from e in ent.Entity where e.Column > waarde select e); Je kunt een background worker proces gebruiken om in een andere Thread werk af te handelen. De syntax is: BackgroundWorker bw = new BackgroundWorker(); Bw.RunWorkerAsync(); Hierbij moeten er 2 events gedefinieerd worden: DoWork() en RunWorkerCompleted() om het werk in te zetten en de callback functie te definieren.
Customization Entities worden uitgegenereerd in partial classes. Daarnaast kun je zelf een partial class maken voor deze entity en er extra informatie op elke property en extra properties op meegeven. Als het Entity Model opnieuw gegenereerd wordt vanuit de database, dan blijven deze aanpassingen in je eigen partial class. Ook heeft elke property van een gegenereerde Entity een partial propertyChanging en een partial propertyChanged methode. In je eigen partial class kun je ook deze partial methods definieren en er bijvoorbeeld DataRules in afdwingen. Helaas gaan de propertyChanging en properyChanged partial methods ook af bij het ophalen van data. Voor de performance erg onhandig dat de DataRules dan ook afgaan. Een partial method kan niet uitgerust worden met public. Wil je de partial method buiten de eigen class gebruiken, zet er dan een public function naast die de partial method aanroept. Daarnaast zijn extension methods mogelijk. Begin een willekeurige static class en definieer daar static extension methods. Bijvoorbeeld: public static bool IsIntBigNumber(this int getal) {return getal > 1000;} Nogal een freestyle manier om een extension method met het keyword this op een integer zetten. Met de tttt (T4) taal is beschreven hoe een .edmx XML file omgezet wordt in de .cs file waarin de Entities type safe in gegenereerd worden. Je kunt een ADO.Net EntityObject Generator .tt file toevoegen aan je project. Hierin kun je de .edmx file specificeren en op je eigen manier de Entities type safe uitgenereren in een .cs file. Zet dan wel in je .edmx file de Code Generation Strategy op None, dit voorkomt het uitgenereren in de .cs aldaar, want anders heb je alle Entities 2x in je namespace gedefinieerd. Daarnaast kun je ook zelf een custom Entity class maken die afgeleid is van EntityObject. Als je deze class met de juiste attributen als [EdmEntitytype(Namespacename=”EntityModel”)] uitrust, dan wordt je eigen custom Entity class beschikbaar binnen het Entity Framework. Let wel alle primairy en foreign keys moeten allerlei attributen hebben. Dit is veel werk.
POCO Entity classes (Plain Old CLR Objects) Met POCO Entity classes ga je niet Entity Framework classes, toch in de ObjectContext laden. Dit kan op 3 manieren. - Je kunt ObjectContext.Attach(eigenobject) aanroepen en het persisteren naar de database via het Entity Framework. - Of met ObjectContext.CreateObject() een entity framework object maken en de POCO class properties eroverheen kopieren en het persisteren naar de database via het Entity Framework. - De POCO classes hebben hun eigen code om persisteren naar de database. Je maakt wel een .edmx file met entiteiten voor de classes, maar genereert niet de code erachter, door Code Generation Strategy op None te zetten. Je wint de voordelen van de ObjectContext, zoals Caching. Een aantal voorwaarden: de classname en property names moeten gelijk zijn aan de entiteiten in de .edmx file. Verschillen kun je oplossen in de MSL mappingen van de .edmx file. Classes moeten public zijn, een public constructor hebben en de ProxyCreationEnabled property op true hebben. Daarnaast moet je van bijvoorbeeld het entiteit Product, wel de Products ter beschikking hebben, dit kun je doen met CreateObjectSet(). Lazy Loading is het automatisch ophalen van gerelateerde data achter de data. Er moeten wel Associations gedefinieerd zijn en die Navigation Properties moeten public en virtual zijn. De concurrent is Eager Loading, dit is het meteen ophalen van alle gerelateerde data. In Linq kun je een .Include(“gerelateerde data”) definieren om de gerelateerde data expliciet op te halen. Change Tracking is het bijhouden van oude en nieuwe waarden. Het Entity Framework maakt onder water 2 objecten, 1 voor de oude en 1 voor de nieuwe waarden. Voorwaarden, alle properties moeten public en virtual zijn en je moet overal in code ObjectContext.CreateObject() gebruiken ipv een new. Om de dubbele objecten te creeren. Voor het persisteren van de data moet de ObjectStateManager eerst in de goede status gezet worden. Roep altijd eerst de ObjectContext.DetectChanges() om dit te doen vlak voor de ObjectContext.SaveChanges().
N-Tier Solutions Over web services data uitwisselen, of in de web front end data ter beschikking stellen kan met: - DataSets, iedereen gebruikt microsoft en heeft change tracking, dure data. Dit is legacy. - Data transfer object (DTO), XML, open, geen change tracking. Dit is een uitgeklede versie van een entity, waar alleen het hoognodige in zit. Dit is architectureel het mooiste. Maak een apart DTO DataContract met Datamembers aan, en maak een mapping van en naar de Entities van het Entity Framework. - Simple Entity (SE), .net Entity Framework detached entity in XML, geen change tracking De simple entity komt terug met nieuwe waarden en kun je met .Attach weer in de ObjectContext plaatsen. o Met .DetectChanges() kun je de ObjectContext bijwerken qua change tracking. o Daarnaast kun je ook met ObjectContext.ObjectStateManager.ChangeObjectState(object, Entitystate.Modified) de status handmatig updaten. - Self Tracking Entity (STE), .net Entity Framework detached entity, maar dan met wat extra functionaliteit voor change tracking. Self Tracking Entities maken kan met een ander T4 Model: ADO.Net Self Tracking Entity Generator. o Dit genereert weer alle classes uit op basis van een .edmx bestand, maar dan in allemaal aparte classes onder een .tt bestand met extra change tracking functionaliteit. Via Web Services stel je de objecten ter beschikking via WSDL. Aan de Client kant wordt dan een proxy gegenereerd met deze object. Met een WPF windows client zet je de Self Tracking Entities apart in een eigen class project, lees dll, waarnaar de WPF windows client kan verwijzen, zonder notie te hebben van het Entity Framework. o Tevens genereert het een context.tt bestand met daarin de code die nodig is om de extra informatie op het Self Tracking object weer in te laden in de ObjectContext. Bij de .Attach() wordt de ObjectContext bijgewerkt qua change tracking. Zet wederom wel in je .edmx file de Code Generation Strategy op None, dit voorkomt het uitgenereren in de .cs aldaar, want anders heb je alle Entities 2x in je namespace gedefinieerd. o MarkAsDeleted() op de STE aanroepen op de client markeert een object als te deleten, komt het object dan met .Attach() terug in de ObjectContext, dan weet het Entity Framework dat het object gedelete moet worden. ApplyChanges() vlak voor SaveChanges() kan ipv een .Attach() zorgen voor het weer binnen de ObjectContext laden. Dit kan als de .Attach() niet werkt als het object in de tussentijd geattached is door andere functionaliteit. Met het PrinciplePermission attribute kun je de autorizatie afdwingen op een WCF service operation, de syntax is: [PrincipalPermission (SecurityAction.Demand, Role=”Admin”)]
Updates in N-Tier Los van het laden van waarden en het wederom persisteren van data kun je ook Waarden berekenen of laten genereren: - Vanuit de database kunnen wijzigingen terugkomen naar het Entity Framework. Zoals een auto identity van een primairy key. Op een kolom in de .edmx file kun je dan zeggen: StoreGeneratedPattern = Identity. Dan zal de automatisch generereerde waarde in de kolom vanuit de database geladen worden in de ObjectContext. - Daarnaast kunnen er ook calculated fields in de database aanwezig zijn. Op een kolom in de .edmx file kun je dan zeggen: StoreGeneratedPattern = Computed. Dan zal de berekende kolom vanuit de database geladen worden in de ObjectContext. - Op een kolom in de .edmx file kun je ook zeggen: StoreGeneratedPattern = None. Dit is standaard. In het geval van een Calculated Field wordt je dan in een partial class naast de gegenereerde Entities partial class zelf verantwoordelijk voor het uitrekenen van de kolom. Een UpdateException kan ontstaan wanneer de integriteit van de database in het geding komt, wanneer de database bijvoorbeeld meer constraints heeft dan het Entity Model. Een OptimisticConcurrencyException kan ontstaan wanneer er tegen concurrency problemen aangelopen wordt. Maak hier een FaultException van die geserializeerd kan worden als bijvoorbeeld een SOAP fault naar de clients van een WCF service. Connection pooling is een cache van het hergebruiken van connections. Connectionstrings kun je encrypten en decrypten met de command line tool: aspnet_regiis.exe Dit moet per se op de server waar de web.config staat.
Occasionally Connected Occasionally connected is bedoeld voor Windows applicaties. Hierin zijn 2 strategieen, alles zelf maken met Linq 2 XML of het Sync Framework gebruiken. Linq 2 XML Er zijn een nieuwe generatie XML objecten beschikbaar: Linq 2 XML Classes. Xdocument, Xelement en Xattribute. In combinatie met Linq kun je middels een Linq query de Xdocument vullen met Xelement en Xattribute naar eigen invulling vanuit een Entity. Met .Save() kun je een XML file saven op disk. Met de Xelement.Load() kun je de XML weer lezen vanaf disk. Je moet dan wel casten naar de werkelijke typen, want uit XML komen alleen maar strings. Hier kun je dan met Linq weer queries op schrijven. Hier heb je dan geen Xpath voor nodig. Deze Xml documenten op disk kun je encrypten met het object EncryptedXML. Op dit object kun je .EncryptData() en DecryptDocument() functies beschikbaar. (Met de XmlSerializer kun je een Entity serialiseren naar XML en ook wegschrijven naar disk.)
Het Sync Framework Je kunt een Local Database Cache .sync file toevoegen aan je project. Dan kun je door een wizard heen lopen om de tabellen aan te wijzen die je lokaal wilt cachen, als er geen connectie is. Dit levert uiteindelijk een .SDF database file op op de client. Het syncen zelf kan je aan SQL Server overlaten, of zelf velden of tabellen aanwijzen op basis waarvan de sync moet gaan plaatsvinden. Ja, het Sync Framework werkt alleen met SQL Server. Synchronisatie kan in verschillende modes, in te stellen met SyncDirection per Tabel in code: - Snapshot, totale delete en insert van de client data bij de synchronisatie. - Download Only, server wijzigingen komen door op de client. Client kan niet persisteren. - Upload Only, client kan wijzigen. Updates van de server komen niet terug naar de client. - BiDirectional, client en server kunnen de sync updaten. Kans op conflicten Synchoriseren is enkel tussen 2 databases. Je krijgt in je project dan: - Extra referenties naar het sync framework - Sql scripts om de server database uit te rusten met sync data. - Een .sdf file voor de lokale cache - Een .sync file, waar de output van de Sync Framework wizard in staat In code kun je dan de LocalSyncAgent.Synchronize() aanroepen. Verwacht bij lange offline tijden wel concurrency problemen. Deze conflicten kun je oplossen met de volgende Actions: - Continue, Default, de wijziging wordt niet doorgevoerd - RetryApplyingRow, nog een keer proberen - RetryWithForceWrite, nog een keer proberen en wijziging toch doorvoeren De lokale database .sdf valt te encrypten bij de create van de database. De connectionstring naar de database moet dan met encrypt database=true.
WCF Data Services Naast de WCF Service is er ook nog de WCF Data Service. De WCF Data Service zorgt ervoor dat de Cache van de ObjectContext volledig ter beschikking is bij de Client. Nu moet je om de ObjectContext te kunnen genereren geen connectionstring gebruiken met csdl, msl, ssdl en de database connection, maar een URI naar de WCF Data Service. Uiteraard werkt dit alleen met een .Net Client die het Entity Framework ondersteund. De service kun je aanroepen via de url: http://localhost/website/service.svc/entiteit(1)/property Alles wat je in SQL kan doen, kan je nu op de url doen. Selecten met ?$select en ?$filter voor de where clause en ?$orderby voor de order. De data die terugkomt is dan het Open Data Protocol: Odata.
Security moet dan wel goed afgedwongen worden met SetEntitySetAccessRule(entiteit, EntitySetRights.AllRead) voor alleen lezen van 1 specifieke Entity. Maximaliseren van het aantal result waarden kan met SetEntityPageSize(entiteit, 100). Vanuit een Client kun je een Service Reference leggen naar de WCF Data Service. En de Client kun je dan de WCF Data Service zijn ObjectContext gebruiken. Met de .AddQueryOption() op een Entity van de ObjectContext maakt je vanuit code extra ?$ url opties die je helpen om te querien door de data. Tevens kun je voorgedefinieerde methoden op de WCF Data Service definieren ipv iedereen via de url alles te laten selecten. Voor een select method gebruik het attribuut [WebGet] boven de method. En voor Insert / Update / Delete methods gebruikt het attribuut [WebInvoke] boven de method.
Updating Wanneer de ObjectContext.SaveChanges() vanuit de Client zijn Cache gedaan wordt, moeten alle Entities met CRUD vertaald worden via de HTTP Response naar de WCF Data Service met alle Insert / Update / Delete syntaxen. Onder water wordt gebruikt: - HTTP POST voor de Create - HTTP PUT en HTTP MERGE voor een Update - HTTP DELETE voor een Delete Op het moment dat er gerelateerde data is, bijvoorbeeld Products.Categories, moet je aan de Client kant toch nog extra zaken regelen, ondanks dat je de ObjectContext ter beschikking hebt: - AddRelatedObject, een nieuwe bidirectional link tussen 2 Entities - AddLink, een link tussen 2 Entities vanuit de Many kant - SetLink, een link tussen 2 Entities vanuit de 1 kant - DeleteLink, verwijderd een link tussen 2 Entities. Dan moet het foreign key id wel nullable zijn of mede verwijderd zijn anders krijg je bij SaveChanges() een foreign key fout - AttachLink, zet change tracking aan voor gerelateerde data, handig wanneer de Entities zelf net ook geattached zijn - DetachLink, zet change tracking uit voor gerelateerde data Naast Updating via de Entity Framework Provider, kun je ook updaten via 3 andere providers: - Reflection Provider, die implementeerd de Iqueryable en de Iupdatable interfaces om standaard non-Entity CLR objecten naar de client te ontsluiten. - Streaming Provider, om Binairy over te krijgen naar de Client. - Een serie Custom Data Providers, om je eigen Providers te schrijven.
