One Backend, Different Clients
ervang deze tekst door eengrafische illus het p
Joeri Goeyvaerts & Glenn Delahaye voor het behalen van de graad van Bachelor in de New Media and Communication Technology Academiejaar 2013-2014 Stageplaats : RealDolmen Stagementor : Alexander Reynaert Stagebegeleider : Henk Bostyn
One Backend, Different Clients Joeri Goeyvaerts & Glenn Delahaye
Woord vooraf Volgend werkstuk moet een beeld geven aan de lezer hoe we een backend kunnen opzetten in de cloud. Eveneens verschillende applicaties schrijven die van deze opzet gebruik kunnen maken ongeacht hun platform. Dit stuk werd geschreven door Glenn Delahaye en Joeri Goeyvaerts, beide studenten volgen een opleiding aan de Hogeschool West-Vlaanderen te Kortrijk in de richting New Media and Communication Technology. Graag zouden we onze stagementor Alexander Reynaert en onze stagebegeleider Henk Bostyn willen bedanken voor hun tips en adviezen omtrent de stageopdracht. Ook een dank aan de RealDolmen collega’s die ons geholpen hebben met dit project.
I
Verklarende Woordenlijst API Backend
Cloud
Data Access Layer (DAL) Data transfer object (DTO) Dependecy Injection Inversion of control(IoC) Lambda's LINQ Separation Of Concerns (SOC) Single Page Application (SPA)
II
Application programming interface: vormt vaak de abstractie tussen lagen en kan aangesproken worden door andere software Achterliggende laag onzichtbaar voor de eindgebruiker, de front-end van een applicatie zal hier gebruik van gaan maken. Een backend zal meestal bestaan uit API’s Een netwerk van hardware waarvan de eindgebruiker niet weet waar de software wordt uitgevoerd, een cloud toepassing is zowel veilig, performant en schaalbaar in gebruik. Gemakkelijkere toegang tot data Hierbij wordt alle onnodige data die de gebruiker niet nodig heeft eruit gefilterd en enkel de nodige data ingevuld en doorgestuurd. Injecteren van dependencies, zorgt voor loosely coupled Vermijdt afhankelijkheid in code door injectie van interfaces Anonieme functie (functie schrijven dat als parameter wordt door gegeven Query’s schrijven in .Net Is een design principe om verschillende onderdelen van een programma te scheiden. Zodat men deze terug kan hergebruiken of snel en gemakkelijk kan aanpassen. Single Page Application is een applicatie die altijd en volledig op één pagina wordt weergegeven
Afkortingen API
Application Programming interface
BL
Business Logic
CC
Customer Case
DAL
Data Access Layer
DI
Dependency Injection
EF
EntityFramework
IoC
Inversion of Control
LINQ
Language-Integrated Query
MVC
Model-View-Controller
MVVM
Model-View-ViewModel
PCL
Portable Class Library
RD
RealDolmen
RT
Runtime
SoC
Seperation of Concerns
SSL
Secured Socket Layer
Win
Windows
WP
Windows Phone
III
Inhoudsopgave WOORD VOORAF ..................................................................................................................................................... I VERKLARENDE WOORDENLIJST .............................................................................................................................. II AFKORTINGEN ....................................................................................................................................................... III INHOUDSOPGAVE.................................................................................................................................................. IV 1
INLEIDING ........................................................................................................................................................ 1
2
OPZET BACKEND: WEB API EN DATABASE ........................................................................................................ 2 2.1 WEB API .................................................................................................................................................. 2 2.1.1 Opzet............................................................................................................................................... 2 2.1.2 Model .............................................................................................................................................. 3 2.2 ENTITYFRAMEWORK .................................................................................................................................... 5 2.2.1 NuGet Package ............................................................................................................................... 5 2.2.2 Database in Azure ........................................................................................................................... 7 2.2.3 Code First ........................................................................................................................................ 8 2.3 REPOSITORIES .......................................................................................................................................... 11 2.3.1 Interfaces ...................................................................................................................................... 11 2.3.2 Repositories .................................................................................................................................. 11 2.3.3 AutoFac ......................................................................................................................................... 12 2.4 CONTROLLERS .......................................................................................................................................... 13 2.5 SECURITY ................................................................................................................................................ 16 2.5.1 Secure Sockets Layer ..................................................................................................................... 16 2.5.2 API Keys ........................................................................................................................................ 17 2.6 DATA TRANSFER OBJECTS........................................................................................................................... 17
3
FRONT-END: SINGLE PAGE APPLICATION ....................................................................................................... 19 3.1 DEFINITIE SPA ......................................................................................................................................... 19 3.2 OPZET SPA ............................................................................................................................................. 19 3.2.1 Aanmaken SPA.............................................................................................................................. 19 3.3 DESIGN WEBSITE ...................................................................................................................................... 19 3.3.1 Gebruikte technologieën............................................................................................................... 19 3.4 GEBRUIKTE PATRONEN .............................................................................................................................. 20 3.4.1 Separation of Concerns ................................................................................................................. 20 3.4.2 Model-View-ViewModel-Structuur ............................................................................................... 20 3.5 DOEL VAN SPA ........................................................................................................................................ 21 3.6 OPBOUW SPA ......................................................................................................................................... 21 3.7 RESULTAAT .............................................................................................................................................. 24
4
FRONT-END: ASP.NET APPLICATION .............................................................................................................. 27 4.1 OPZET ASP.NET APPLICATION ................................................................................................................... 27 4.1.1 Aanmaken ASP.NET Application ................................................................................................... 27 4.2 DESIGN WEBSITE ...................................................................................................................................... 27 4.2.1 Gebruikte Technologieën .............................................................................................................. 27 4.3 GEBRUIKTE PATRONEN ............................................................................................................................... 29 4.3.1 Model-View-Controller-structuur ................................................................................................. 29
IV
4.4 DOEL INTERNE WEBSITE.............................................................................................................................. 30 4.5 OPBOUW ASP.NET APPLICATION ............................................................................................................... 30 4.5.1 AutoFac configureren ................................................................................................................... 30 4.5.2 Controllers aanmaken................................................................................................................... 30 4.5.3 Views aanleveren van data ........................................................................................................... 33 4.6 RESULTAAT .............................................................................................................................................. 39 5
NATIVE CLIENTS ............................................................................................................................................. 43 5.1 WINDOWS 8.1......................................................................................................................................... 43 5.1.1 Opzet............................................................................................................................................. 43 5.1.2 Model ............................................................................................................................................ 44 5.1.3 ViewModel .................................................................................................................................... 45 5.1.4 View .............................................................................................................................................. 47 5.1.5 Koppeling ViewModels ................................................................................................................. 50 5.1.6 Databinding .................................................................................................................................. 53 5.1.7 Resultaat ....................................................................................................................................... 55 5.2 WINDOWS PHONE 8 ................................................................................................................................. 56 5.2.1 View .............................................................................................................................................. 56 5.2.2 ViewModel .................................................................................................................................... 57 5.2.3 Koppeling ViewModels ................................................................................................................. 57 5.2.4 Resultaat ....................................................................................................................................... 57 5.3 UNIVERSAL APPS (WINDOWS 8.1 EN WINDOWS PHONE 8) .............................................................................. 58
CONCLUSIE ........................................................................................................................................................... 59 JOERI ................................................................................................................................................................ 59 GLENN .............................................................................................................................................................. 59 LITERATUURLIJST .................................................................................................................................................. 60 FIGURENLIJST ....................................................................................................................................................... 61 BIJLAGEN .............................................................................................................................................................. 64 BIJLAGE 1: INFORMATIE STAGE ............................................................................................................................... 64 BIJLAGE 2: FUNCTIONELE ANALYSE ......................................................................................................................... 66 BIJLAGE 3: ARCHITECTUUR WEB PROJECT ................................................................................................................ 80 BIJLAGE 4: CODE VOORBEELDEN CLIENT................................................................................................................... 86 BIJLAGE 5: ARCHITECTUUR CLIENT PROJECT .............................................................................................................. 92 BIJLAGE 6: MOCKUPS......................................................................................................................................... 100
V
1 Inleiding De onderzoeksvraag gaat over “One backend, different clients”, dat wil zeggen één backend (API) en meerdere clients. Het is de bedoeling om een backend op te zetten die door zo veel mogelijk (platform) onafhankelijke applicaties kan geconsumeerd worden. De verschillende clients binnen RealDolmen bestaan uit volgende platformen, een externe website (Single Page Application), een interne website(Model-View-Controller), een Windows 8.1 applicatie en een Windows Phone 8 applicatie. De clients kunnen nog verder uitgebreid worden naar Android, IOS en verschillende andere platformen. In het document wordt uitgebreid vertelt hoe een best practice wordt toegepast om een dergelijk project op te zetten van backend tot applicatie. Omdat de stage verliep onder de Microsoft divisie is de gekozen technologie vooral gebaseerd op .Net. Het project beschreven in de cursus dient enkel als leidraad voor de uitleg, het is niet de bedoeling om enkel te beperken tot het door RealDolmen beschreven Customer Cases Project. Er zullen dus enkele verwijzingen gebeuren naar het project maar de opzet van het project is een universele methode om zo’n project op te bouwen. De verschillende platformen tonen aan dat zowel RealDolmen als hun werknemers in staat zijn om voor verschillende platformen te kunnen ontwikkelen. Tevens is dit voor RealDolmen ook een buitenkans om via deze weg klanten te overtuigen om van deze platformen gebruik te maken. Technologieën zoals Knockout, Javascript, Jquery, ASP.NET MVC 5, Entity Framework 6 (EF), C#, HTML5, CSS3, AutoFac kwamen in dit project allemaal tezamen. Knockout, Javascript, Jquery, HTML5, CSS3, ASP.NET werden zowel in de Interne als in de Externe website gebruikt. De overige technologieën werden vooral gebruikt in de Windows 8.1 en de Windows Phone 8 applicatie. AutoFac en EF werden toegepast voor de opzet van de Web API. Voor de opzet van het project werd gebruik gemaakt van een functionele analyse (zie bijlage). De functionele analyse werd voor dit project opgesteld door analist Alec van der Heyden van RealDolmen. Alsook zijn er verschillende schema’s gemaakt voor de structuur van de database en het project. De doelgroep van de bachelorproef is vooral gericht naar developers die enkele jaren ervaring hebben met .Net technologieën of studenten die zich willen verdiepen in .Net met specialisatie voor backend en front-end development. De opzet ziet er als volg uit: 1. Opzet van een restful Web API die zal dienen als backend 2. Opzet van een Single Page Application(SPA), een web applicatie die de data van de Web API zal gebruiken. 3. Opzet van een intern MVC project, dit werkt hetzelfde als een SPA maar zal geen gebruik maken van de Web API maar via de repositories naar de database. 4. Opzet van een Windows 8.1 applicatie en een Windows Phone 8 applicatie, hier zal tevens data verwerkt worden die van de Web API afkomstig is. Er zijn nog tal van andere clients(bv: iOS, Android, Tizen, …) die op dezelfde manier kunnen gebruik maken van de Web API maar die vallen buiten de scope van dit werkstuk. 1
2 Opzet backend: Web API en database De backend is een restful Web API opgebouwd in ASP.NET. Een Web API zorgt ervoor dat een client applicatie hetzij web of native beroep kan doen op data. De keuze voor ASP ligt erin dat de Web API zal gehost worden vanuit een Azure cloud omgeving. De integratie tussen beide platformen werkt zeer efficiënt samen met TFS en Visual Studio. Voor de achterliggende database die tevens in de Azure cloud plaatsvindt, is gekozen voor een SQL database waar er gebruik gemaakt wordt van het EntityFramework(EF). EF neemt heel wat database gerelateerde zaken op zich voor de opbouw ervan, dit gebeurt aan de hand van de ‘code first’ implementatie. Code first bouwt een tabelstructuur op aan de hand van het model. Hierdoor kan de programmeur veel zaken logisch op voorhand opbouwen.
2.1 Web API
Figuur 1 Overzicht Web API project
2.1.1 Opzet Voor het aanmaken van het API project kan er in Visual Studio standaard gekozen worden voor een Web API project. Dit zal een web project starten met bijhorende template. De structuur van een Web API heeft ongeveer dezelfde opbouw als die van een MVC project het verschil hierin ligt bij de controllers. Bij een Web API project zullen deze controllers mits hun security level het toelaten, van buiten af aangesproken te kunnen worden doormiddel van https requests. Enkele voorbeelden van zo’n requests zijn: GET, POST, PUT en DELETE. In Visual Studio is het “ASP.NET Web Application” project te vinden onder de Web sectie (voor een globaal overzicht zie “Architectuur Document”).
2
Figuur 2 Wizard aanmaken API project De instellingen mogen standaard gehouden worden. Indien Visual Studio vraagt voor een koppeling te maken met Azure mag dit genegeerd worden, de connectie zal later tot stand gebracht worden.
2.1.2 Model Ten eerste zal er een basis model moeten opgebouwd worden. In het geval van RealDolmen zal het gaan over Customer Cases. Maak hiervoor een aparte class library aan zodat alles gescheiden blijft. Het model zal moeten voldoen aan bepaalde voorwaarden om het later met EntityFramework makkelijk te kunnen omzetten naar tabellen in de database. Voordat het model gemaakt wordt, is het aangeraden om een ERschema op te stellen.
3
Figuur 3 ER diagram van de database
4
Op basis hiervan kan dan het model gemaakt worden. Elke tabel stelt een object voor en alle attributen binnen een tabel zullen een property gaan voorstellen. Indien er met relaties gewerkt wordt zal er bij een één op veel relatie een tabel zijn die aan de “één” kant een ID property heeft en een Object property aan de verwante tabel.
Figuur 4 Snippet relatie binnen model één op veel Bij veel op veel relaties zullen er in beide klasse een collectie te vinden zijn van het type ‘ICollection
’
Figuur 5 Snippet relatie binnen model veel op veel
2.2 EntityFramework 2.2.1 NuGet Package EntityFramework zit nog niet standaard in het project, dit zal eerst toegevoegd moeten worden via Nuget.
Figuur 6 NuGet package EntityFramework Na het toevoegen van de Nuget package zullen er twee aparte class library’s toegevoegd worden, repositories en repositories contracts. De eerste library zal de data access layer(DAL) logica bevatten, ook zal hier EF toegevoegd moeten worden. Het tweede project bevat interfaces. Vanuit de Web API ligt er een referentie naar beide projecten.
5
Figuur 7 Project setup repositories In het repository project wordt een klasse toegevoegd ervend van DbContext. De context klasse is de communicatie naar de database en zal de mapping verzorgen voor het aanmaken van de tabellen. In het voorbeeld van de RealDolmen Customer Cases zal de context CustomerCaseDbContext noemen. Voor elk model in de model library moet een tabel property gemaakt worden van het type DbSet<model>.
Figuur 8 Voor te stellen tabellen voor database Alle properties zijn in het meervoud, in de database is dit niet gewenst, volgende regel lost dit op: modelBuilder.Conventions.Remove();
EF weet echter nog niet helemaal of de relaties de gewenste vorm hebben. Indien dit zoals het er nu staat wordt gegenereerd zullen de namen van de eventuele tussentabellen niet naar wens zijn. Hiervoor kan er gebruik gemaakt worden van custom mappings. Dit laat de programmeur toe verschillende zaken zelf te controleren voor deze tabellen gegenereerd worden: 1. Naam (tussen)tabel 2. Kolomnamen 3. Cascade on delete (ervoor zorgen dat de data juist verwijdert) 4. Volgorde kolommen
6
Figuur 9 Mappen tussentabellen in code
2.2.2 Database in Azure Om een context te laten genereren zal er een locatie moeten aangeduid worden waar de database zich bevindt. In dit geval de cloud, meerbepaald de Azure cloud van Microsoft. De Azure cloud kan gratis gebruikt worden tot een bepaald volume, binnen RealDolmen kon er gebruik gemaakt worden van een betaalde licentie. Op https://manage.windowsazure.com/ kan er via een wizard een database aangemaakt worden.
Figuur 10 Wizard aanmaken database op Azure Indien er gekozen wordt voor “New SQL database server” zal er ook een gebruiker met wachtwoord moeten aangemaakt worden. Tevens zal er ook een regio gekozen worden. Het beste is een regio te kiezen die dicht bij het doelpubliek ligt. In dit geval zal dat Europa zijn. 7
Figuur 11 Wizard aanmaken user Azure Er kan nu vanuit de Web API een verbinding gelegd worden naar de cloud database. Omdat de Web API nog steeds lokaal staat en nog niet in de cloud zal er eerst een IP firewall rule moeten toegevoegd worden in het dashboard van de Azure portal. Zonder een firewall rule kan de database niet aangesproken worden van buitenaf. Dit zal niet meer nodig zijn als de Web API ook in de cloud gehost wordt. Wel zal dit nodig zijn als er via Visual Studio of SQL Server verbinding gemaakt wordt.
Figuur 12 Toelaten IP adres op Azure Op dit dashboard kan tevens de nodige connectionstring terug gevonden worden die nodig is voor de connectie van de Web API met de database. De connectionstring kan gekopieerd worden naar de Web.Config van het Web API project.
Figuur 13 Connectionstring naar Azure database Het is verplicht om als name de naam van de DbContext te gebruiken!
2.2.3 Code First Nu de database gekoppeld is en DbContext klaarstaat kan EF de database gaan genereren, hiervoor zullen er enkele console commando’s uitgevoerd moeten worden in de “Package manager console”. De console kan gevonden worden onder Tools – NuGet Package Manager – Package Manager Console.
8
Figuur 14 Package manager console Volgende commando’s dienen uitgevoerd te worden: Enable-Migrations o zal automatische migratie activeren Er zal een nieuwe map zichtbaar worden “Migrations” die bevat een klasse Configuration.cs, in de klasse Configuration is een Seed-methode te vinden. De Seed methode kan gebruikt worden om test data te genereren bij het initialiseren van de database.
Figuur 15 Snippet seed methode
Add-Migration Init o Zal een eerste migratie toevoegen, de naam aan het einde hoeft niet ‘Init’ te zijn.
Figuur 16 Code gegenereerd door EF voor het aanmaken van de database op Azure Indien alles in orde is kan het laatst nodige commando uitgevoerd worden dit zal de database creëren. Update-Database o Dit zal de laatst aangemaakte migratie construeren in de database 9
Figuur 17 Gegenereerde database op Azure Nu de database volledig opgezet is kan er data aangesproken worden. Dit gebeurt door middel van repositories.
10
2.3 Repositories 2.3.1 Interfaces Door gebruik te maken van interfaces kan alles loosely coupled geïmplementeerd worden, dit betekent dat er geen afhankelijkheid meer geldt tussen de lagen. In dit geval zal dat tussen Model(repositories) en de Controller(controllers) zijn. De interfaces bevatten de functies die nodig zijn voor data te verwerken binnen de database.
Figuur 18 Methodes van de repository interface Alle interfaces zijn terug te vinden in het Repositories.Contracts project.
2.3.2 Repositories Door de interface daarna te implementeren in de repositories kunnen de verschillende methodes aangemaakt worden. Voor dat er een connectie kan tot stand gebracht worden zal er een readonly field gemaakt worden in de klasse. Het type zal een DbContext zijn. DbContext zal de connectie naar de database verzorgen ook dit is loosely coupled aangezien DbContext niet weet over welke context het hier gaat. Later zal er een koppeling tot stand gebracht worden. Als de DbContext later verandert moet dit enkel op één plaats gebeuren.
Figuur 19 Get methode customer case repository
11
2.3.3 AutoFac Voor dat de controllers gebruik kunnen maken van de repositories moet er een koppeling gebeuren. Die koppeling zal gemaakt worden via AutoFac. AutoFac is een Inversion of Control (IoC) tool dat zorgt voor een generieke aanpak voor de koppeling tussen componenten. Om AutoFac te implementeren moet de NuGet van AutoFac geïnstalleerd worden in het Web API project en het Repositories project. In het Repository project komt een klasse RepositoryModule, die klasse zal de registratie van de interfaces doen samen met de Repositories zelf.
Figuur 20 Registratie repositories in AutoFac Daarna zal er in de Web API een registratie gebeuren van de DbContext via AutoFac, hiervoor zal er een AutoFacConfig klasse toegevoegd worden in de App_Start. Hier zal het nodige gebeuren om de CustomerCaseDbContext te koppelen met DbContext zonder dat repositories hier van afweten.
Figuur 21 AutoFac aan de config file toevoegen In Global.asax zal daarna nog de nodige aanspreking moeten gebeuren naar de config klasse. AutofacConfig.Register(GlobalConfiguration.Configuration);
12
Na het invullen van alle nodige registraties kan er gewerkt worden aan de controllers.
2.4 Controllers De controllers worden aangemaakt voor de verschillende calls naar de database via de repositories. De controllers die telkens aangemaakt worden, zijn Web API 2 Controllers met alle acties zoals read, write, edit en delete.
Figuur 22 Aanmaken controller via wizard Voor de code specifieker te maken dient er ook een Model klasse en een CustomerCaseDbContext aangeduidt te worden. Vergeet de controller name zeker en vast niet te veranderen naar enkelvoud (sectorcontroller zonder s).
13
Figuur 23 Specificeren controller Dit is een overzicht van een al aangepaste versie van een controller. De web API wordt alleen maar aangesproken vanaf de verschillende clients daarom dient er alleen maar een GET te gebeuren. Aangezien alle clients alleen maar objecten opvragen en geen objecten aanpassen dienen er alleen maar GET's te gebeuren.
Figuur 24 Overzicht controller code Aangezien er enkel via de repositories kan gesproken worden met de database dient er hier eerst een interfaces geïnitialiseerd te worden. Die interface zal een methode hebben die een functie zal uitvoeren die een call doet naar de database. AutoFac ziet zelf welke repository er gekoppeld is op die moment.
14
Figuur 25 DI via constructor Hier een specifieker voorbeeld van hoe een Get-methode eruit ziet. Elke Get-methode heeft ook een bepaalde route waarnaar verwezen kan worden. De route kan dan telkens aangesproken worden om data van de API op te halen. De Get-methode zorgt ervoor dat alle sectoren worden opgevraagd vanuit de database. De data wordt dan in een Data Transfer Object (DTO) gewrapped, dit gebeurt om geen overtollige data mee te sturen over het netwerk. Over dit onderwerp kan er gelezen worden in hoofdstuk “2.6 Data Transfer Objects”.
Figuur 26 Detail get API controller
15
2.5 Security De beveiliging van de web API zal uit twee delen bestaan, enerzijds een Secured Socket Layer(SSL) encryptie, zodat er enkel verbinding mogelijk is via https. Anderzijds aan de hand van API keys.
2.5.1 Secure Sockets Layer Secure Sockets Layer(SSL) zal er voor zorgen dat de data via een geëncrypteerde weg wordt verstuurd over het netwerk. Dit voorkomt dat niet zomaar alle data onderschept kan worden. De opzet zelf is een custom attribuut dat op de controller kan geplaatst worden. Er zal dus een nieuwe klasse aangemaakt worden die zal erven van AuthorizationFilterAttribute. Dit attribuut zal ervoor zorgen dat de klasse als attribuut kan gebruikt worden. Daarnaast zal de klasse twee methodes hebben een OnAuthorization die zal kijken of er al dan niet via https gewerkt wordt. De HandleNonHttpsRequests zal een response geven dat de gebruiker verplicht https dient te gebruiken.
Figuur 27 Attribuut voor SSL implementatie
16
2.5.2 API Keys API keys is een sleutel waarde die bijgevoegd wordt in de header van een request om zo te valideren of de applicatie of website die de request doet wel geautoriseerd is. Die op zijn beurt dan aangeeft of de data van de API mag aangesproken worden. Dit zorgt ervoor dat niet iedereen zomaar requests zal doen naar de opgestelde web API. Zoals bij de https header zal er hier ook gebruik gemaakt worden van een attribuut, maar dit keer zal de desbetreffende klasse erven van DelegatingHandler. De SendAsyncmethode zal dan overschreven worden. Het attribuut zal bij elke request valideren of er in de header een API key aanwezig is en al dan niet de toegang toestaan of weigeren.
Figuur 28 API key attribuut In dit geval worden de keys vergeleken met keys die in een database worden opgeslagen zo kunnen keys gemakkelijk later aangepast worden. Of kunnen er extra keys toegevoegd worden indien er extra applicatie zouden bij komen.
2.6 Data Transfer Objects
17
Een Data Transfer Object (DTO) wordt gebruikt wanneer er data opgevraagd wordt van de server naar de client. Dit object slaat alle data op dat bij het request hoort. Hierdoor is het mogelijk dat er minder requests naar de server en dus ook minder overbelasting is voor de server. Voorbeeld hieronder. De client stuurt een request naar de server “Geef mij een bepaalde student” dan wordt er 1 request naar de server gestuurd. De server zendt die bepaalde student terug. De DTO vangt al deze informatie op en als de client dan de naam zou nodig hebben zendt de client naar die bepaalde DTO “Geef mij de naam van de student”. Hierdoor worden er geen onnodige requests gestuurd naar de server. Als de client de leeftijd nodig heeft doet hij dit enkel naar de DTO.
Figuur 29 http://i.msdn.microsoft.com/dynimg/IC54601.gif
Als we geen gebruiken zouden maken van een DTO zouden er verschillende requests gebeuren naar de server dit zoals “Geef mij de naam van die student”, “Geef mij de leeftijd van die student”, “Geef mij de studierichting van deze student”. Hierdoor worden er veel meer requests gestuurd, als gevolg hiervan zal de server ook meer overbelast worden. Een DTO wordt aan de hand van een nieuwe klasse gedefinieerd. Hieronder een voorbeeld van een DTO die aangemaakt is geweest.
Figuur 30 DTO model
18
3 Front-end: Single Page Application Een onderdeel van het project bestaat uit het maken van een Single Page Application (SPA). De applicatie dient alle customer cases terug te geven van RealDolmen. Tevens kan de applicatie alle informatie terug geven over die customer case. De website kan zowel intern als extern bekeken worden. De technologieën die dit onderdeel bevatten zijn ASP.NET MVC 5.1, Javascript, Jquery, Knockout.js, HTML5, CSS3, Bootstrap 3.
3.1 Definitie SPA De definitie van een SPA is alle data laten inladen van een database en die weergeven op één pagina. De data wordt ingeladen aan de hand van een Javascript library Knockout.js. De data wordt hierdoor op dezelfde pagina terug ingeladen enkel met een andere view en andere opbouw van de site. Knockout zorgt ervoor dat de data op het scherm getoond wordt alsook als de data aangepast wordt en automatisch terug ingeladen wordt.
3.2 Opzet SPA Voor het volgende gedeelte dient men best eerste “Bijlage 2 en 3” gelezen te hebben vooraleer men verder kan gaan. In dit hoofdstuk wordt uitgelegd hoe het project is opgesteld en hoe onderdelen en dergelijke technologieën werken.
3.2.1 Aanmaken SPA Het project die onder de Web folder wordt aangemaakt is een ASP.NET Web Application. Hiermee wordt het project gestart. Na het aanmaken van het project wordt er een bepaalde structuur uitgerold. De structuur die hier gebruikt wordt is de MVVM-structuur (zie foto) dit herkennende door de volgende mappen Models, ViewModels, Views. De models zijn beschikbaar in de Shared folder.
3.3 Design Website 3.3.1 Gebruikte technologieën 3.3.1.1 Bootstrap 3 Bootstrap is een tool voor het sneller en gemakkelijker te creëren van websites en web applicaties. Bootstrap bevat enkel HTML, CSS en Javascript. Bij Bootstrap zijn er ook nog enkele extra’s bijgeleverd zoals knoppen, formulieren... Bootstrap zorgt er ook voor dat als je een website bouwt op een computer, de site er ook goed uitziet
Figuur 31 Overzicht SPA 19
op een kleiner toestel zoals een GSM, Tablet,.... Bootstrap wordt gebruikt voor het opstellen van de Externe website tevens zorgt Bootstrap ervoor dat de site responsive design heeft. Hierdoor ziet de site er zowel op een smartphone, tablet en computer er even goed uit. Aangezien dat CSS en HTML niet alleen voor de responsiviteit zorgen maken deze twee technologieën ook nog gebruik van Javascript en LESS.
3.3.1.2 Javascript Javascript is een scripttaal die vaak gebruikt wordt om websites en web applicaties interactief te maken of te ontwikkelen. Javascript kan zowel client-side als server-side gebruikt worden. Client-side Javascript wordt uitgevoerd aan de hand van de browser waarmee men werkt. Server-side Javascript wordt de javascript aan server-zijde uitgevoerd en daarna wordt het resultaat terug gestuurd naar de client.
3.3.1.3 Knockout.js Knockout.js is een Javascript bibliotheek dat je helpt bij het maken van uitgebreide, responsive schermen. Knockout.js zorgt er ook voor dat code gemakkelijker en onder houdbaarder is. Knockout zorgt er tevens ook voordat data, zichtbare elementen en data dat dient getoond te worden zich volledig van elkaar scheiden.
3.3.1.4 HTML5 en CSS3 HTML5 is de nieuwste nog onafgewerkte versie van vorige HTML versies. HTML5 is een opmaaktaal en wordt gebruikt om de opmaak op te stellen voor een website. CSS3 is tevens gemaakt voor de stijl te bepalen van HTML pagina’s. CCS3 geeft de vormen en de kleuren aan HTML pagina’s.
3.4 Gebruikte Patronen 3.4.1 Separation of Concerns Serparation of Concerns of wel SoC genoemd is een design ontwikkeling voor het scheiden van logica in een project. Dit principe kan op elke laag van het project worden toegepast zowel op business logica, prestentatie laag, database laag enzovoort. SoC wordt in elk project toegepast omwille van het gemakkelijker ontwikkelen en onderhouden achteraf. Door dit principe toe te passen kan er ook individuele code sneller aangepast worden zonder kennis te hebben van de andere delen. Eveneens maakt SoC het ook gemakkelijker om code te hergebruiken in andere projecten.
3.4.2 Model-View-ViewModel-Structuur De Model-View-ViewModel-structuur (MVVM-structuur) is een architecturaal patroon en wordt vooral gebruikt om structuur te houden. Alsook wordt dit gebruikt voor te voldoen aan de Separation Of Concerns (SoC). De drie lagen van een MVVM-structuur zijn als volgt:
20
1. Models: Hierbij wordt het model gedefinieerd hoe het object er zou moeten uitzien. 2. Views: Deze bevat vooral alle views die een website zou moeten aannemen. De views gebruiken technologieën zoals HTML5, CSS3, Javascript, Bootstrap en Knockout 3. ViewModels: Alle ViewModels zorgen ervoor dat de correcte weergave van de data gehanteerd wordt. De ViewModels zijn het medium tussen de Models en de Views.
Figuur 32 Bron: http://www.theaccidentalgeek.com/Portals/0/Blog/Files/1/187/Windows-LiveWriter-Getting-Started-with-KnockoutJS_727D-mvvm_2.png
3.5 Doel van SPA Het doel van de SPA is het naar buiten brengen van de customer cases van RealDolmen. Via de website kunnen klanten zien welke projecten gerealiseerd zijn door RealDolmen alsook welke competenties, welke technologieën en welke sectoren waar RealDolmen actief is. Bij de details van de customer cases kan de klant de korte beschrijving bekijken alsook de gebruikte technologieën, de diensten en oplossingen die ze leveren, wanneer het project gerealiseerd is, hoeveel tijd het project in beslag neemt, de contactpersonen alsook de donwloadbare PDF en eventueel nog een video als er één zou beschikbaar zijn.
3.6 Opbouw SPA Voor de opbouw van de SPA beginnen we met een nieuw ASP.NET Web Application. Onder dit project begint het met de aanmaak van verschillende ViewModels voor het weergeven van de data. De Viewmodels worden onderverdeeld in de map ViewModels. Alle ViewModels werden gemaakt via javascript files. Hier 1 ViewModel ter verduidelijking.
Figuur 33 ViewModel Javascript
21
Voor Knockout.js overal te kunnen toepassen op de website alsook de views automatisch te laten updaten, dienen de array’s en dergelijke op voorhand geïnitialiseerd te worden. De naamgeving is hier zeer belangrijk aangezien de namen straks in de View worden hergebruikt voor de aaneenschakeling tussen data en View. Dit wordt mogelijk gemaakt in de file InitializeObservables.js hier een klein voorbeeld.
Figuur 34 Initialiseren observables Om het mogelijk te maken dat knockout overal werkt dient men knockout te activeren dit wordt gedaan op het einde van de main javascript file. Deze lijn code zeker en vast niet vergeten anders werkt knockout niet.
Figuur 35 Knockout activeren Voor er aan de view begonnen wordt, dient er eerst data opgehaald te worden vanuit de database. De views spreken niet rechtstreeks met de database maar met de Web API. Hieronder worden de details van een customercase opgehaald. 22
Figuur 36 Customer cases opvragen javascript De apiRequestBuilder is een andere file waar de URL van de Web API automatisch gegenereerd wordt. Na het automatisch genereren van de URL wordt er een ajax call gedaan naar de Web API. De API call krijgt een header mee ‘X-ApiKey’, dit is een key die toelaat om de Web API te mogen aanspreken. De key is nu hardcoded maar wordt in het vervolg uit de database gehaald. Eenmaal de call gedaan is gaat er bij succes een CustomerCaseModel aangemaakt worden en deze wordt dan doorgegeven naar de View. Aangezien de website een SPA is wordt er hier maar 1 enkele View aangemaakt. De View bevat alles om de data die verkregen is mooi weer te geven.
23
Figuur 37 Opbouw view HTML Bij de eerste div staat een data-bind attribuut dit wijst erop dat hier knockout gebruikt wordt. De naam die naast de foreach staat op dezelfde lijn, staat newestCases. Die naam kan men terugvinden in het InitializeObjects.js script hierdoor koppelt de View en het ViewModel zich. Aangezien newestCases een observable array is wordt de array overlopen en wordt de view aangemaakt die tussen de div staat. Aangezien er een bepaald model wordt toegepast op de array van customer cases kan elke attribuut van dit model aangesproken worden. Hieronder is een voorbeeld beschikbaar met de foto URL.
Ook kan er via knockout verschillende events op 1 bepaalde groep (zoals een div) geplaatst worden. Dit click-event krijgt volgende attributen mee de data en het ID van de bepaalde customer case.
Tot hier de basis setup van de externe website. Zo wordt de volledige SPA dynamisch opgebouwd.
3.7 Resultaat
24
Dit is de homepage van dit project. De layout van de andere navigatie is ongeveer dezelfde.
Figuur 38 Resultaat SPA
25
Figuur 39 Resultaat SPA detail pagina
26
4 Front-end: ASP.NET Application Het tweede onderdeel van het project is een Interne applicatie maken voor het inputten, deleten en updaten van alle data. Eveneens dient de site ook voor het opvragen van alle data die in de database opgeslagen is. Tevens maakt deze applicatie gebruik van de database in plaats van de web API. De verschillende technologieën waarvan de applicatie gebruik maakt zullen hieronder verder toegelicht worden. De applicatie kan enkel binnen RealDolmen gebruikt worden en zal door een persoon van de Marketing onderhouden worden.
4.1 Opzet ASP.NET Application Voor het volgende gedeelte dient men eerste “bijlage 2 en 3” gelezen te hebben vooraleer men verder kan gaan. In dit hoofdstuk wordt uitgelegd hoe het project is opgesteld en hoe onderdelen en dergelijke technologieën werken.
4.1.1 Aanmaken ASP.NET Application Het aanmaken van een ASP.NET Application loopt ongeveer synchroon dan met een SPA. Enkele verschillen zijn er bij de structuur van het project. Alsook de verschillende technologieën die gebruikt worden om de applicatie te maken. De foto beschrijft hier de opmaak hoe het project zal opgesteld worden. Als de foto vergeleken wordt met de vorige foto van de Front-end: Single Page Application kan er gezien worden dat er enkele verschillen in dit project zijn.
4.2 Design Website
Figuur 40 Structuur MVC project
4.2.1 Gebruikte Technologieën De gebruikte technologieën in dit project zijn eveneens gelijk lopend zoals de SPA. De gebruikte technologieën die hier ook aanbod komen zijn Javascript, Bootstrap, HTML5 en CSS3. De documentatie is raadpleegbaar in het vorige hoofdstuk. Enkele technologieën die nog niet zijn uitgelegd worden hieronder verder toegelicht.
4.2.1.1 JQuery Jquery is een Javascript library dat het mogelijk maakt om navigatie tussen documenten, manipulatie, event handeling, animaties en ajax gemakkelijker te maken tussen de API en verschillende browsers. Aangezien de technologie geïntegreerd is in Visual Studio 2013 is dit echter niet moeilijk om Jquery te implementeren in het project.
27
Andere technologieën die gekoppeld zijn aan Jquery zijn Jquery UI (die in dit project geïmplementeerd zal worden), Jquery Mobile, Qunit en Sizzle (Niet geïmplementeerd in dit project). De verschillende Jquery UI’s die gebruikt zijn, zijn Jquery UI Tabs en Jquery UI Datepicker. De eerste, Jquery UI Datepicker wordt toegepast om de data op te slaan van wanneer tot wanneer een project gelopen heeft. De Datepicker wordt ook gebruikt om de inputdatum van de customer case in te stellen. De lay-out van de UI kan rechts op de foto bekeken worden. De tweede, Jquery UI Tabs wordt toegepast om verschillende talen toe te voegen of te veranderen. Deze UI heeft als uitzicht het volgende: Figuur 41 Datepicker
Figuur 42 Invulveld korte beschrijving
28
4.3 Gebruikte patronen 4.3.1 Model-View-Controller-structuur De Model-View-Controller (MVC) is een ontwerppatroon die het verdeelt in 3 verschillende onderdelen. De technologie dat gebruikt wordt in dit project is een ASP.NET MVC 5. De verschillende onderdelen hebben verschillende verantwoordelijkheden:
Figuur 43 http://cupsofcocoa.files.wordpress.com/2011/08/mvcdiagram1.png
1. Model: Het model geeft de representatie terug van alle informatie die dit model krijgt. De applicatie maakt gebruik van het model om data op te halen of weg te schrijven. 2. View: De verschillende views geven verschillende UI elementen terug. Dit zoals buttons, textboxen, comboboxen enzovoort. De View doet niet qua berekeningen en dergelijke de View geeft enkel data weer. 3. Controller: De controller ontvangt de verschillende acties die de gebruiker maakt op de View. De controller zorgt dan verder voor de afhandeling van die verschillende events.
29
4.4 Doel interne website De interne website is bedoelt voor een overzicht te krijgen van alle data. De data bevat o.a. alle klanten, alle customercases, alle diensten en oplossingen enzovoort. Tevens wordt de website gebruikt voor het onderhoud van de externe website. Alsook voornamelijk voor customercases toe te voegen. Via de interne website kan je alles aanpassen, verwijderen of toevoegen. Voor de data up to date te houden zal Marketing hiervoor aangesteld worden. De site is enkel raadpleegbaar via het RealDolmen netwerk.
4.5 Opbouw ASP.NET Application Eerste en vooral beginnen we hier met een nieuw ASP.NET MVC 5 Application project aan te maken. Door het aanmaken van een project worden er automatisch verschillende mappen aangemaakt voor de structuur.
4.5.1 AutoFac configureren Voor de connectie tussen de database en de web applicatie dient er een IoC container gedefinieerd te worden. Voor meer uitleg over IoC kan hoofdstuk “2.3.3 AutoFac” geraadpleegd worden. Een klasse wordt aangemaakt onder de folder App_Start. De klasse ziet er als volgt uit:
Figuur 44 Configureren AutoFac
4.5.2 Controllers aanmaken Na de opzet van de IoC container dienen er controllers aangemaakt te worden deze kunnen hoofdzakelijk automatisch aangemaakt worden. De keuze voor dit project wordt gekozen voor “MVC 5 Controller with views, using Entity Framework”. Alle call’s die in de controllers worden uitgevoerd zijn asynchroon.
30
Figuur 45 Wizard aanmaken controller Daarna moet worden opgegeven aan de hand van welk model de controller moet worden opgemaakt. Alsook dient hier de Context niet te worden meegegeven aangezien er straks connectie gelegd zal worden via de interfaces/repositories.
Figuur 46 Wizard aanmaken controller detail 31
Voordat de rest van de controllers aangemaakt worden, dient er eerst een BaseController aangemaakt te worden. Aangezien er talen dienen beschikbaar te zijn in de applicatie wordt er in de BaseController de BeginExecuteCore-methode overriden. BeginExecuteCore maakt het dan mogelijk om de verschillende talen te ondersteunen.
Figuur 47 Ondersteunen meerdere talen Voor de verderzetting van de andere controllers dienen de controllers allemaal de BaseController te implementeren.
Voor de views te voorzien van data dienen er eerst nog enkele stappen ondernomen te worden. Elke controller dient in de constructor enkele parameters mee te geven. Deze parameters zijn de interfaces die nodig zijn voor de bepaald data op te halen voor die bepaalde View. De constructor kan er als volgt uit zien.
Figuur 48 DI via constructor
32
4.5.3 Views aanleveren van data Nu volgen er enkele voorbeelden voor de views te voorzien van data, alsook voor data te manipuleren, aan te maken en te verwijderen. Onderstaande code dient voor de View te voorzien van alle customers in alle talen.
Figuur 49 Get methode controller De ViewBag.Langs wordt in de View overlopen om de verschillende tabellen te maken. De tweede lijn code wordt iets verder in de View overlopen om data weer te geven.
Figuur 50 Weergeven data via ViewBag In de @Html.ActionLink staat er @Resources. Dit zijn files die zich onder de map “App_GlobalResources” bevinden. Aangezien er in dit project 3 talen dienen beschikbaar te zijn er in dit project ook 3 Resource files.
Figuur 51 Resources 33
Een Resource file kan er als volgt uitzien:
Figuur 52 Inhoud resource file
De @Resources worden aan de hand van de Name opgevraagd. Hierdoor worden dan alle titels en dergelijke aangepast aan de value die er aan gelijk staat. De verwerking van de details pagina verloopt ongeveer synchroon met de index pagina.
Figuur 53 Opvragen detail in controller Voor het aanmaken een customer wordt de View eerst voorbereid dit door een GetMethode. Deze code maakt de data klaar voor het te verzenden naar een EditorTemplate.
34
Figuur 54 Aanmaken customer
4.5.3.1 EditorTemplates EditorTemplates maken het mogelijk de template voor verschillende models te gebruiken. In dit project worden de EditorTemplates vooral gebruikt om de validatie in goede te banen leiden. Aangezien er soms lijsten moeten gevalideerd worden dienen die ook gevalideerd te worden. Zonder EditorTemplates zou dit niet mogelijk zijn en kan de validatie niet correct werken. De EditorTemplates worden altijd gebruikt voor maar één instantie van een lijst en niet een volledige lijst te verwerken. De naam van de EditorTemplate is zeer belangrijk voor de connectie tussen View en template. De EditorTemplate heeft als naam “CreateCustomer”.
Figuur 55 EditorTemplate De EditorTemplate wordt aangesproken via de View. De View wordt hier weergegeven en de “CreateCustomer” legt de link naar de EditorTemplate.
35
Figuur 56 Gebruikt EditorTemplate Voor het effectief creëren van een Customer wordt er een Post-methode gedaan vanaf het formulier op de client naar de server.
Figuur 57 Create methode (POST) In de formcollection wordt dan alle data meegegeven die de client heeft ingegeven. In de bovenstaande code wordt dan alle data verwerkt en geeft aan de gebruiker terug dat de create succesvol gebeurd is. De edit-methode (GET) wordt uitgevoerd wanneer de client een bepaalde customer wilt editeren. Deze methode vraagt dan alle data die nodig is voor de View op.
36
Figuur 58 Edit methode De edit-methode (POST) wordt dan zoals de create-methode(POST) uitgevoerd.
Figuur 59 Edit methode (POST) Alsook de delete-methode (GET) haalt eerst de geselecteerde customer op en geeft de customer terug aan de View. De delete-methode (POST) zorgt er dan voor op zijn beurt de geselecteerde customer te deleten uit de database.
37
Figuur 60 Delete methode
38
4.6 Resultaat
Figuur 61 Homepage Interne website
39
Figuur 62 Details Interne website
40
Figuur 63 Create Interne website
41
Figuur 64 Overzicht Interne website
42
5 Native Clients RealDolmen opteerde zelf voor de opzet van Windows applicaties dit omdat RealDolmen zelf een showcase wilt van wat zij kunnen bouwen voor de klant. In dit geval zal het dus een applicatie zijn dat de Customer Case API zal consumeren en die data zal visualiseren aan de klant. Er zullen twee native clients gebouwd worden, een Windows 8.1 applicatie en een Windows Phone 8 applicatie. Beide kunnen zodanig ontwikkelt worden dat veel van de code in beide projecten kan hergebruikt worden. Dit kan verwezenlijkt worden door een goede Seperation of Concerns(SoC) en Inversion of Control(IoC). SoC toepassen zorgt ervoor dat alles in een project zodanig opgesplitst is zodat het niet afhankelijk is van elkaar. IoC zal er dan weer voor zorgen dat alles generiek is, dit zal er dus voor zorgen dat de juiste code op de juist plaats geïnjecteerd wordt voor zowel de Windows 8.1 applicatie als de Windows Phone 8 applicatie. Beide hoofdstukken zijn opgesplitst maar zullen naar elkaar verwijzen, de eindelijke opzet gebeurt in de Windows 8.1 app waarna de Windows Phone 8 app verder bouwt op de herbruikbare code van de Windows 8.1 app. In “Bijlage 3: Architectuur” is er extra uitleg te vinden over de structuur van de applicatie.
5.1 Windows 8.1 Windows 8.1 applicatie zijn runtime applicatie die gedownload kunnen worden uit de Windows Store. Het verschil met een gewone x86 of x64 applicatie is dat een Windows 8.1 Runtime(RT) app ook op ARM architectuur uitvoerbaar is. ARM wordt gebruikt in tablets, Runtime apps kunnen tevens op een gewone desktop uitgevoerd worden mits die geïnstalleerd wordt vanuit de Windows Store.
5.1.1 Opzet Voor de opzet van de native client kant is het aangewezen te starten vanuit een nieuw solution, dit omdat er geen verwarring zou komen met de code van het Web project. Het project zal opgebouwd zijn aan de hand van het Model-View-ViewModel(MVVM) design pattern, dit is een standaard implementatie van hoe Windows 8.1 applicatie opgebouwd worden. MVVM is een specialisatie van het Presentation Model en grotendeels afgeleid van het MVC patroon. MVVM gaat de Business Logic(Model) scheiden van de View en waarbij het ViewModel aan value conversie zal doen. Zo kan de View de data objecten vanuit het model gemakkelijker consumeren. De View is hier compleet onafhankelijk van alles wat achterliggend is. MVVM is zo gebouwd dat het kan gebruikt worden voor databinding, dit betekent dat er in XAML bindings kunnen gemaakt worden naar een ViewModel. XAML is de achterliggende View logica van WPF, Windows 8.1 en Windows Phone 8 applicaties, hier zal de volledige GUI mee opgebouwd worden.
43
Figuur 65 Bron: http://www.c-sharpcorner.com/UploadFile/0b73e1/mvvm-model-viewviewmodel-introduction-part-1/Images/MVVM2.jpg
5.1.2 Model De business logic ofwel het model zal bestaan uit het eigenlijke model, het model is voornamelijk gebaseerd op de DTO’s van het web project. Het model werkt enkel met de noodzakelijke data die verkregen is door de web API.
Figuur 66 Model gebaseerd op DTO Daarnaast zal er ook een service gedeelte zijn die de data verwerking voor zich neemt. De verschillende services zullen instaan voor het aanspreken van de data via de API, dit zal gebeuren aan de hand van http requests.
44
Figuur 67 Ophalen nieuwste cases
5.1.2.1 Interfaces Voor elke service die aangemaakt wordt zal een gelijknamige interface aangemaakt worden die later via een IoC container wordt geïnjecteerd, dit behoudt de SoC. De interface zal alle publieke methodes bevatten die mogelijks aangeroepen kunnen worden om data op te halen. Hierdoor kan er later eventueel geopteerd worden om in plaats van een web API een WCF service te gebruiken, dan moet er enkel in de IoC container een andere link gelegd worden naar die WCF service.
Figuur 68 Interface overzicht
5.1.3 ViewModel Het ViewModel zorgt ervoor dat de View voorzien kan worden van data en commando’s om operationeel te zijn. De code kan hierdoor in de View gereduceerd worden en de code is dan herbruikbaar in de Phone applicatie. Als framework kan er best geopteerd worden voor de MVVM light library van Laurent Bugnion. MVVM light is een heel uitgebreid framework en heeft tevens een portable class library(PCL) versie. MVVM light kan geïnstalleerd worden via NuGet.
Figuur 69 Toegevoegde bibliotheek MVVM Light Na installatie van MVVM light kan de structuur opgezet worden om de ViewModels te implementeren in de applicatie. Eerst zal er een interface IViewModel aangemaakt worden die een methode Initialize bevat. Initialize zal er voor zorgen dat elk ViewModel die de interface implementeert automatisch na binding van het ViewModel zijn eigen data kan initialiseren. 45
Figuur 70 Interface ViewModel Elke interface die aangemaakt wordt voor zijn respectievelijke zal dan de IViewmodel interface implementeren. Daarnaast zal een ViewModel van ViewModelBase erven. ViewModelBase is een klasse die uit het MVVM Light framework komt. Door de erving hiervan kan automatisch gebruik gemaakt worden van verschillende methodes. Dit zoals RaisePropertyChanged(), die zal er voor zorgen dat de properties automatisch geüpdatet worden zonder dat de programmeur zelf INotifyPropertyChanged zelf moet gaan implementeren. Daarnaast kan er gebruik gemaakt worden van RelayCommand. RelayCommand zorgt voor makkelijk bind bare commands voor in de View. public class CustomerCaseViewModel : ViewModelBase, ICustomerCaseViewModel
De klasse CustomerCaseViewModel zal dus gebruik kunnen maken van ViewModelBase en van de Initialize methode die zich genesteld heeft in het IViewModel van het ICustomerCaseViewModel.
Figuur 71 CustomerCaseViewModel Windows 8.1 In de NavigationService die later zal uitgelegd worden zal Initialize uitgevoerd worden. In de GetData() methode wordt er gebruik gemaakt van de CustomerCaseService. Dit is een service die aangemaakt wordt aan de model kant, die hier nu wordt aangesproken. Om deze te gebruiken wordt hier ook Inversion of Control gebruikt en zal er via Dependency Injection(DI) de juiste service geïnjecteerd worden. De vorm van DI die gebruikt wordt is via constructor injectie. De constructor krijgt een interface van de te injecteren service binnen en zal dan gekoppeld worden aan een variabele van dat zelfde type.
46
Figuur 72 Initialiseren Dependency Injection Dit alles zorgt ervoor dat het ViewModel kan opgebouwd worden met de bindable properties en commands.
Figuur 73 Properties ViewModel
Figuur 74 Commands ViewModel
5.1.4 View Die views worden volledig in XAML opgebouwd dit kan zowel via Visual Studio of Blend afhankelijk van de voorkeur van de programmeur. Het gebruik van de code behind wordt zoveel mogelijk vermeden, dit houdt alles gescheiden. Ook hier zal er eerst een basis interface aangemaakt worden. Die zal IView noemen en zal een property van IViewModel bevatten met een getter.
47
Figuur 75 Interface View IView wordt op zijn beurt dan gekoppeld aan de interface van de view.
Figuur 76 Koppeling View aan Interface View Dit is nodig om later de IoC koppeling te maken. Nu kan de interface geïmplementeerd worden in de code behind van de view. Dit zal de enigste code zijn die daar zal aanwezig zijn op code die View afhankelijk is na.
Figuur 77 Implementatie interface
5.1.4.1 Navigationservice Er zal een eigen NavigationService opgesteld worden om zo een goede implementatie te krijgen voor de View en ViewModel om zo de programmeur een eigen vrijheid te geven zodat alles samen werkt. Eerst zal er weer gestart worden met het aanmaken van een interface die bepaalde key methodes implementeert.
Figuur 78 Interface NavigationService De INvaigationSerivce zal dan in de ViewModels via DI geïnjecteerd worden om zo aangeroepen te worden. Dit is nodig omdat zo de Phone op dezelfde manier kan navigeren maar dan met zijn eigen NavigationService. Het ViewModel zal weten dat het via een methode moet navigeren maar zal niet weten of het de Phone of de RT applicatie is die de methode oproept. private INavigationService _navigationService;
48
_navigationService.Navigate(PageNames.MainPage, args);
Natuurlijk zal er dan eerst een klasse aangemaakt moeten worden in de Windows 8.1 applicatie, die de interface implementeert met de bijhorende methodes. Achteraan in de bijlage kan de volledige NavigationService gevonden worden. Een klein deel in de NavigationService zorgt ervoor dat de binding van het ViewModel met de View kan verwezenlijkt worden. Dit door de initialize methode aan te spreken.
Figuur 79 Snippet NavigationService Telkens als er een navigatie gebeurt zal het ViewModel willen initialiseren, de programmeur moet dan opvangen of dit al reeds gebeurt is of niet.
Figuur 80 Initialiseren data Om makkelijk te kunnen navigeren is het mogelijk om constanten aan te maken van de views die aanwezig zijn in het project. Dit zal later tevens nodig zijn om ook te kunnen navigeren met de Phone applicatie.
49
Figuur 81 Pagenames De string bestaat uit de namespace gevolgd door de mappenstructuur met op het einde de pagina. Nadat de navigatie geïmplementeerd is, is het mogelijk om het volledige geheel aan elkaar te knopen.
5.1.5 Koppeling ViewModels De koppeling zal gebeuren via een container klasse die alle registraties van de interfaces met de respectievelijke klasse gaat koppelen en injecteren. In het voorbeeld hier zal er gebruik gemaakt worden van de SimpleIoC container van de MVVM Light library, maar dit kan natuurlijk ook met een andere container.
5.1.5.1 InstanceFactory Een container klasse is niet noodzakelijk maar neemt heel wat refactoring werk weg. De InstanceFactory zal de ISimpleIoC container gaan wrappen en hier de verschillende methodes gaan koppelen in die wrapper. Indien dus de container verandert moet de code niet aangepast worden, maar dus enkel de InstanceFactory.
50
Figuur 82 InstanceFactory
5.1.5.2 ViewModelLocator Eenmaal dat de container opgesteld is kan het koppelen beginnen. Er zijn twee zaken nodig voor de koppeling te gebruiken. Eerst zal er een property nodig zijn van het ViewModel met als type zijn interface, daarna moet elke interface via de container gekoppeld worden aan zijn klasse.
Figuur 83 CustomerCaseViewModel
51
Figuur 84 Initialiseren ViewModels De ViewModelLocator klasse vindt best plaats in de applicatie zelf omdat de locator specifiek tot de applicatie behoord. Voor de Phone applicatie zal dit via een andere locator gebeuren.
Figuur 85 Plaats ViewModelLocator Er moeten natuurlijk niet enkel ViewModels gekoppeld worden maar ook de services en views moeten gekoppeld worden. Dit gebeurt ook in de locator aan de hand van de container.
52
Figuur 86 Initialiseren Views en Services In de App.xaml file kan nu de ViewModelLocator toegevoegd worden om zo de binding in de View tot stand te brengen.
5.1.6 Databinding Door databinding toe te passen kan alle data gevisualiseerd worden in de View zonder hiervoor code te moeten schrijven in de code behind. Dit geeft designers of integrators de mogelijkheid al een View op te stellen en die dan aan de programmeur op te leveren zonder dat de programmeur zich iets van die code moet aantrekken. Door dat de ViewModelLocator gespecificeerd is in de App.Xaml is het mogelijk de locator aan te spreken in de designer van de View. DataContext="{Binding CustomerCaseViewModel, Source={StaticResource ViewModelLocator}}"
Zo kan alle data van een bepaalde geïnjecteerd ViewModel geconsumeerd worden door de View. Dit geldt dan tevens voor commands die zo op dezelfde manier dan gebind wordt aan de View. ItemsSource="{Binding CustomerCases}"
53
Figuur 87 Databinding Xaml
5.1.6.1 Converters Converters zorgen ervoor dat data kan verwerkt worden via de databinding, zo kan een converter bijvoorbeeld een lijst van customer cases binnenkrijgen, indien de lijst leeg is kan er een boodschap getoond worden aan de gebruiker.
54
5.1.7 Resultaat Alles samen moet een werkende Windows 8.1 applicatie opleveren, verder zal er de mogelijkheid zijn de meeste onderdelen te gaan hergebruiken voor de Windows Phone applicatie.
Figuur 88 Homepage Windows 8.1
Figuur 89 Detailpagina Windows 8.1 55
5.2 Windows Phone 8 Omdat al heel wat code uit de Windows 8.1 Applicatie te hergebruiken valt is er al heel wat werk uitgespaard. Het grootste werk zal zich bevinden in het uitwerken van het design aan de View zijde. Verder zal er een eigen navigatie opgezet worden aan de hand van de interfaces die in het Windows 8.1 project reeds werden aangemaakt. Er zal een aparte ViewModelLocator klasse geïmplementeerd worden.
5.2.1 View Sharing van de View code is nog niet echt mogelijk, op enkele controls na. Hierdoor is het dus nodig nieuwe views te gaan aanmaken. Indien een View qua data afwijkt van de pagina’s in de Windows 8.1 applicatie zal er tevens een nieuw ViewModel moeten aangemaakt worden. Indien dit niet het geval is kan gewoon hetzelfde ViewModel vanuit de Windows 8.1 applicatie gebruikt worden. Dit was nodig voor de mainpage van de Windows Phone applicatie, dit omdat er meer data noodzakelijk was om te tonen, maar irrelevant was voor de Windows 8.1 applicatie.
5.2.1.1 NavigationService Omdat de navigatie tussen de Windows 8.1 RT en de Windows Phone 8 verschillend is moet hier zelf een implementatie worden voorzien. Dit komt omdat de navigatie van de RT versie op ‘type’ navigeert terwijl bij de Phone dit op basis van een relatieve uri string is. Dit kan opgelost worden door een kleine workaround die ervoor zorgt dat de navigatie ongeveer op dezelfde manier in de Phone zal werken. Een methode zal er voor zorgen dat bij het meegeven van de pagename zelf een relatief pad geconstrueerd wordt. Dit zorgt er voor dat er geen aparte code in het ViewModel nodig is om navigatie uit te voeren.
Figuur 90 Navigation bij Type De pagenames die aangemaakt werden in het RT project zijn volledig compatibel met het Phone project omdat het deel van de namespace verwaarloost wordt bij de opbouw.
56
5.2.2 ViewModel Het kan zijn dat er bepaalde properties of commands zijn die extra moeten worden toegevoegd in de Phone app die niet van toepassing zijn voor de RT versie. Omdat er gewerkt wordt met een PCL kan helaas geen aparte compile versie gemaakt worden. Deze genereerd bij de build aparte code voor dat bepaald platform.
5.2.3 Koppeling ViewModels Voor de koppeling in het Phone project zal tevens een ViewModelLocator geïmplementeerd moeten worden aan de Phone zijde. De locator wordt dan op dezelfde manier in de App.xaml gespecificeerd.
5.2.4 Resultaat Het resultaat is een Phone applicatie dat met weinig moeite code hergebruikt vanuit de mvvm setup.
Figuur 92 Overzicht Windows Phone 8
Figuur 91 Detailpagina Windows Phone 8
57
5.3 Universal Apps (Windows 8.1 en Windows Phone 8) Op 2 april 2014 werd op Build de komst van de universal apps aangekondigd, dit viel natuurlijk net buiten de scope van de stage opdracht en kon niet tijdig geïmplementeerd worden. Universal Apps kan een oplossing bieden voor nog meer sharing van content en code tussen de applicaties. Dit doordat er een shared project ingebakken zit dat naar beide platformen portable is zonder dat er grote code aanpassingen nodig zijn. Universal apps kan zeker naar later toe een oplossing bieden voor de tekorten die Windows 8.1 en Windows Phone 8 momenteel nog ondervinden door de te grote verschillen tussen beide platformen.
58
Conclusie Het doel van het project was 1 backend op te zetten en verschillende clients hieraan koppelen. De backend werd door ons tezamen opgezet waarna onzen wegen splitsten. Joeri maakte de Windows 8 en Windows Phone 8 applicaties. Glenn maakte de Interne website voor de onderhoudt van de data en de Externe website voor alle data weer te geven voor de klanten.
Joeri Alles wordt mobile, mensen willen voor alles een applicatie. Om die noden te kunnen voorzien is een goed structuur nodig om dit op te bouwen. Zelf heb ik een beter beeld gekregen hoe applicatie te bouwen en deze van data te voorzien. Het opzetten van een eigen backend op basis van een Rest web API biedt zeer veel mogelijkheden aangezien alles hiermee kan communiceren. En zo developers in staat stelt om zelf voor elkaar applicatie te bouwen. Zelf ben ik vooral gepassioneerd door de .Net wereld maar dit beperkt me gelukkig niet voor ook applicaties te bouwen voor iOS en Android, dit is zeer makkelijk te bereiken met Xamarin. Hierdoor wordt hier ook een kloof gedicht tussen de verschillende werelden. Ik heb zeker zeer veel bijgeleerd in de 13 weken dat ik stage liep het heeft mijn inzicht als developer zeer hard versterkt en mijn ervaring en kennis is met een grote stap toegenomen op een zeer korte tijd. Programmeren leer je door te doen en te onderzoeken.
Glenn Alle onderdelen langs de web zijde zijn geïmplementeerd. De toekomst zal verder uitwijzen of dit project zal gebruikt worden in de toekomst. Aangezien het een groot bedrijf is moet deze applicatie nog enkele stappen ondernemen voor het te laten goedkeuren. Eens het project zal uitgerold worden zal de externe website voornamelijk door klanten gebruikt worden en de interne website zal voornamelijk door Marketing gebruikt worden. Deze 13 weken stage hebben mij enorm veel kennis bijgebracht. Tijdens mijn opleiding heb ik een bepaald basis gekregen. Dit waren soms iets verouderde technologieën. Gedurende de stage heb ik de nieuwste technologieën leren gebruiken. De richting waarbij mijn kennis is verhoogd is vooral naar de web zijde. Dit door ASP.NET MVC 5, Knockout, EntityFramework, Javascript, Jquery, HTML5, CSS3. Door deze stage heb ik ook meer inzicht gekregen van hoe een applicatie binnen een groot bedrijf wordt opgezet. Alsook het splitsen van code die zeer belangrijk is voor later onderhoud aan de applicatie. Samengevat, de stage was voor mij een zeer leerrijke periode en zeker en vast een mooie afsluiter van mijn studies.
59
Literatuurlijst “Bootstrap (front-End Framework).” Wikipedia, the Free Encyclopedia, April 30, 2014. http://en.wikipedia.org/w/index.php?title=Bootstrap_(frontend_framework)&oldid=606454846. “HTML5.” Wikipedia, April 30, 2014. http://nl.wikipedia.org/w/index.php?title=HTML5&oldid=38341517. “JavaScript.” Wikipedia, April 30, 2014. http://nl.wikipedia.org/w/index.php?title=JavaScript&oldid=38631650. “CodeProject” CodeProject, January 17, 2014.www.codeproject.com.
60
Figurenlijst Figuur 1 Overzicht Web API project .................................................................................... 2 Figuur 2 Wizard aanmaken API project ............................................................................... 3 Figuur 3 ER diagram van de database ................................................................................ 4 Figuur 4 Snippet relatie binnen model één op veel .............................................................. 5 Figuur 5 Snippet relatie binnen model veel op veel ............................................................. 5 Figuur 6 NuGet package EntityFramework .......................................................................... 5 Figuur 7 Project setup repositories ...................................................................................... 6 Figuur 8 Voor te stellen tabellen voor database .................................................................. 6 Figuur 9 Mappen tussentabellen in code ............................................................................. 7 Figuur 10 Wizard aanmaken database op Azure ................................................................. 7 Figuur 11 Wizard aanmaken user Azure ............................................................................. 8 Figuur 12 Toelaten IP adres op Azure ................................................................................. 8 Figuur 13 Connectionstring naar Azure database ............................................................... 8 Figuur 14 Package manager console .................................................................................. 9 Figuur 15 Snippet seed methode ........................................................................................ 9 Figuur 16 Code gegenereerd door EF voor het aanmaken van de database op Azure ....... 9 Figuur 17 Gegenereerde database op Azure .................................................................... 10 Figuur 18 Methodes van de repository interface ................................................................ 11 Figuur 19 Get methode customer case repository ............................................................. 11 Figuur 20 Registratie repositories in AutoFac .................................................................... 12 Figuur 21 AutoFac aan de config file toevoegen ............................................................... 12 Figuur 22 Aanmaken controller via wizard ......................................................................... 13 Figuur 23 Specificeren controller ....................................................................................... 14 Figuur 24 Overzicht controller code................................................................................... 14 Figuur 25 DI via constructor .............................................................................................. 15 Figuur 26 Detail get API controller..................................................................................... 15 Figuur 27 Attribuut voor SSL implementatie ...................................................................... 16 Figuur 28 API key attribuut ................................................................................................ 17 Figuur 29 http://i.msdn.microsoft.com/dynimg/IC54601.gif ................................................ 18 Figuur 30 DTO model........................................................................................................ 18 Figuur 31 Overzicht SPA ................................................................................................... 19 Figuur 32 Bron: http://www.theaccidentalgeek.com/Portals/0/Blog/Files/1/187/WindowsLive-Writer-Getting-Started-with-KnockoutJS_727D-mvvm_2.png .................................... 21 Figuur 33 ViewModel Javascript........................................................................................ 21 Figuur 34 Initialiseren observables .................................................................................... 22 Figuur 35 Knockout activeren ............................................................................................ 22 Figuur 36 Customer cases opvragen javascript ................................................................. 23 Figuur 37 Opbouw view HTML .......................................................................................... 24 Figuur 38 Resultaat SPA ................................................................................................... 25 Figuur 39 Resultaat SPA detail pagina .............................................................................. 26 Figuur 40 Structuur MVC project ....................................................................................... 27 Figuur 41 Datepicker ......................................................................................................... 28 Figuur 42 Invulveld korte beschrijving ............................................................................... 28 Figuur 43 http://cupsofcocoa.files.wordpress.com/2011/08/mvc-diagram1.png ................. 29 61
Figuur 44 Configureren AutoFac ....................................................................................... 30 Figuur 45 Wizard aanmaken controller .............................................................................. 31 Figuur 46 Wizard aanmaken controller detail .................................................................... 31 Figuur 47 Ondersteunen meerdere talen........................................................................... 32 Figuur 48 DI via constructor .............................................................................................. 32 Figuur 49 Get methode controller ...................................................................................... 33 Figuur 50 Weergeven data via ViewBag ........................................................................... 33 Figuur 51 Resources ......................................................................................................... 33 Figuur 52 Inhoud resource file ........................................................................................... 34 Figuur 53 Opvragen detail in controller.............................................................................. 34 Figuur 54 Aanmaken customer ......................................................................................... 35 Figuur 55 EditorTemplate .................................................................................................. 35 Figuur 56 Gebruikt EditorTemplate ................................................................................... 36 Figuur 57 Create methode (POST) ................................................................................... 36 Figuur 58 Edit methode ..................................................................................................... 37 Figuur 59 Edit methode (POST) ........................................................................................ 37 Figuur 60 Delete methode ................................................................................................. 38 Figuur 61 Homepage Interne website ............................................................................... 39 Figuur 62 Details Interne website ...................................................................................... 40 Figuur 63 Create Interne website ...................................................................................... 41 Figuur 64 Overzicht Interne website .................................................................................. 42 Figuur 65 Bron: http://www.c-sharpcorner.com/UploadFile/0b73e1/mvvm-model-viewviewmodel-introduction-part-1/Images/MVVM2.jpg ........................................................... 44 Figuur 66 Model gebaseerd op DTO ................................................................................. 44 Figuur 67 Ophalen nieuwste cases ................................................................................... 45 Figuur 68 Interface overzicht ............................................................................................. 45 Figuur 69 Toegevoegde bibliotheek MVVM Light .............................................................. 45 Figuur 70 Interface ViewModel .......................................................................................... 46 Figuur 71 CustomerCaseViewModel Windows 8.1 ............................................................ 46 Figuur 72 Initialiseren Dependency Injection ..................................................................... 47 Figuur 73 Properties ViewModel ....................................................................................... 47 Figuur 74 Commands ViewModel ..................................................................................... 47 Figuur 75 Interface View ................................................................................................... 48 Figuur 76 Koppeling View aan Interface View ................................................................... 48 Figuur 77 Implementatie interface ..................................................................................... 48 Figuur 78 Interface NavigationService............................................................................... 48 Figuur 79 Snippet NavigationService ................................................................................ 49 Figuur 80 Initialiseren data ................................................................................................ 49 Figuur 81 Pagenames ....................................................................................................... 50 Figuur 82 InstanceFactory................................................................................................. 51 Figuur 83 CustomerCaseViewModel ................................................................................. 51 Figuur 84 Initialiseren ViewModels .................................................................................... 52 Figuur 85 Plaats ViewModelLocator .................................................................................. 52 Figuur 86 Initialiseren Views en Services .......................................................................... 53 Figuur 87 Databinding Xaml .............................................................................................. 54 Figuur 88 Homepage Windows 8.1 ................................................................................... 55 62
Figuur 89 Detailpagina Windows 8.1 ................................................................................. 55 Figuur 90 Navigation bij Type ............................................................................................ 56 Figuur 91 Detailpagina Windows Phone 8......................................................................... 57 Figuur 92 Overzicht Windows Phone 8 ............................................................................. 57 Figuur 93 http://www.codeproject.com/KB/miscctrl/768427/mvvm.png .............................. 93
63
Bijlagen Bijlage 1: Informatie stage Stagebedrijf RealDolmen is het bedrijf waar we 13 weken stage liepen. Het bedrijf heeft verschillende vestigingen over het hele land. Tevens zijn ze ook gevestigd in Luxemburg en Frankrijk. Vestigingen in België: Huizingen (HQ) Kontich De Pinte Diegem Harelbeke Lummen Namen Bergen Vestiging in Luxemburg: Real Solutions Vestigingen in Frankrijk: Paris la Défense Lille Huizingen was de vestiging waar we voornamelijk aanwezig waren. De stagementor kon niet altijd aanwezig zijn in Huizingen daardoor diende ik nu en dan naar de vestigingen Kontich of De Pinte te gaan dit voor de opvolging van het project.
Projectomschrijving Het project bestond uit verschillende luiken. Maken van Windows 8 app Realiseren van Windows Phone app Verwezenlijken van een externe website Vervullen van interne website voor onderhoud externe website Eventuele uitbreiding voor Android en IOS
64
Keuze voor RealDolmen Contactgegevens Stageplaats Industriezone Zenneveld A. Vaucampslaan 42 1654 Huizingen Tel: +32 2 801 55 55 Fax: +32 2 801 55 99 Website: http://www.realdolmen.com
Student Glenn Delahaye Valleistraat 69 9402 Meerbeke Tel: +32 497 24 96 83 E-mail: [email protected] Joeri Goeyvaerts Huytstraat 22 9450 Haaltert Tel: +32 473 39 49 01 E-mail: [email protected]
Stagebegeleider Henk Bostyn E-mail: [email protected]
Stagementor Alexander Reynaert E-mail: [email protected]
65
Bijlage 2: Functionele Analyse
Inleiding Doel van de MSCC-stageopdracht is om een applicatie te maken om customer cases te tonen en te beheren. Bijvoorbeeld: iemand zit op een interessant project en schrijft via de toepassing daar een case over; de admin keurt deze goed en kan door verkopers of online gelezen worden. Het is hierbij expliciet de bedoeling dat de toepassing gebruikt zal worden in een Windows8-omgeving, Windows Phone en web. Dit document geeft een globale beschrijving via de functionele analyse en kan eventueel later aangepast of uitgebreid worden. Op dit punt is er door de beperkte middelen een globaal document opgesteld om de basis van de toepassing te beschrijven.
Actoren Het overzicht van de actoren definieert alle actoren die met het systeem werken. Een actor is een gebruiker die een interactie uitvoert met het systeem. De actor vervult een bepaalde rol tijdens deze interactie. Actoren zijn niet altijd personen maar kunnen ook externe systemen of concepten vertegenwoordigen.
Gebruikersactoren Gebruiker actor Beheerder customer case
Omschrijving actor De beheerder customer case is degene die de betreffende customer case beheerd. Dit meestal iemand die zeer goed op de hoogte is van het door RealDolmen uitgevoerde project. Dit is meestal iemand die zelf op het project gewerkt heeft. Het is mogelijk dat verschillende personen van een project werken aan één customer case.
Goedkeurder
Degene die de customer case goedkeurt. Er wordt verondersteld dat dit iemand van de marketing afdeling zal zijn. Deze persoon kan natuurlijk altijd advies inwinnen bij een project manager of andere betrokkenen bij een project.
Lezer customer case 66
Degene die toegangsrechten krijgt om een
goedgekeurde customer case te openen en te bekijken.
Identificatie van actoren Dit gedeelte is nog technisch uit te werken in overleg met Alexander en Security. Het belangrijk bij de identificatie van actoren rekening te houden met de verschillende hardware (smartphone, laptop). Er zijn verschillende pistes.
Single sign-on Hierbij logt iemand in op haar/ zijn pc en wordt ineens geïdentificeerd. Via Live?
Via login scherm Hierbij kan iemand alleen bij de applicatie door in te loggen. Het betreft hier een standaard loginscherm (gebruiker, wachtwoord). Dit is nog niet voorzien in dit document.
Andere?
Use Cases Beheer van customer cases Informatie Doel Het beheer van customer cases speelt zich af rond het de aanpassingsmogelijkheden en het creëren van de beheerders customer case.
Veronderstellingen
Een beheerder customer case mag alleen een nieuwe customer case maken of een bestaande openen waarvan hij het beheer heeft.
Actoren Beheerder customer case.
67
Scenario’s Creëren van customer case Sta Beschrijving van de interactie p 1 De beheerder customer case opent een nieuwe customer case.
2
De beheerder customer case vult de velden.
3
De beheerder customer case klikt op klaar voor publicatie.
Interface SC01 - Scherm "Home”, SC03 Scherm "Customer case beheersscherm” SC03 - Scherm "Customer case beheersscherm”
Alternatieve flow: de beheerder customer case bewaart als draft, om later verder aan te werken. Wijzigen van een customer case Sta Beschrijving van de interactie p 1 De beheerder customer case kiest de te wijzigen customer case.
2
De beheerder customer case wijzigt de gewenste velden.
3
De beheerder customer case klikt op klaar voor publicatie.
Interface SC02 - Scherm "Customer case zoeken”, SC03 Scherm "Customer case beheersscherm” SC03 - Scherm "Customer case beheersscherm”
Alternatieve flow: de beheerder customer case bewaart als draft, om later verder aan te werken. Verwijderen van een customer case Sta Beschrijving van de interactie p 1 De beheerder (of alternatief: goedkeurder) customer case kiest de te verwijderen customer case.
2
De beheerder (of alternatief: goedkeurder) customer case klikt op verwijderen en bevestigt nogmaals.
3
Het systeem verwijdert de customer case.
68
Interface SC02 - Scherm "Customer case zoeken”, SC03 Scherm "Customer case beheersscherm” SC03 - Scherm "Customer case beheersscherm”
Keuring van customer cases Informatie Doel Het doel van deze use case is het beschrijven van het proces van goedkeuren of afkeuren van customer cases.
Veronderstellingen
Er wordt verondersteld dat een customer case klaar is voor goedkeuring.
Actoren De goedkeurder zal een customer case uiteindelijk goedkeuren of afkeuren.
Scenario’s Goedkeuren en publiceren van een customer case Sta p 1
Beschrijving van de interactie
Interface
Goedkeurder opent een customer case die klaar is voor goedkeuring.
2
Goedkeurder wijzigt zonodig de inhoud van de velden of voegt informatie toe.
3
Goedkeurder klikt op goedkeuren.
SC01 - Scherm "Home”, SC04 - Scherm "Te keuren customer cases”, SC03 - Scherm "Customer case beheersscherm” SC03 - Scherm "Customer case beheersscherm” SC03 - Scherm "Customer case beheersscherm”
4
Alternatieve flow: de goedkeurder bewaart de customer case door op bewaren te drukken, om later verder aan te werken. . Het systeem update de status tot goedgekeurd (voor publicatie).
Afkeuren van een customer case Sta p 1
Beschrijving van de interactie
Interface
Goedkeurder opent een customer case die klaar is voor goedkeuring.
SC01 - Scherm "Home”, SC04 - Scherm "Te keuren customer cases”, 69
2
Goedkeurder wijzigt zonodig de inhoud van de velden of voegt informatie toe.
3
Goedkeurder klikt op afkeuren.
4
Alternatieve flow: de goedkeurder bewaart de customer case door op bewaren te drukken, om later verder aan te werken. Het systeem update de status naar afgekeurd (voor publicatie).
SC03 - Scherm "Customer case beheersscherm” SC03 - Scherm "Customer case beheersscherm” SC03 - Scherm "Customer case beheersscherm”
Gebruiken van customer cases Informatie Doel Het doel is om gepubliceerde customer case te zoeken en te bekijken. Het is uitdrukkelijk de bedoeling dat dergelijk customer cases er "mooi" uit mogen zien, omdat deze ook getoond kunnen worden aan derde partijen voor marketing- en verkoopdoeleinden.
Actoren De customer cases worden gebruikt door de lezer customer cases. Dit is degene die toegangsrechten heeft tot de applicatie en tot de customer cases.
Scenario’s Zoeken en bekijken van een customer case Sta p 1
Beschrijving van de interactie
2
De lezer vult zoektermen en klikt op zoeken.
3
Het systeem toont de resulaten of geeft een melding: "Geen resultaten gevonden." De lezer klikt op een customer case om details te bekijken.
4
Interface
De lezer opent het zoekscherm.
Diagram van de Domain Classes Class “CustomerCase” Lijstveld 70
Type
Beperkingen
ID CustomerCaseGroepID
String String
PRIMARY KEY De groep waar deze customer case toe behoort. Dit is bedoeld om de verschillende taalversies te groeperen. TaalVersie Dropdown EN, FR, NL NaamOrganisatie String NOT NULL NaamProject String Periode String Doorlooptijd String DoelProject String KorteBeschrijvingProject String Hier moet een korte beschrijving inpassen VolledigeBeschrijvingProject String Hier moet een volledige beschrijving inpassen Video String Hyperlink DatumAanvraag Date Foto String Link naar BLOB Logo String Link naar BLOB
Class “CustomerCaseContact” Veld ID
Type Beperkingen Uitleg String PRIMARY Deze wordt gegenereerd. KEY
CustomerCaseID Contact String
Dit veld bevat de contactpersoon van een customer case. Bij één customer case mogen meerdere contactpersonen.
Class “CustomerCaseSector” Veld Type Beperkingen ID String PRIMARY KEY CustomerCaseID Sector Dropdown Keuzes (zoals op realdolmen.com): Education General Industry & Services Healthcare Logistics & Distribution Media & Telecom Pharma & Lifesciences Public Utilities
71
Class “CustomerCaseSolution” Veld Type Beperkingen ID String PRIMARY KEY CustomerCaseID Dienst Dropdown Verschillende Solutions
Class “CustomerCaseTechniek” Veld Type Beperkingen ID String PRIMARY KEY CustomerCaseID Techniek Dropdown Keuzes (lijst nog uit te werken): .NET JAVA ...
Class “CustomerCaseGroep” Deze wordt gebruikt om dezelfde customer cases met verschillende taalversie te groeperen. Lijstveld Type Beperkingen ID String PRIMARY KEY
Interfaces Algemene bepalingen Algemene lay-out en stijlkenmerken De stijl van alle schermen en rapporten moeten nog besproken worden met de afdeling Marketing (Tina De Wilde).
Menustructuur De menustructuur van de applicatie is als volgt: Menu-item Home Customer case zoeken Nieuwe customer case maken Te keuren customer 72
Beheerder x x
Goedkeurder x x
x
? x
Lezer x x
cases Customer case detailscherm
x
x
x
Schermen Dit scherm beschrijft een concept van de gebruikersinterface en of een aantal zaken al dan niet getoond moeten worden. De beschrijvingen van de gebruikersinterface zijn te begrijpen als een schets van welke elementen op het scherm zichtbaar moeten zijn en in welke context. Het is niet de bedoeling van dit document om een exacte specificatie van de positie, kleur en lettertype van ieder element te geven.
SC01 - Scherm "Home” Schermtype Gebruiksfrequentie Scope
Navigatiescherm Dagelijks
Structuur van het Scherm De structuur moet nog besproken worden met Marketing (Tina De Wilde). Doel van het Scherm Doel is om hier te starten als de applicatie opstart. Van de homepage moet daarom een goede navigatie zijn naar de andere pagina's. De navigatie is afhankelijk van de actor.
SC02 - Scherm "Customer case zoeken” Schermtype Gebruiksfrequentie Scope
Zoekscherm Dagelijks
73
Structuur van het Scherm
* Lijst met resultaten enkel zichtbaar na succesvolle zoekopdracht. Max 15 items.
Beschrijving “Zoektermen” Zoekterm Type Naam organisatie Text Naam project Text Sector Dropdown
Verplicht? N N N
Techniek
Dropdown
N
Contactpersoon RealDolmen Taal
Dropdown
N
Selectiebox Y, minstens één
Operator Veronderstelde waarde LIKE LIKE == Keuze uit één van de 8 waarden. (Zie datamodel.) == Keuze uit één van technieken. (Zie datamodel.) == Keuzes: Engels, Frans, Nederlands. Gebruiker moet minstens één aanvinken. Standaard de voorkeurstaal van de gebruiker aangevinkt.
Minstens één zoekterm is verplicht. Knop Zoeken
Gedrag De resultaten worden weergegeven (of een melding dat er geen resultaten gevonden zijn). Bij iedere keer dat deze knop wordt ingedrukt, wordt de zoekopdracht opnieuw uitgevoerd.
Beschrijving “Lijst met Resultaten” Dit is een lijst met alle attributen die gekend, in pagina’s van 15 items. Initieel gesorteerd op Naam organisatie. Daarna volgens laatste sortering gebruiker. 74
Zoekterm Knop Openen
Zichtbaar Allen
Knop Wijzigen
Beheerder, Goedkeurder
Naam organisatie Naam project Sector Technieken Taal Contactpersonen RealDolmen
Sorteerbaar Gedfraag N Opent SC05 - Scherm "Customer case detailscherm” N Opent SC03 - Scherm "Customer case beheersscherm Y Y Y Y Y N
De taalversie van de customer case Toont eventueel meerdere contactpersonen. Als dit niet past, dan eventueel één contactpersoon met drie puntjes of plusteken tonen. Zelf te bekijken.
SC03 - Scherm "Customer case beheersscherm” Schermtype Gebruiksfrequentie Scope
Formulierscherm Dagelijks
Structuur van het Scherm English
Veldnamen
français
Nederlands
Te beheren velden
Een knop "voorbeeld" geeft een popup scherm met voorbeeld zoals het scherm SC05 Scherm "Customer case detailscherm”. De tabs verwijzen naar de taal waarin de customer case wordt beschreven. Beschrijving Dit is een lijst met alle attributen die gekend zijn. 75
Lijstveld Naam organisatie Naam project Sector Periode Doorlooptijd Doel project Korte beschrijving project Volledige beschrijving project Foto Video Techniek Contactpersonen RealDolmen
Knop Contactpersonen toevoegen
Type Gedrag Text Text Dropdown Het moet mogelijk zijn meerdere sectoren te selecteren of toe te kennen aan een customer case Text Text Text Text Text Photo
Eventueel meerdere foto's kunnen opladen, bijvoorbeeld van logo firma of project. Link Link naar bv. Youtube. Persoon moet dan zelf de video opladen op Youtube. Dropdown Het moet mogelijk zijn meerdere technieken te selecteren of toe te kennen aan een customer case Dropdown Autosuggest. Als een persoon is ingegeven, dan verschijnt een verwijder-icoontje om te persoon eventueel weer te verwijderen. Knop Geeft een extra inputveld voor nog een contactpersoon..
De knoppen verschijnen per tab, zodat per taal kan worden goedgekeurd of niet. Knop Bewaren
Knop zichtbaar Gedrag voor Beheerder, Gegevens worden bewaard als Draft. Eventuele Goedkeurder veranderingen aan een al goedgekeurde customer case worden nog niet getoond. Een beheerder moet deze later eerst ter goedkeuring voorleggen. Een goedkeurder moet deze eerst goedkeuren.
Klaar om goed Beheerder te keuren Goedkeuren Goedkeurder
76
Terug naar het vorige scherm. Gegevens worden bewaard. De status veranderd van Draft naar Goed-te-keuren. Gegevens worden bewaard. De status veranderd naar Goedgekeurd. Het systeem zal de customer publiceren.
Afkeuren
Goedkeurder
Verwijderen
Beheerder, Goedkeurder Beheerder, Goedkeurder Beheerder, Goedkeurder
Annuleren Voorbeeld tonen
Gegevens worden bewaard. De status veranderd naar Afgekeurd. Het systeem zal de customer niet publiceren. Gegevens van de betreffende customer case worden verwijderd. Terug naar vorige pagina. Gegevens worden niet bewaard. Terug naar vorige pagina. Opent popup met voorbeeld van die taalversie.
SC04 - Scherm "Te keuren customer cases” Schermtype Gebruiksfrequentie Scope
Lijstscherm Dagelijks
Structuur van het Scherm Dit scherm zal een lijst bevatten met te keuren customer cases. Maximaal 50 resultaten per pagina.
Beschrijving Dit is een lijst met alle attributen die gekend zijn. Initieel sorteren op DatumAanvraag. Daarna sorteren op laatst gesorteerde volgorde van de betreffende gebruiker. Lijstveld knop Openen
Type Sorteerbaar Knop Nee
Naam project
Text
Naam organisatie Taalversie Beheerder
Text
DatumAanvraag
Date
Text Text
Gedrag Opent SC03 - Scherm "Customer case beheersscherm”
Ja, alfabetisch Ja, alfabetisch Ja Ja, alfabetisch Ja, op datum
SC05 - Scherm "Customer case detailscherm” Schermtype Gebruiksfrequentie Scope
Formulierscherm Dagelijks
77
Structuur van het Scherm De structuur moet nog besproken worden met Marketing (Tina De Wilde).
78
Beschrijving Dit is een lijst met alle attributen die gekend zijn. Lijstveld Naam organisatie Naam project Sector Periode Doorlooptijd Doel project Korte beschrijving project Volledige beschrijving project Foto Video
Type Gedrag Text Text Dropdown Text Text Text Text
Techniek
Dropdown
Text
Photo Link
Hier opent een typisch videoschermpje met een playknop. De video start niet meteen, pas als de gebruiker de play-knop indrukt.
79
Bijlage 3: Architectuur Web project
Inleiding Het project “One Backend, Different Clients” bestaat uit drie onderdelen. Het eerste onderdeel is een backend maken en een API opstellen. Het tweede onderdeel bestaat eruit om 2websites te maken, 1externe website en 1interne website. Het laatste onderdeel bestaat eruit om een Windows 8 applicatie te maken en een Windows Phone 8 applicatie. De onderdelen die in dit document zullen besproken worden zijn Backend en API en de 2websites. Voor de backend hebben we een database aangemaakt. Deze database hebben we laten genereren door Code First via het Entity Framework 6. Deze laag geeft ons dan toegang om vanuit zowel de externe als interne website alle data op te vragen. De externe website heeft als doel de CustomerCases van RealDolmen beschikbaar te maken voor het publiek en mogelijks toekomstige klanten. Bij de CustomerCases kan men dan alle informatie opzoeken van wie de contactpersonen zijn, welke technologieën er gebruikt zijn, wanneer dit project gestart is, .... Tevens hebben we dan ook een site nodig voor de CustomerCases te beheren dit is de interne website. Via deze site maken we het mogelijk om CustomerCases toe te voegen, te updaten, te deleten, .... Eveneens maakt deze site het mogelijk om Customers, Technologieën, Sectoren, Divisies, Software, Services en Solutions toe te voegen, te updaten en te deleten.
80
Opbouw ProjectStructuur Namespaces De namespaces die wij gehanteerd hebben voor de opbouw van het project is RD.CustomerCases.GlobalProjectName.SpecificProjectName
Verschillende Projecten en Class Libraries De solution noemt als volgt “RD.CustomerCases.Web” hieronder bevinden zich eerst subfolders:
0.Shared In de Shared-folder bevindt zich een class library die “RD.CustomerCases.Model” heet. In deze class library bevinden zich alle models die nodig zijn voor het project.
1.DAL In de DAL-folder bevinden zich 2 class libraries de ene heet “RD.CustomerCases.Repositories” en de andere “RD.CustomerCases.Repositories.Contracts”. RD.CustomerCases.Repositories.Contracts In deze class library bevinden zich alle interfaces die zich laten implementeren door de andere class library. De interfaces bevatten de contracten hoe de repository laag er zou dienen uit te zien. RD.CustomerCases.Repositories Bij deze class library bevinden zich alle repositories die erven van de Interfaces die zich bevinden in de andere class library bevinden in dezelfde map.
2.Web
RD.CustomerCases.API In dit Web Project bevindt zich de api die de call’s verzorgt naar de database. In de controllers staan de verschillende call’s die kunnen uitgevoerd worden op de database. De api is zowat de baas tussen de externe en de andere clients voor de call’s naar de database. RD.CustomerCases.Extern.Web De externe website is een Single Page Application, deze maakt het mogelijk om extern (dus buiten realdolmen) alle customercases te bekijken. RD.CustomerCases.Intern.Web De interne website is een ASP.NET.net website die het mogelijk maakt om customercases te inputten, deleten en te editen. 81
Deze kan alleen maar intern gebruikt worden, niemand anders kan deze site bereiken als hij niet ingelogd is op het realdolmen netwerk. Hier onderaan ziet u een overzicht van hoe het project opgebouwd is.
Gedetailleerd Overzicht Database Layer De database die we hebben opgezet voor dit project is een SQL Server. Deze database hebben we in de cloud gezet dit op het Azure Platform. Aangezien de database in de cloud staat dienen we niet meer te piekeren over genoeg ruimte voor data, onderhoud van servers. Het enige wat we enkel in het oog moeten houden is dat we een niet al te hoge kost hebben bij de verschillende calls dat we doen naar de server. Maar dit is momenteel nog niet relevant voor ons project.
Data Access Layer Voor onze database op te zetten hebben we gebruik gemaakt van “Entity Framework Code First”. De volgende lagen die hierop volgen worden hieronder uitgelegd: 1. Entity Framework (EF) Code First heeft ervoor gezorgd dat we eerst de models zelf dienden te schrijven en daarna werd onze databse geschreven aan de hand van het EF. 2. Repository Contracts Deze interfaces zorgen ervoor dat de bepaalde signatuur behouden wordt in de Repositories. Alsook wordt hierdoor de Seperation Of Concerns (SOC) nageleefd. 3. Repositories De Repositories dienen voor het verzenden, updaten, deleten en het opvragen van de data uit de database via het EF.
Client Side Layer Externe Website structuur (MVVM) De Model-View-ViewModel-structuur (MVVM-structuur) is een architecturaal patroon en wordt vooral gebruikt om structuur te houden. Alsook wordt dit gebruikt voor te voldoen aan de Separation Of Concerns (SOC). De drie lagen van een MVVM-structuur zijn als volgt: 1. Models: Hierbij wordt het model gedefiniëerd hoe het object er zou moeten uitzien. 2. Views: Deze bevat vooral alle views die een website zou moeten aannemen. De views gebruiken technologieën zoals HTML5, CSS3, Javascript, Bootstrap en Knockout 3. ViewModels: Alle ViewModels zorgen ervoor dat de correcte weergave van de data gehanteerd wordt. De ViewModels zijn het medium tussen de Models en de Views.
82
Externe Website Technologieën De Externe Website die we gemaakt hebben is een Single Page Application (SPA). De website is opgezet geweest voor het tonen van de verschillende customercases van RealDolmen. Dit zou het mogelijk maken om nieuwe klanten te overtuigen om toch voor RealDolmen te kiezen. Deze website maakt van verschillende technologieën gebruik, bij deze zullen we deze hieronder allemaal opsommen:
Bootstrap 3 Bootstrap is een tool voor het sneller en gemakkelijker te creeëren van websites en web applicaties. Deze tool bevat enkel HTML, CSS en Javascript. Bij deze tool zijn er ook nog enkele extras bijgeleverd zoals knoppen, formulieren, .... Deze tool zorgt er ook voor dat als je een website bouwt op een computer, deze site er ook goed uitziet op een kleiner toestel zoals een GSM, Tablet,....
Javascript Javascript is een scripttaal die vaak gebruikt wordt om websites en webapplicaties interactief te maken of te ontwikkelen. Javascript kan zowel client-side als server-side gebruikt worden.Client-side Javascript wordt uitgevoerd aan de hand van de browser waarmee men werkt. Server-side Javascript wordt de javascript aan server-zijde uitgevoerd en daarna wordt het resultaat terug gestuurd naar de client.
Knockout.js Knockout.js is een Javascript bibliotheek dat je helpt bij het maken van uitgebreide, responsive schermen. Knockout.js zorgt er ook voor dat code gemakkelijker en onderhoudbaarder is. Knockout zorgt er tevens ook voordat data, zichtbare elementen en data dat dient getoond te worden zich volledig van elkaar scheiden. Knockout zorgt er tevens voor dat data gebind wordt aan de DOM elementen via het data-bind attribuut. Een data-bind attribuut kan verschillende vormen aannemen zoals text, value, html, visible, .....
83
Voor men deze kan binden dient men eerst een ViewModelaan te maken en deze dan aan Knockout te binden hieronder een voorbeeld:
In de AppViewModel bevindt zich de code die allemaal dient uitgevoerd te worden voor alles te binden.
HTML5 en CSS3 HTML5 is de nieuwste nog onafgewerkte versie van vorige HTML versies.HTML5 is een opmaaktaal en wordt gebruikt om de opmaak op te stellen voor een website. CSS3 is tevens gemaakt voor de stijl te bepalen van HTML pagina’s. Deze geven de vormen en de kleuren aan HTML pagina’s. Na de opzet van de gehele externe site hebben we deze alsook zoals de database gepublished naar het Azure Platform.
Interne Website Structuur (MVC) De Model-View-Controller (MVC) is een ontwerppatroon die het verdeelt in 3 verschillende onderdelen. De gebruikte technologie is hier ASP MVC 5. Deze verschillende onderdelen hebben verschillende verantwoordelijkheden: 1. Model: Het model geeft de representatie terug van alle informatie die dit model krijgt. De applicatie maakt gebruik van het model om data op te halen of weg te schrijven. 2. View: De verschillende views geven verschilende UI elementen terug. Dit zoals buttons, textboxen, comboboxen enzovoort. De View doet niet qua berekeningen en dergelijke de View geeft enkel data weer. 3. Controller: De controller ontvangt de verschillende acties die de gebruiker maakt op de View. De controller zorgt dan verder voor de afhandeling van die verschillende events.
84
Externe Website Technologieën De gebruikte technologieën in dit project zijn eveneens gelijk lopend zoals de SPA. De gebruikte technologieën die hier ook aanbod komen zijn Javascript, Bootstrap, HTML5 en CSS3. De documentatie is raadpleegbaar in het vorige hoofdstuk. Enkele technologieën die nog niet zijn uitgelegd worden hieronder verder toegelicht.
JQuery Jquery is een Javascript library dat het mogelijk maakt om navigatie tussen documenten, manipulatie, event handeling, animaties en ajax gemakkelijker te maken tussen de API en verschillende browsers. Aangezien de technologie geïntegreerd is in Visual Studio 2013 is dit echter niet moeilijk om deze technologie te implementeren in het project. Andere technologieën die gekoppeld zijn aan
Jquery zijn Jquery UI (die in dit project geïmplementeerd zal worden), Jquery Mobile, Qunit en Sizzle (deze worden niet geïmplementeerd in dit project).
De verschillende JQuery UI’s die gebruikt zijn, zijn Jquery UI Tabs en Jquery UI Datepicker. De eerste, Jquery UI Datepicker wordt toegepast om de data op te slaan van wanneer tot wanneer een project gelopen heeft. De Datepicker wordt ook gebruikt om de inputdatum van de customercase in te stellen. De layout van deze UI kan rechts op de foto bekeken worden.
De tweede, Jquery UI Tabs wordt toegepast om verschillende talen toe te voegen of te veranderen. Deze UI heeft als uitzicht het volgende:
85
Bijlage 4: Code voorbeelden Client InstanceFactory: using using using using using using
GalaSoft.MvvmLight.Ioc; System; System.Collections.Generic; System.Linq; System.Text; System.Threading.Tasks;
namespace RD.CustomerCases.Shared { /// <summary> /// This class wil handle all the registration of the containers and wil handle them /// You can change the SimpleIoc to another IoC container here without the need of editing the ViewModelLocators. /// public static class InstanceFactory { static readonly ISimpleIoc container; public static Dictionary Registrations = new Dictionary(); static InstanceFactory() { container = SimpleIoc.Default; } public static void RegisterType() where T2 : class where T1 : class { Registrations[typeof(T1)] = typeof(T2); container.Register(); } public static void RegisterInstance() where T1: class { container.Register(); } public static T GetInstance() { return container.GetInstance(); } public static T GetNamedInstance(string key) { return container.GetInstance(key); } } }
86
App.xaml Windows 8 RT: using using using using using using using using using using using using
RD.CustomerCases.Services.Contracts; RD.CustomerCases.Shared; RD.CustomerCases.Win8.Common; System; Windows.ApplicationModel; Windows.ApplicationModel.Activation; Windows.ApplicationModel.Resources; Windows.UI.ApplicationSettings; Windows.UI.Popups; Windows.UI.Xaml; Windows.UI.Xaml.Controls; Windows.UI.Xaml.Navigation;
// The Blank Application template is documented at http://go.microsoft.com/fwlink/?LinkId=234227 namespace RD.CustomerCases.Win8 { /// <summary> /// Provides application-specific behavior to supplement the default Application class. /// sealed partial class App : Application { /// <summary> /// Initializes the singleton application object. This is the first line of authored code /// executed, and as such is the logical equivalent of main() or WinMain(). /// public App() { if (SettingsStore.CurrentLanguage != null) { Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride = SettingsStore.CurrentLanguage; } this.InitializeComponent(); this.Suspending += OnSuspending; this.UnhandledException += App_UnhandledException; } void App_CommandsRequested(SettingsPane sender, SettingsPaneCommandsRequestedEventArgs args) { var loader = new ResourceLoader(); args.Request.ApplicationCommands.Add(new SettingsCommand(loader.GetString("languageSettings"), loader.GetString("languageSettings"), a => { SettingsFlyoutLanguage sfl = new SettingsFlyoutLanguage(); sfl.Show(); })); } async void App_UnhandledException(object sender, UnhandledExceptionEventArgs e) { var loader = new ResourceLoader();
87
NavigationService Windows 8 RT:
88
using using using using using
RD.CustomerCases.Services.Contracts; RD.CustomerCases.Shared; RD.CustomerCases.Win8.Contracts; System; Windows.UI.Xaml.Controls;
namespace RD.CustomerCases.Win8.Common { public class NavigationService : INavigationService { private Frame _rootFrame; private object _frame; public object Frame { get { return _frame; } set { _frame = value; if (_frame != null && _frame is Frame) { _rootFrame = (Frame)_frame; _rootFrame.Navigated += OnFrameNavigated; } } } public NavigationService() { } public void Navigate(Type type) { if (_rootFrame != null) _rootFrame.Navigate(type); } public void Navigate(Type type, object parameter) { if (_rootFrame != null) _rootFrame.Navigate(type, parameter); } public void Navigate(string type) { switch (type) { case PageNames.MainPage: Navigate(); break; case PageNames.SectorPage: Navigate(); break; case PageNames.SolutionPage: Navigate(); break; case PageNames.TechnologyPage: Navigate(); break;
89
App.xaml Windows Phone 8 using using using using using using using using using using using using
Microsoft.Phone.Controls; Microsoft.Phone.Shell; RD.CustomerCases.Services.Contracts; RD.CustomerCases.Shared; RD.CustomerCases.WP8.Resources; System; System.Diagnostics; System.IO.IsolatedStorage; System.Threading; System.Windows; System.Windows.Markup; System.Windows.Navigation;
namespace RD.CustomerCases.WP8 { public partial class App : Application { /// <summary> /// Provides easy access to the root frame of the Phone Application. /// /// The root frame of the Phone Application. public static PhoneApplicationFrame RootFrame { get; private set; }
/// <summary> /// Constructor for the Application object. /// public App() { // Global handler for uncaught exceptions. UnhandledException += Application_UnhandledException; // Standard XAML initialization InitializeComponent(); // Phone-specific initialization InitializePhoneApplication(); // Language display initialization InitializeLanguage(); //SystemTray.Opacity = 0; //theme ThemeManager.ToLightTheme(); ThemeManager.OverrideOptions = ThemeManagerOverrideOptions.None; //Appbar Localization //var appBar = App.Current.Resources["GlobalAppBar"] as ApplicationBar; //((ApplicationBarIconButton)appBar.Buttons[0]).Text = AppResources.Search; //((ApplicationBarMenuItem)appBar.MenuItems[0]).Text = AppResources.Languages;
// Show graphics profiling information while debugging. if (Debugger.IsAttached) { // Display the current frame rate counters. Application.Current.Host.Settings.EnableFrameRateCounter = true; // Show the areas of the app that are being redrawn in each frame.
90
NavigationService Windows Phone 8: using using using using using using using using using
Microsoft.Phone.Controls; Microsoft.Phone.Shell; RD.CustomerCases.Services.Contracts; RD.CustomerCases.Shared; RD.CustomerCases.WP8.Contracts; System; System.Text.RegularExpressions; System.Windows.Controls; System.Windows.Navigation;
namespace RD.CustomerCases.WP8.Common { public class NavigationService : INavigationService { public NavigationService() { } private PhoneApplicationFrame _rootFrame; private object _frame; public object Frame { get { return _frame; } set { _frame = value; if (_frame != null && _frame is PhoneApplicationFrame) { _rootFrame = (PhoneApplicationFrame)_frame; _rootFrame.Navigated += OnFrameNaviagetd; } } } private void OnFrameNaviagetd(object sender, NavigationEventArgs e) { var view = e.Content as IView; if (view == null) return; var viewModel = view.ViewModel; if (viewModel != null) { if(e.NavigationMode != NavigationMode.Back) { object param; PhoneApplicationService.Current.State.TryGetValue("param", out param); viewModel.Initialize(param); } } } public void Navigate(Type type) {
91
Bijlage 5: Architectuur Client project
Inleiding De architectuur hier beschreven is een luik uit het totaalproject van het RealDolmen Customer Cases showcase project. Het is de bedoeling de opgezette web API van de RealDolmen Customer Cases te gaan consumeren van uit een Windows 8 Runtime applicatie en een Windows Phone 8 applicatie. Het project biedt niet enkel de mogelijkheid te tonen aan klanten welke opdrachten RealDolmen al verwezenlijkt heeft maar het is tevens zelf een show case naar klanten toe om te laten zien wat RealDolmen kan bieden van modren UI applications binnen een .Net omgeving. De structuur van het project is zo opgebouwd dat de structuur hergebruikt kan worden in andere projecten.
Overzicht De projectstructuur van de Windows Clients zal via MVVM opgebouwd worden et een zo goed mogelijke scheiding van project structuur. Dit zal er voor zorgen dat project test-en beheerbaar blijft. Het model zal in dit geval de data logica verwerken door de Customer Cases Web API aan te spreken. Het ViewModelzal instaan voor de object conversie om deze later te binden aan de View. De opbouw zal zo zijn dat de ViewModels hergebruikt kunnen worden in beide platformen.
Inhoud clients:
Een eindgebruik zal de nieuwste case kunnen bekijken Alle case kunnen in detail bekeken worden Er kan gezocht worden via een zoekfunctie Case kunnen gegroepeerd worden op sector, oplossing en technologie Alle cases kunnen in verschillende talen bekeken worden.
De Windows 8 cliënt zal een Windows 8.1 runtime project en de Phone cliënt een Windows Phone 8 silverlight project. Dit omdat bij de opzet van het project nog geen sprake was van de Universial Apps, die aangekondigd werden in April.
92
Detail architectuur
Figuur 93 http://www.codeproject.com/KB/miscctrl/768427/mvvm.png
Model Het model zal opgebouwd zijn uit enerzijds de models die overeenstemmen met de data verkregen uit JSON1 en een services die de connectie maakt vanuit de client naar de web API.
Model object public class CustomerCase { public int ID { get; set; } public int LanguageID { get; set; } public string ProjectName { get; set; } public string PhotoCustomer { get; set; } public string CustomerName { get; set; } public string PhotoUrl { get; set; } public DateTime InputDate { get; set; } }
1
In de Web API wordt de dat via een Javascript Object Notation verstuurd
93
Services De service legt een http connectie tussen de client en de web API. De opbouw is via interface geinjecteerd zodat als de REST API morgen een WCF zou worden deze gewoon zo kan ingeplugd worden via deze interfaces.
De aaneen hechting van de service met zijn interface gebeurd via IoC2 de IoC container is die van de MVVM light library SimpleIoC genaamd. Deze is tevens generiek geïmplementeerd zodat er eventueel later van aan andere IoC container gebruik kan gemaakt worden.
2
Inversion of Control
94
ViewModel Elke View krijgt een bijpassend viewmodel, die zal instaan om data te binden in de View via zijn properties. Er zullen tevens hieruit commands toegevoegd worden zodat de uiteindelijk View zo weinig mogelijk code zal bevatten. Dit houd alles gescheiden. Eventueel kan er geopteerd worden om later unit test te schrijven voor de ViewModels. De ViewModels kunnen voor zowel het Windows 8 project als het Windows Phone 8 project hergebruikt worden3. Beide projecten maken gebruik van hun eigen viewmodellocator.
3
Dit is natuurlijk niet bij elke View het geval
95
View De View is volledig opgebouwd in XAML en wordt via een interface en datacontext voorzien van zijn data. Zodat er bijna geen code in de code-behind geschreven wordt. Zo kan de seperation of concern bewaard worden.
Door enkel naar een interface te verwijzen is er geen afhankelijkheid meer vanuit de naar de ViewModels toe en kan er zo weer een nieuwe GUI opgezet worden. De datacontext zal gebind worden uit de viewmodellocator met het juiste ViewModelgedineerd in de XAML daarna zal de NavigationService dit ViewModelaanspreken en via een methode call data initialiseren vanuit het ViewModeldie dan op zijn beurt de properties update die gebind zijn in de XAML van de View.
Navigation De navigation service is tevens zo opgebouwd dat beide projecten een enigen abstractie implementeren maar zodat beide in een gelijkaardige manier tewerk gaan. Dit wil zeggen dat er dus door een navigatie te triggeren in het ViewModelbij beide projecten een zelfde flow gebeurt. Hierdoor moet er enkel een aparte navigation service geschreven worden en niet een heel nieuw viewmodel. Omdat de navigatie tussen Windows 8 en Phone 8 verschillend is, is dit rechtgezet door op een zelfde manier te gaan navigeren in de Phone. Dit zal de navigatie doormiddel van een type based parameter gaan omzetten naar een navigation uri voor de Phone cliënt. Maar zo kan nog steeds de standaard Navigate(typeof(pagename)); gebruikt worden.
96
Home
Detail
97
Structuur opbouw Client Map structuur De cliënt solution van de RealDolmen Customer cases zal bestaan uit de Windows 8 RT en de Windows Phone 8 cliënt applicaties. We kozen hier voor volgende map structuur: Logica, contracten, de clients en de controls.
Logic Onze logic folder zal de verschillende data models en data processing projects bevatten. We spreken hier over de Models, services, shared en ViewModels. Al deze projecten zullen Portable Class Library’s zijn. Zodat deze kunnen geshared worden over de verschillende platformen.
Models Het models project zal de models leveren. Deze zullen de objecten aanleveren die we aanmaken vanuit onze API.
Services Services zal onze data gaan opvragen van de API en deze verwerken.
Shared Hierin zal men logica kunnen sharen tussen beide projecten.
ViewModels De ViewModels zullen de View voorzien van hun datacontext deze zal geshared worden over beide clients voor hergebruik. Het ViewModel project zal gebruik maken van het MVVM Light Framework.
Contracts De contracts zullen alle interfaces bevatten voor de setup van het project hierdoor kunnen we eenvoudig gebruik maken van onze Dependency Injection. De projecten die een contract zullen gebruiken zijn: Services, ViewModels, Win8 en WP8.
Clients Er zullen twee cliënt versies gebouwd worden één voor Windows 8 RT en één voor Windows Phone 8. Beide zullen over dezelfde functionaliteit binnen de Customer Cases bevatten. Vandaar de vele gesharde logica.
Windows 8 RT Het Windows 8 project zal de Windows 8 cliënt zijn. Hierin zullen we gebruik makken van het MVVM Light framework.
Windows Phone 8 Het Windows Phone 8 project zal de Windows Phone 8 cliënt zijn. Hierin zullen we gebruik makken van het MVVM Light framework. 98
Controls De controls library zal de verschillende gesharde controls bevatten die we eventueel kunnen sharen binnen beide Windows projecten.
99
Bijlage 6: Mockups
100
101
102
103
104
105
106
107
108
109
110
111
112
