INDHOLD 1 Domæne 2 1.1 Design valg........................................ 2 1.1.1 User........................................ 2 1.2 Database.......................................... 4 1.2.1 Tredje Normal Form (3NF)........................... 4 1.3 Klassediagran....................................... 6 1.4 Arkitektur......................................... 8 2 Serbio 9 2.1 Kommunikation...................................... 9 2.1.1 Bruger authentificering.............................. 11 2.1.2 Exceptions..................................... 11 2.2 Database.......................................... 12 2.2.1 Entity Framework................................. 12 2.3 Booking.......................................... 14 2.3.1 Sædevalg...................................... 14 2.3.2 Concurrency.................................... 14 2.3.3 Algoritme..................................... 16 3 Client 19 3.1 GUI............................................ 19 3.1.1 Eksempler..................................... 20 4 Konklusion 21 1
KAPITEL 1 DOMÆNE I vores domæne model, som ses i figur 1.1, har vi 8 klasser, som hver især har sine attributter. Hver klasse har enten en association, aggregation, composition og generalization som forbinder de forskellige klasser med hinanden. Et show er en movie med yderligere detaljer om hvor og hvornår filmen bliver afspillet. Det er en 1 til 1 forbindelse mellem Show og Hall, da et show skal være tilknyttet til en sal for at kunne oprettes, og ligeledes, hvis en film skal køre i flere sale på samme tid, er der tale om flere shows. En Hall har en 1 til mange relation til Row, da man ikke kan have en sal uden rækker. Endvidere har Row en 1 til mange relation til sæder. Her gælder samme argument: Det er ikke muligt at oprette en række uden sæder. Hvis der skal oprettes gange i salen, vil dette være en række sæder, med et særligt flag, der fortæller at det er tomme sæder. 1.1 Design valg Intro + Her skal vi nu nok have skrevet lidt mere? Relationen mellem Reservation og Price er lavet da det vil gøre det muligt at kunne håndtere forskellige pris niveauer (Premiere/Normale, Voksen/Barn... ). 1.1.1 User Denne klasse var ment som en superklasse, der alt efter Role skulle bruges til at instantiere forskellige roller af en bruger. Dette blev dog ikke gjort da vi valgte at gå men en klasse, hvor de forskellige attributter var med i. Følgende værdier bruges: Rolle Værdi Admin 1337 Clerk 2000 User 3000 Tabel 1.1: Rolle intervaller 2
KAPITEL 1. DOMÆNE Figur 1.1: Domæne model 3
KAPITEL 1. DOMÆNE 1.2 Database Databasen er lavet med udgangspunkt i domænemodellen og kan ses i figur 1.2. Det vil ud fra et bruger ID være muligt at lave et opslag i Reservation tabellen og finde alle reservationer fra denne bruger. Ud fra Reservation.Id er det mulig at arbejde sig igennem hele databasen, og dermed få de reelle informationer. Måden dette foregår på, er at via HasSeats kan der findes Seat TRow Hall Show Movie. Denne opbygning er lavet for at sikre, at Én bruger kan have mange reservationer. En reservation kan have flere sæder. En film kan køre på forskellige tider, i samme sal, eller på samme tid, i forskellige sale. En sal kan have varierende antal rækker, der kan have forskellige antal sæder. 1.2.1 Tredje Normal Form (3NF) 4
KAPITEL 1. DOMÆNE Figur 1.2: Database170 5
KAPITEL 1. DOMÆNE 1.3 Klassediagran Klassediagrammet for vores data tier kan ses i figur 1.3. Main klassen (skal nok omdøbes?) står for selve kontrollen af laget. Det er denne brugeren kommunikere med gennem UI et. Herfra er det muligt at instantiere 4 klasser, og gemme dem i lister. Det meste af funktionaliteten er lagt ud på de forskellige klasser, og hvert kald har returntypen string. Det er her meningen at de forskellige kald skal retunere en string med SQL (eksempel ses i listing 1.1) der bliver sendt videre til serven, der eksekvere koden, og sender et resultat tilbage. Et eksempel på dette, kan ses i Listing 1.2. 1 Users.editName(string fname, string lname) 2 { 3 String SQL; 4 if (fname!= null && lname == null) 5 { 6 SQL = "UPDATE Users SET fname = "+fname+" WHERE Id = " + id+";"; 7 } 8... 9 return SQL; 10 } Listing 1.1: Eksempel på generering af SQL (User klassen) 1 String editdescripsql = Movie.editDescp("New description"); 2 int result = executesql(editdescripsql); 3 if (result == 1) 4 { 5 Console.WriteLine("Success!"); 6 } 7 else 8 { 9 Console.WriteLine("Some error"); 10 } Listing 1.2: Kald til Movie.editDescrip(string newdescrip) De fire lister i Main klassen (halls, movies, shows, users) står for håndteringen af de forskellige objekter i systemet. Main.addMovie(...) vil både håndtere oprettelse af en ny film, indsættelse i listen og generering af SQL, som set i listing 1.3 1 Main.addNewMovie(args) 2 { 3 Movie m = new Movie(args); 4 String SQL = "SQL"; 5 int result = executesql(sql); 6 if (result == 1) 7 { 8 movies.add(m); 9 } 10 else 11 { 12 Console.WriteLine("Something fishy happened :-\("); 13 } 14 } Listing 1.3: Tilføj ny film 6
7 KAPITEL 1. DOMÆNE
KAPITEL 1. DOMÆNE 1.4 Arkitektur 3-tier arkitekturen er valgt til dette projekt. Denne arkitektur adskiller brugeren (præsentationstier) fra direkte kontakt med den bagved liggende database (data-tier), via et mellemled (logictier) der står for alt udregning om manipulation af data. At have et data-tier medvirker også øget skalerbarhed og ydeevne[1]. 8
KAPITEL 2 SERBIO Serveren, Serbio, er opbygget efter 3-lags pricippet, og indeholder et service library, en host process, og et bussiness logic lag. Alt kommunikation går gennem library et, som et bootstrapped via Servide host, og kalder bussiness logic s funktioner for at lave udregningerne. Serbio er lavet således at så meget beregning som muligt ligger her. Dette betyder at klienterne kan være letvægtede, da det eneste de skal håndtere er diverse kald og grafisk repræsentation af data. 2.1 Kommunikation Kommunikationen mellem server og (mulige) klienter foregår via WCF 4.5, der er et framework til.net 4.5. Serveren sender XML data via SOAP protokollen, der gør at klientent kan implementeres cross-platform, et eksempel på dette kan ses i listing 2.1(request) og listing 2.2 (response). A-B-C Konfigurationen følger ABC opsætningen af WCF (Address, Binding, Contract). I denne sektion vil de forskellige dele blive beskrevet. Address Addressen er ip en på serveren, sammen med en port. Serbio kører på port 9753. 1 <host> 2 <baseaddresses> 3 <add baseaddress = "http://localhost:9753/" /> 4 </baseaddresses> 5 </host> Binding Serbio bruger basichttpbinding. Denne protokol giver i modsætning til nettcpbinding mulighed for platformfrie klienter, dog med den pris, at der bliver sendt mere data. Vi har valgt at prioritere fleksibilitet over hastighed ved at bruge HTTPBinding fremfor nettcpbinding. Valget er faldet på dette, da c# ikke er det mest brugte sprog 1, og ved at vælge en platformfri protokol, vil det også 1 Kilde: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html 9
KAPITEL 2. SERBIO 1 <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> 2 <s:header> 3 <Action s:mustunderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none ">http://tempuri.org/iserbiooperations/connect</action> 4 </s:header> 5 <s:body> 6 <Connect xmlns="http://tempuri.org/"> 7 <username>kirs</username> 8 <password>9000</password> 9 </Connect> 10 </s:body> 11 </s:envelope> Listing 2.1: Request 1 <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> 2 <s:header /> 3 <s:body> 4 <ConnectResponse xmlns="http://tempuri.org/"> 5 <ConnectResult xmlns:a="http://schemas.datacontract.org/2004/07/serbiobussinesslogic.dto" xmlns:i="http://www.w3.org/2001/xmlschema-instance"> 6 <a:id>3</a:id> 7 <a:password>9000</a:password> 8 <a:role>1337</a:role> 9 <a:token>kirs@rksy8s12kcedetypypax</a:token> 10 <a:username>kirs</a:username> 11 </ConnectResult> 12 </ConnectResponse> 13 </s:body> 14 </s:envelope> Listing 2.2: Response 10
KAPITEL 2. SERBIO være muligt at forholdsvist nemt implementere løsninger på ekstempeltvist Android eller iphone. Endvidere giver basichttpbinding ingen problemer med hverken Nat s eller firewalls. Ccontract Serbio har en masse contracts, et lille udsnit er: BookSeats(...),AddReservation(...) og GetAllReservationsForUser(...). Alle disse er stillet tilrådighed gennem interfacet ISerbioOperations. 2.1.1 Bruger authentificering baischttpbinding indeholder ikke mulighed for sessionstyring per default. Derfor er det nødvendigt at implementere vores egen løsning til dette. Vores primære grund til at skulle bruge sessionstyring er, at det skal være muligt at invalidere reservationer hvis de overskrider en prædefineret tid (i vores system, kan billetter holdes i 10 minutter - hvis de ikke er blevet reserveret efter dette, vil det være muligt for andre at vælge dem). Connect Når en klient skal logge ind, sker dette ved at kalde.connect(string username, string password). Herefter vil serveren checke om det er korrekt bruger og kodeord. Er dette tilfældet, vil serveren tildele brugeren en Token og sende en UserDTO objekt tilbage til klienten. Dette objekt skal bruges til senere kommunikation der kræver brugervalidering. Hvis ikke brugeren kan autentificeres, kastes en exception tilbage til klienten. Purger Purger er vores sessionshåndtering. Dette bliver kørt i sin egen tråd, med et interval på 500ms. Hver gang Purger ticker, vil den se om der er brugere der ikke har været aktive i over 10 minutter. Hvis dette er tilfældet, vil deres token blive fjernet og de vil blive fjernet fra listen af authentificerede brugere. Dermed vil det kræve et nyt.connect(...) før brugeren kan foretage sig ting i systemet, der kræver autentificering. Purger står også få invalidering af sæde reservationer. Koden for dette kan ses i 2.3. Det hele er pakket ind i et TransactionScope, dette vil vi forklare nærmere i sektion 2.3.2, for at sikre consistency. 1 foreach (Reservation res in context.reservation.tolist()) 2 { 3 if (res.resercationtime.addminutes(ttl) < DateTime.Now && res.paid == false) 4 { 5 logger.info("removing reservation " + res.id + " due to session timeout"); 6 context.hasseats.first(s => s.idseat == res.seats).seatstate = 0; 7 context.reservation.remove(res); 8 context.savechanges(); 9 } 10 } Listing 2.3: PurgeReservations invalidering af for gamle reservationer 2.1.2 Exceptions Hvis en klient foretager en handling, der af en eller anden grund ikke går godt, vil der blive kastet en exception tilbage. Dette sker gennem throw new FaultException<Exception> som er WCFs måde at kaste exceptions til klienten på. Følgende exceptions kan blive kastet fra serven: 11
KAPITEL 2. SERBIO DatabaseOfflineException Denne kastet, hvis serveren ikke kan få kontakt til databasen. Dette er en fatal error. DuplicationFoundException Denne kastes, hvis der forsøges at indsættes duplikater af data i databasen. NoShowsException Denne kastes, hvis der ikke er nogle shows is databasen. SeatAlreadyReservedException Denne kastes, hvis der forsøges at reserveres et sæde, der allerede er reserveret. UserLoginException Denne kastes ved forkert login. UserRightsException Denne kastes, hvis en bruger forsøger ting, han ikke har rettigheder til. Excpetions bliver kastet med 2 typer af beskeder: En inner og en outer. Outer message er den, der bliver vist, hvis der ikke er blevet implementeret en try/catch; her vil der blive vist, hvilekn type exception det er, efterfulgt at fejlmeddelelsen. Dette er gjort, så udvikleren nemt kan implementere en catch til den specifikke exception. Inner message, er det der vil blive vist, hvis udvikleren direkte printer på ex.message, som bliver sat i serveren, som i 2.4 1 throw new UserRightsException("User not authorized to action GetMovies()"); Listing 2.4: Eksempel på exception Grunden til dette er, at en udvikler skal have nemt ved at finde ud at, hvad der går galt, hvis(når) noget går galt. 2.2 Database For at få serveren til at hente og skrive data til databasen, er der flere muligheder der kan vælges. I denne sektion sammenligner vi ADO.net og Entity Framework (som er en Object-Relational mapper), for at finde den bedst egnede løsning. Analysen, der ses i tabel 2.1 er belvet lavet, ved at sammenligne flere forskellige aspekter 2 ved at give hver mulig en score på 1-5 (hvor 5 er bedst) og en vægt, der beskriver hvor vigtigt vi vurdere resultatet i forhold til vores produkt. Vi har valgt at bruge Entity Frameworket, da den score højest totalt, med de vægte vi har vurderert til at være til vores produkt. 2.2.1 Entity Framework I denne sektion vil vi give eksempler på, hvordan Entity Frameworket virker. Vi vil opstille nogle cases, og sammenligne, hvordan SQL koden skulle have set ud. Case 1 Find alle brugere af systemet. 2 Kilder: http://stackoverflow.com/questions/15264983/entity-framework-objectcontext-share-pros-and-cons http://noamlewis.wordpress.com/2012/07/18/net-4-5-improves-orm-performance-across-the-chart/ http://blogs.msdn.com/b/adonet/archive/2012/02/14/sneak-preview-entity-framework-5-0-performanceimprovements.aspx 12
KAPITEL 2. SERBIO EF ADO Vægt Vægtet EF Vægtet ADO Hurtighed 1 5 4 4 20 Vedligeholdelse 5 1 2 10 2 Concurrency* 5 3 5 25 15 Readability 4 2 2 8 4 DB Specific** 5 1 1 5 1 Writeability 5 1 3 15 3 Productivity 5 1 3 15 3 Sum 82 48 Tabel 2.1: Sammenligning mellem EF og ADO *) Her menes, hvor nemt forskellige typer af concurrency er at implementere **) Her menes, hvor nemt det ville være at skifte fra eksempeltvist SQL Server til Windows Azure SQL Database. 1 using (var context = new dmaa0212a_3entities) 2 { 3 List<Users> users = context.users.tolist(); 4 } 1 using (var context = new dmaa0212a_3entities) 2 { 3 Select * from Users 4 } Listing 2.5: Entity kode til Case 1 Listing 2.6: SQL kode til Case 1 Case 2 Find alle reservationer for brugere med id nummer 1, og print titlen på filmen 1 using (var context = new dmaa0212a_3entities()) 2 { 3 var res = context.reservation.where(r => r.userid == 1); 4 foreach (var reservation in res) 5 { 6 Console.WriteLine(context.Show.First(s=>s.ID==reservation.Show).Movie1.Title); 7 } 8 } Listing 2.7: Entity kode til Case 2 1 SELECT Movie.Title 2 FROM Reservation 3 Inner join Users on Users.Id = Reservation.UserID 4 INNER JOIN Movie on Reservation.Show = Movie.ID 5 where Reservation.UserID = 1 Listing 2.8: SQL kode til Case 2 I 2.5 og 2.6 er der ikke den store forskel på at bruge SQL eller Entity Frameworket. Forskellen bliver dog mere tydelig i 2.7 og 2.7, hvor førstnævnte tydeligt er mindre komplekst at læse. 13
KAPITEL 2. SERBIO 2.3 Booking En af de vigtigste dele af systemet, er håndteringen af sædebooking. Her skal tages højde for consistency i systemet, samtidig med, at der skal implementeres en algoritme der fungere korrekt. I de følgende sektioner vil vi beskrive vores implementation af booking hvordan vi har håndteret consistency og en analyse af algoritmen til at vælge sæder. 2.3.1 Sædevalg Målet for sædevalg i vores system er: Concurrency Der må ikke kunne dobbeltbookes sæder Concurrency Sæder bookes efter først-til-mølle-princippet Concurrency Der må ikke kunne spærres sæder i for lang tid Concurrency Sæder skal bookes efter alt-eller-intet princippet Algoritme Sæder skal bookes efter alt-eller-intet princippet Algoritme Der skal foreslås de bedste sæder først Algoritme Der skal vælges de sæder, der forventes bliver valgt Algoritme Det skal være mulig at ændre sædevalg, indtil sæderne bliver markeret som booked 2.3.2 Concurrency Da vi har valgt at bruge Entity Framework, vil det være smart, at bruge én af de måder EF stiller til rådighed, til locking af databasen. Følgende metoder er mulige 3 Serializable Volatile data can be read but not modified, and no new data can be added during the transaction. RepeatableRead Volatile data can be read but not modified during the transaction. New data can be added during the transaction. ReadCommitted Volatile data cannot be read during the transaction, but can be modified. ReadUncommitted Volatile data can be read and modified during the transaction. Snapshot Volatile data can be read. Before a transaction modifies data, it verifies if another transaction has changed the data after it was initially read. If the data has been updated, an error is raised. This allows a transaction to get to the previously committed value of the data. When you try to promote a transaction that was created with this isolation level, an InvalidOperationException is thrown with the error message Transactions with IsolationLevel Snapshot cannot be promoted. Chaos The pending changes from more highly isolated transactions cannot be overwritten. 3 Kilde: http://msdn.microsoft.com/en-us/library/system.transactions.isolationlevel.aspx 14
KAPITEL 2. SERBIO Unspecified A different isolation level than the one specified is being used, but the level cannot be determined. An exception is thrown if this value is set. Der er flere af disse, der allerede ved første øjekast kan forkastes, da de ikke opfylder kravene til vore system. Disse er: ReadCommitted, da vi ikke kan læse data, og dermed finde nuværenede state på sæder. Chaos, det ligger lidt i navnet det er svært at vide hvem der får lov til hvad hvis der er flere transactions i gang. Unspecified, dette er ikke interessant, da vi selv specificere hvilke isolations niveau der skal bruges. Dette efterlader: Serilizable, RepeatableRead, ReadUncomitted og Snapshot. I tabel 2.2 4 ses en oversigt over de resterende muligheder side effects. Isolation level Dirty read Nonrepeatable data Phantoms Read uncommitted Yes Yes Yes Repeatable Read No No Yes Snapshot No No No Serializable No No No Tabel 2.2: Isolations niveauer Følgende er en forklaring på de forskellige attributter fra?? 5 Dirty read vil sige, at der læses data, der ikke er blevet comitted til databasen endnu. Eksempel: Transation1 (T1) opdatere en række. Transation2 (T2) læser den opdaterede række, før T1 comitter updaten. Hvis T1 laver et rollback, vil T2 stadig have læst en værdi, der anses som ikke eksisterende. Nonrepeatable Reads vil sige, at den samme række læses flere gange, men med forskellig data hver gang. Eksempel: T1 læser en række. T2 updatere eller sletter den række, og comitter. Hvis T1 læser rækken igen, vil den enten få en anden værdi, eller finde ud af, at rækken er slettet. Phantoms vil sige, at en række matcher nogle søge kriterier, men er ikke set med det samme. Eksempel: T1 læser nogle rækker, der opfylder et søge krav. T2 generere en ny række, der passer T1s søgekriterier. Hvis T1 eksekvere den samme søgning igen, vil der findes en anden sæt af rækker. Snapshot I vores system vil dirty read ikke være ønskeligt, da dette kan medføre, at state på sæder ikke kan regnes med. Endvidere er nonrepeatable read heller ikke ønskeligt, da dette kan medføre fejllæsninger. Dette efterlader Snapshot og Serilizable som muligheder. Forskellen på Snapshot og Serilizable, er at den første er optimistic og den sidste er pessimistic concurrency. Forskellen på de to niveauer er 6 : Serializable isolation level relies on pessimistic concurrency control. It guarantees consistency by assuming that two transactions might try to update the same data and uses locks to ensure that they do not but at a cost of reduced concurrency - one transaction must wait for the other to complete and two transactions can deadlock. 4 http://msdn.microsoft.com/en-us/library/ms189122.aspx 5 Kilde: http://msdn.microsoft.com/en-us/library/windows/desktop/ms709374(v=vs.85).aspx 6 http://blogs.msdn.com/b/craigfr/archive/2007/05/16/serializable-vs-snapshot-isolation-level.aspx 15
KAPITEL 2. SERBIO Snapshot isolation level relies on optimistic concurrency control. It allows transactions to proceed without locks and with maximum concurrency, but may need to fail and rollback a transaction if two transactions attempt to modify the same data at the same time. Vi har valgt at bruge snapshot da dette løser opgaven med concurrency, og samtidig fjerne risikoen for deadlocks. Granularitet Granularitet er hvor finkornet vores locking af databasen er. Jo finere granularitet desto mindre locking. I et biograf booking system, er der flere muligheder for at låse. Disse går fra at låse et helt show (Meget grov granularitet) til kun at låse et enkelt sæde (Meget fin granularitet). Det er et tradeoff på, hvor meget locking man ønsker i sit system. Da vi i Serbio bruger Snapshot locking, er det ikke nødvendigt at få den helt fine granularitet i form af lås af enkelt sæder. Men den meget grove granularitet er stadig heller ikke at ønske. Vi har valgt at lække vores lås på sæder (alle sæder). Dette kan give problemer, hvis der bruges en pessemistic locking, da dette vil medføre at T ( n) er nød til at vente på T ( n 1)...T ( 1). Dette er ikke ønskeligt, da det vil give alt for meget ventetid. Men, da vi bruger en optimictic locking, er dette ikke problemet, da alle kan få lov at booke på samme tid, og kun hvis der opstår dobbeltbooking vil systemet melde fejl. Test Følgende test er blevet opstiller, og kørt, for at checke concurrency i vore system. 2.3.3 Algoritme Der er blevet udarbejdet en algortime til valg af sæder. I denne sektion besrkiver vi algortimen, analysere køretid og kommer med foreslag til forbedringer. Sædevalgsalgoritme 16
KAPITEL 2. SERBIO Test 1 Forventet resultat Faktisk resultat Èn klient. Èn booking OK OK Test 2 To klienter. Èn booking K1 OK OK K2 Fejl Fejl Test 3 To klienter. To booking K1 OK OK K2 OK OK Test 4 Mange Klienter, mange bookin K1 OK OK K2 OK OK... K ( n) OK OK Test 5 Mange Klienter, èn bookin K1 OK OK K2 Fejl Fejl... K ( n) Fejl Fejl Tabel 2.3: Test af concurrency 17
KAPITEL 2. SERBIO Data: Number of seats to reserve, Number of startseat Result: A list of seatsto reserve. Error if out of bounds f1; fslut; List seatstoreserve; if numberofseats = 2 then f1 = startseat fslut = startseat + numberofseats -1; else f1 = (startseta - (numberofseats/2)); if numberofseats % 2 == 0 then fslut = startseat + (numberofseats/2) - 1; else fslut = startseat + (numberofseats/2); end end int rowmaxint = Index of the last seat on selected row; int minrowseat = Index of the first seat on selected row; if fslut > rowmaxint then fslut = rowmaxint; f1 = fslut - numberofseats + 1; end if f1 < minrowseat then f1 = minrowseat; fslut = f1 + numberofseats - 1; end if fslut > rowmaxint then Return out of bounds error end for i=f1; i<fslut; i++ do Add each seat with id 1 to seatstoreserve end Algorithm 1: Generering af sæder til at reservere Data: List of seats to reserve Result: A list of seats reserved in the system. Error if concurrency conflict for each seat in the list do Check if seats is already reserved; if seat is reserved then return error else mark seat as reserved end end if Error then Rollback database else Commit changes to database end Algorithm 2: Reservering af sæder 18
KAPITEL 3 CLIENT 3.1 GUI GUI Når vi kigger på GUI, vidste vi godt at det ikke var det der skulle fokuseres på fra starten. Men som vores projekt skred frem, fandt vi ud af at ved at lave GUI ville vi kunne få et bedre produkt. Nu havde vi besluttet at lave en GUI og så kom diskutionen hvordan skulle vi lave denne GUI. Valget endte med at stå mellem Winforms og WPF. Winforms denne API, er udviklet af Microsoft, og er en af de første måder at lave nemme og hurtige grafiske opsætninger i.net. Fordele: Det er meget nemt og meget hurtigt, at få lavet noget der nogenlunde ligner det du vil have. Det virker godt i Windows. Ulemper: Det er svært at få alt, til at være helt som du vil have det til at se ud ved hjælp af drag and drop. Det er svært at få til at virke på andre platforme som fx Android,iOS og som web. WPF Udviklet af Microsoft, Windows Presentation Foundation (eller WPF), og er den nyeste måde at lave grafiske opsætninger i.net. Fordele: Det er muligt at få alle ting, til at ligge som de skal ved hjælp af xaml men også muligt at drag and drop. Det er muligt at få denne GUI til at virke på de fleste andre platforme som fx Android,iOS og som web. Ulemper: Det er på baggrund af dette, at vi har valgt bruge WPF, det krævede godt nok lidt mere tid at sætte op end Winforms, men med WPF vil vi nemt kunne scalere vores GUI til web, vi vil også nemt kunne lave apps. 19
KAPITEL 3. CLIENT 3.1.1 Eksempler 20
KAPITEL 4 KONKLUSION 21
LITTERATUR [1] Wikipedia the free encyclopedia. Multitier architecture. http://en.wikipedia.org/wiki/ Domain_model, 2013. [Online; accessed 27-March-2013]. 22