Logboek
Aangezien ik druk bezig ben met het aanleren, kom ik nu ergens tegen aan te lopen waarvan ik geen idee heb hoe ik dit het beste kan aanpakken. Ik moet namelijk een logboek per klant gaan bij houden. Dit logboek is verdeeld in 3 categorieen. question, answer en overige. In deze drie moet ik dus per klant een log kunnen bijhouden. Ik heb enkel geen idee hoe ik dit het beste kan doen.
Waar loop je op vast? De datastructuur?
Ik loop vast op het bedenken van de structuur. En hoe ik dan het verwerken het beste kan doen.
Bollie Zwollie op 29/06/2018 22:54:34:
Dit logboek is verdeeld in 3 categorieen. question, answer en overige.
Dit klinkt niet echt als een logboek maar meer als een soort van ticketsysteem? Los van hoe je dit technisch aanpakt zou je eerst functioneel (dus zonder tussenkomst van enige techniek) kunnen omschrijven wat dit systeem zou moeten kunnen doen.
Als dat helemaal -of in grote lijnen- klaar is, zou je eens kunnen gaan denken hoe je een en ander technisch aanpakt. Deze aanpak (functioneel --> techniek) is ook vele malen makkelijker omdat je al hebt uitgedacht wat je allemaal zou willen doen en je hebt daarmee een blauwdruk (functionele specificatie) van wat je daarvoor zou moeten maken.
Dit zorgt ook voor een overzichtelijke scheiding (separation of concerns) tussen wat in wezen verschillende onderdelen zijn: ontwerpen en bouwen.
Vergelijk het met het bouwen van een huis. Je gaat dan toch ook geen betonnen fundament storten en simpelweg beginnen met bouwen zonder een van tevoren opgesteld plan (de eerdergenoemde blauwdruk).
Gewijzigd op 29/06/2018 23:50:26 door Thomas van den Heuvel
Toch kun je al een beetje intekenen hoe het er uit gaat zien.
Stelling: Klanten kunnen meerdere vragen stellen en op een vraag zijn meerdere antwoorden mogelijk.
Of deze stelling voor jouw "opdracht" klopt moet je voor jezelf invullen.
Indien deze klopt krijg je een tabel klanten, een tabel vragen en een tabel antwoorden.
De tabel antwoorden krijgt een kolom vraag_id zodat je hem aan een vraag kunt koppelen
De tabel vragen krijgt een kolom klant_id zodat je kan bijhouden welke vraag bij welke klant hoort.
Daarnaast kun je je afvragen hoe je je pagina's gaat inrichten. Zo zou het makkelijk kunnen zijn als een vraag op een eenvoudige manier aan een bestaande klant gekoppeld kan worden en daarnaast met een druk op de knop een nieuwe klant kan worden aangemaakt. Hierin zijn de mogelijkheden enorm groot.
Stelling: Klanten kunnen meerdere vragen stellen en op een vraag zijn meerdere antwoorden mogelijk.
Of deze stelling voor jouw "opdracht" klopt moet je voor jezelf invullen.
Indien deze klopt krijg je een tabel klanten, een tabel vragen en een tabel antwoorden.
De tabel antwoorden krijgt een kolom vraag_id zodat je hem aan een vraag kunt koppelen
De tabel vragen krijgt een kolom klant_id zodat je kan bijhouden welke vraag bij welke klant hoort.
Daarnaast kun je je afvragen hoe je je pagina's gaat inrichten. Zo zou het makkelijk kunnen zijn als een vraag op een eenvoudige manier aan een bestaande klant gekoppeld kan worden en daarnaast met een druk op de knop een nieuwe klant kan worden aangemaakt. Hierin zijn de mogelijkheden enorm groot.
Frank Nietbelangrijk op 30/06/2018 14:45:56:
Stelling: Klanten kunnen meerdere vragen stellen en op een vraag zijn meerdere antwoorden mogelijk.
Dit is functioneel, waarin de gebruikte entiteiten worden geïdentificeerd, en hoe onderlinge verbanden zijn.
Frank Nietbelangrijk op 30/06/2018 14:45:56:
Indien deze klopt krijg je een tabel klanten, een tabel vragen en een tabel antwoorden.
De tabel antwoorden krijgt een kolom vraag_id zodat je hem aan een vraag kunt koppelen
De tabel vragen krijgt een kolom klant_id zodat je kan bijhouden welke vraag bij welke klant hoort.
De tabel antwoorden krijgt een kolom vraag_id zodat je hem aan een vraag kunt koppelen
De tabel vragen krijgt een kolom klant_id zodat je kan bijhouden welke vraag bij welke klant hoort.
Dit is de technische implementatie van de functionele spec.
Frank Nietbelangrijk op 30/06/2018 14:45:56:
Daarnaast kun je je afvragen hoe je je pagina's gaat inrichten. Zo zou het makkelijk kunnen zijn als een vraag op een eenvoudige manier aan een bestaande klant gekoppeld kan worden en daarnaast met een druk op de knop een nieuwe klant kan worden aangemaakt. Hierin zijn de mogelijkheden enorm groot.
Dit is weer (min of meer) functioneel, want het beschrijft gedrag van de applicatie.
Het is logisch dat dit in elkaar overvloeit, want het een vormt het concrete verlengstuk van het ander, maar het lijkt mij handiger om deze (meer) in afzondering te behandelen. Dit omdat je dan niet op voorhand wordt beperkt door techniek, en je het (ideale) plan voor je applicatie eerst uitstippelt en verfijnt. Nadat je daar een aantal iteraties in hebt gemaakt, met mogelijk wat technische uitstapjes in de vorm van proof-of-concepts kun je de nadruk meer gaan leggen op het daadwerkelijk implementeren. Maar ik zou eerst een goed plan uitdenken voordat je code gaat kloppen... anders zijn de trips terug naar de tekentafel waarschijnlijk een stuk onaangenamer.




