4-tiers, hoe werkt het.. metaforisch....een vraag (ASP-NET)

[anoniem]

bij voorbaat mijn excuses als ik de vraag hier verkeerd geplaatst heb. Ik probeer het concept van n-tiers de doorgronden en heb diverse voorbeelden doorgespit. Maar...misschien snap ik het concept 4-tiers wel helemaal verkeerd…. Een metaforisch voorbeeld dan maar: een Directeur van een groot bedrijf wil uit het magazijn een doos koekjes hebben. Hij heeft bezoek en wil dit nieuwste product tonen aan de bezoeker op zijn kantoor. De bezoeker is namelijk nieuwsgierig naar het nieuwe product…veel over gehoord maar nog nooit in het echt gezien..bla..bla. De directeur (laag 4 de UI), want hij toont het product en gaat een dialog aan met de User) roept zijn secretaresse (laag 3) erbij, vertelt haar het verzoek en geeft haar de opdracht en eindigt met de zin: regel dat!! De secretaresse weet alles van het bedrijf en kent iedereen en regelt dus alles (Business Rules). Maar de secretaresse komt zelf niet op de werkvloer (lees in het magazijn) want ze weet niet waar het product – de koekjes - precies ligt en belt daarom naar de magazijnbeheerder (laag 2, ) De magazijnbeheerder kent niet alleen het magazijn op zijn duimpje en weet de locatie van elk product, maar kent ook elke magazijnmedewerker (laag 1) en weet wie hij moet hebben om het product uit een bepaald gedeelte van het magazijn te halen. Zo haalt aldus de magazijnmedewerker het product uit de stelling, klopt netjes op de deur van de magazijnbeheerder en nadat die gezegd heeft ‘binnen’ vindt de uitwisseling plaats (geeft het aan de magazijnbeheerder), die loopt naar de secretaresse, klopt netjes aan en na de woorden “kom binnen” vindt de uitwisseling plaats. Vervolgens brengt de secretaresse de koekjes bij de directeur. Mijn conclusie is dat er 4 lagen (tiers) nodig zijn om aan de bezoeker de koekjes te tonen. Hoe kom ik er bij? Als er bezoek komt hoeft een secretaresse het niet in haar hoofd te halen om een nieuw product aan de bezoeker te tonen zonder dat de directeur dat wil. Immers, misschien komt die bezoeker voor heel iets anders en ziet de directeur dit als een verstoring. De magazijnbeheerder en de magazijnmedewerker hoeven het al helemaal niet te flikken. De secretaresse hoeft ook niet te proberen de magazijnmedewerker een opdracht uit te laten voeren want dan passeert zij de magazijnbeheerder die uitmaakt wie welke werkzaamheden in het magazijn verricht Stel dat zij een magazijnmedewerker direct benadert maar die werkt helemaal niet in het gedeelte waar de koekjes liggen… Nu naar een webapplicatie omgezet en even van de omgekeerde beweging uit bekeken. De magazijnmedewerker heeft de middelen (scanner, heftruck etc. in handen om een artikel te pakken) de connectie met het magazijn, de database. Hands-on, hij pakt fysiek het artikel De magazijnbeheerder vertelt hem DAT hij een artikel moet pakken (Select-statement) De secretaresse bepaalt wie een opdracht moet uitvoeren .i.d.g. de magazijnbeheerder en vertelt WAT hij moet pakken (Business Rules) De directeur geeft de opdracht op verzoek van de bezoeker. DIT IS hoe IK het zie. Het is voor MIJ dus helemaal niet zeker dat het ook precies zo bedoeld is en dat het zo werkt. Wat is op dit moment mijn probleem…. Ik kan op dit moment het alleen maar voor elkaar krijgen dat de directeur de koekjes rechtstreeks van de magazijnmedewerker krijgt. Ik krijg het dus niet voor elkaar dat de magazijnmedewerker de koekjes eerst aan de magazijnbeheerder geeft die het vervolgens aan de secr…etc… Want de magazijnmedewerker, magazijnbeheerder en secretaresse zijn van type CS (Class) en ik krijg het niet voor elkaar dat de ene Class iets doorgeeft aan een ander Class. Nogmaals, de directeur is van het type ASPX. En een CS en een ASPX-document communiceren wel samen maar een CS-document en een CS-document niet. Tenminste, IK krijg die uitwisseling niet voor elkaar. Nou, vermakelijk voorbeeld wellicht, nu graag een oplossing…of juist een heel ander voorbeeld waaruit blijkt hoe het werkelijk in elkaar steekt… Graag een antwoord want zonder een antwoord kom ik niet verder..en als het kan in de vorm zoals ik gebruikt heb....dus van de directeur en zijn koekjes :lol:

[anoniem]

Zo, dat is een flink verhaal. Het duizelt me nog steeds van alle koekjes ;) Even vooraf, om misverstanden te voorkomen: met dieper en hoger liggende lagen bedoel ik dat de hoger liggende lagen meer aan de oppervlakte van de applicatie liggen (dus UI is toplaag). Er zijn mensen die juist de andere kant op redeneren. Met een [i:225ae378a9]manager[/i:225ae378a9] bedoel ik een conceptueel iets. De manager regelt alle zaken aangaande een entiteit (dus opvragen van de gegevens, bewerkingen daarop, wegschrijven van gewijzigde gegevens). Volgens mij denk je op dit moment de verkeerde kant op. Een dieper liggende laag mag nooit wat (rechtstreeks) 'geven' aan een hoger liggende laag; die laag weet namelijk niets af van het bestaan van een hoger liggende laag. Het is juist andersom: een hoger liggende laag [b:225ae378a9]vraagt[/b:225ae378a9] gegevens op van de laag onder hem. Bijvoorbeeld [code:1:225ae378a9] Database | DAL | BL | UI ----------------------------------------------------------------- tblKoekje <= KoekjeEntiteit <= KoekjeManager <= aspx pagina [/code:1:225ae378a9] Je wil op de aspx pagina de gegevens van een koekje laten zien. Dus je vraag aan de KoekjeManager om het koekje op te halen. Deze [i:225ae378a9]manager[/i:225ae378a9] kan hier nog wat regels aan verbinden (bijv. bij het opvragen van een koekje mogen geen koekjes die over de THT-datum zijn gegaan worden teruggegeven). De manager gebruikt de DAL om gegevens uit de database te halen. In halve pseudocode (ik ben geen c# programmeur) wordt dat dan: [code:1:225ae378a9] // in je aspx codebehind KoekjeManager m = new KoekjeManager(); Koekje k = m.getLaatsteKoekje(); [/code:1:225ae378a9] In de codebehind van je aspx moet je dan wel een "referentie" naar de KoekjeManager aanbrengen, zodat deze weet wat een KoekjeManager is. Dat doe je met een [i:225ae378a9]using[/i:225ae378a9] (om de namespace toe te voegen). Voor KoekjeManager geldt dan weer dat deze uit de namespace van de DAL de juiste entiteit kan ophalen. Enzovoort. Hopelijk heb ik het correct uitgelegd en is het ook een beetje duidelijk. Ik ben namelijk zoals gezegd geen c# programmeur. En ken alleen de basisbeginselen. En na zo'n post kan ik natuurlijk alleen maar afsluiten met: "Koekje d'r bij?" :D

[anoniem]

Ik ben blij dat Annie antwoord. :lol: Het is precies zoals jij zegt en zo bedoel ik het dus ook. De directeur vraagt aan de secretaresse, zij aan de magazijnbeheerder en hij aan de magazijnmedewerker. In jouw voorbeeld. [code:1:82532379e6] Database | DAL | BL | UI ----------------------------------------------------------------- tblKoekje <= KoekjeEntiteit <= KoekjeManager <= aspx pagina magazijnmed. <= Magazijnbeh. <= Secr. <= directeur [/code:1:82532379e6] Mijn probleem is dat ik de directeur wel iets aan de secr of aan de beheerder of aan de mag.medewerker kan laten vragen maar dat ik het niet voor elkaar kan krijgen dat de secr. iets aan de beheerder vraagt...of de beheerder iets aan de magazijnmedewerker. Het heeft weinig tot helemaal niets met de taal C# te maken overigens. Het gaat er mij om dat een Class niets doorgeeft aan een andere Class. Herstel, een Class kan niets vragen aan een andere Class. Kijk, eigenlijk is het probleem simpel. In een video wordt uitgelegd hoe je een Class aanmaakt en hoe je in die Class een waarde toekent aan een Field. Dat Field heeft properties. Je kunt in die class bijvoorbeeld aan een Field automerk de waarde "Opel" toekennen. Nu kan ik in een aspx-bestand (met of zonder code-behind-bestand, dat doet niet terzake) die waarde opvragen (je hebt gelijk Annie, zo is het) Maar nu wil ik in de ene Class bijvoorbeeld de waarde "Opel" toekennen en in een andere Class die waarde opvragen...en dan vervolgens die waarde weer opvragen in de ASPX. Dus: Class A aanmaken van het veld automerk, toekennen waarde "Opel" Class B aanmaken, die vraagt aan Class A de waarde uit het veld automerk op = "Opel" En tenslotte vraagt het ASPX-bestand aan Class B de waarde "Opel" op. En dát lukt me niet. Dus nogmaals: Class A maakt een veld aan en vult het met "Opel" en het ASPX-bestand vraag die waarde op uit Class B, die het opgevraagd heeft uit Class A. Wo...typekramp :lol:

[anoniem]

Als ik zo snel kijk (moet over paar min weg), dan heb je het volgens mij over overerving. Een class kan de eigenschappen van een andere class erven (of een bepaalde interface implementeren). Maar dat is iets anders dan wat ik eerder beschreef. Overerving is bijvoorbeeld iets als: de secretaresse en de magazijnbeheerder zijn beide personeelslid. Je hebt dus een algemene class Personeelslid en de class Secretaresse en de class magazijnbeheerder erven hier van. [code:1:bc64402f6a] public class Secretaresse : Personeelslid { // enz. } [/code:1:bc64402f6a] Wat jij wil bereiken (denk ik dan), en wat ik beschreef, is een opdeling in verschillende lagen (tiers) en de communicatie daartussen. Een aspx is overigens nooit een bepaalde BusinessEntiteit (bijv. Directeur). Dus die gedachte/metafoor moet je vergeten. p.s. Je moet eigenlijk niet zo blij zijn dat ik reageer, hoor ;) Mijn kennis van deze materie is niet compleet (ben geen developer (meer)). Het zou dus mooi zijn als iemand met wat meer ervaring mijn klok-klepel verhaal zou kunnen verifiëren/aanvullen/verbeteren. p.s.2: voorbeelden (mocht je deze nog niet kennen): http://www.dotnetjunkies.com/quickstart/aspplus/doc/businessobjs.aspx

[anoniem]

[quote:c283b49407]Wat jij wil bereiken (denk ik dan), en wat ik beschreef, is een opdeling in verschillende lagen (tiers) en de communicatie daartussen. [/quote:c283b49407] Exact! Ik heb het in de titel ook over 4-tiers :lol:\ Het gaat mij om de communicatie tussen die 4 tiers (lagen) [quote:c283b49407]p.s.2: voorbeelden (mocht je deze nog niet kennen): http://www.dotnetjunkies.com/quickstart/aspplus/doc/businessobjs.aspx[/quote:c283b49407] YES, dat is uhm... :lol: :lol: :lol:

[anoniem]

Dan moet je het dus doen zoals ik het beschreef. Je instantieert telkens een bepaald object uit de andere laag en roept daarvan een methode aan om de gegevens (een bepaalde waarde/object of een collectie) op te halen. Automatisch toekennen van gegevens door overerving zou hier niet "zuiver" zijn. Een koekje is namelijk geen eigenschap van Secretaresse of Magazijnbeheerder, dus dat kan je niet overerven. /edit: oh, ik zie nu pas dat je de link gevonden hebt. Succes.

[anoniem]

Nee, nee, ik heb hem helemaal door, zo gaat ie goed :lol: Wat ik in dit voorbeeld zie is de USING en de NAMESPACE. Dat ontbrak er gewoon aan. Hartstikke bedankt.

[anoniem]

[quote:e786d2607d="Wiep Corbier"]Wat ik in dit voorbeeld zie is de USING en de NAMESPACE. Dat ontbrak er gewoon aan. [/quote:e786d2607d] had ik ook al in mijn eerste post gezegd ;) btw. het toevoegen van een namespace in een aspx pagina of control (ascx) doe je met een import directive (mocht je dat nog eens nodig hebben en het nog niet bent tegengekomen in de voorbeelden) [code:1:e786d2607d] <%@ import namespace="Foo.Bar" %> [/code:1:e786d2607d]

[anoniem]

Yep, ik heb nog één probleem. Die link die je me gaf daar staat een 3-tier voorbeeld. Die heb ik nagemaakt maar 1 ding is me niet duidelijk. In de BusinessLayer staat data = new DataObj(System.Configuration.ConfigurationSettings.AppSettings["GTGString"].ToString()); Waar the f**k komt die [b:dc2dc31fb9]GTGString[/b:dc2dc31fb9] vandaan? Oh, volgens mij zie ik het al....de appSettings (key) vanuit de Web.Config

[anoniem]

YES, het werkt!!!! Die Annie, daar heb je nog eens iets aan - al is het maar de juiste link. :lol: THANKS

[anoniem]

Even voor de n00b... (that would be me) :D @Annie: waar staan DAL en BL voor? - Bas

[anoniem]

Waar staan DAL en BL voor? Data Access Layer Business Layer

[anoniem]

Bedankt! Weer wat geleerd... ;) - Bas

[anoniem]

En dan heb je natuurlijk ook nog de Data Tier en de UI. En zo kom je op 4 Heb het nog niet uitgeprobeerd maar ik wil straks eens kijken of ik in de Business Layer alle properties van TextBoxen, Labels etc kan aanpassen. Dan kan iemand die een UI interface maakt gewoon wat van die controls op een webform knallen en vervolgens bepaalt de BL hoe het er allemaal uit komt te zien. Lijkt me prachtig. :lol:

[anoniem]

Klopt het dat dit allemaal ook heel direct met OOP te maken heeft? Ik bedoel, de GUI roept methoden/functies aan in een ander object, dat op zijn beurt weer andere instanties van objecten aanroept enzovoorts... En dan dat overerven van dingen, klinkt heel bekend, dat heeft toch met interfaces (als in de speciale class) te maken? Hmmm, te lang geleden dat ik hier veel mee bezig ben geweest... Klinkt wel weer heel erg verleidelijk. Ga binnenkort maar weer eens het een en ander aan kennis ophalen. Wiep & Annie, bedankt voor deze impuls! ;P - Bas

[anoniem]

Dan heb ik nog twee hele leuke links voor je: (video's) http://lab.msdn.microsoft.com/express/beginner/default.aspx http://lab.msdn.microsoft.com/express/vwd/videos/default.aspx Kun je lekker achterover leunend je kennis ophalen/verfrissen. :lol:

[anoniem]

[quote:a4c1467ae4="Wiep Corbier"]Heb het nog niet uitgeprobeerd maar ik wil straks eens kijken of ik in de Business Layer alle properties van TextBoxen, Labels etc kan aanpassen.[/quote:a4c1467ae4]Daarmee haal je natuurlijk wel het principe onderuit, de Business Layer mag in principe niet weten hoe de GUI eruit ziet.

[anoniem]

[quote:c44809ea29="BasHamar"]En dan dat overerven van dingen, klinkt heel bekend, dat heeft toch met interfaces (als in de speciale class) te maken?[/quote:c44809ea29]Nee, interfaces zijn min of meer een beschrijving waaraan een klasse (die de interface implementeerd) aan *moet* voldoen. Overerven doe je van andere klasses, je kan dus overerven van een bepaalde klasse (in sommige talen zelfs van meerdere klasses tegelijk, maar in C# kan dat helaas niet) en ondertussen een interface implementeren. Snap je het nog? ;)

[anoniem]

anders ga je lekker flashen BasHamar. Kun je je javascript kennis gebruiken, maar wel gebruik maken van ecmascript4 die notie heeft van classes overerving, interfaces, strong typing etc. en een duidelijke scheiding tussen GUI, code en content, zodat je dit soort principes mooi kunt toepassen. en het maakt de stap naar ASP.NET met JScript.NET makkelijker, al heb ik het gevoel dat dit eigenlijk vrij weinig wordt gebruikt (wat ik vrij verbazend vind, is hier een goede reden voor?)

[anoniem]

[quote:a8362c70fc="Annie"]Als ik zo snel kijk (moet over paar min weg), dan heb je het volgens mij over overerving. Een class kan de eigenschappen van een andere class erven (of een bepaalde interface implementeren). Maar dat is iets anders dan wat ik eerder beschreef. Overerving is bijvoorbeeld iets als: de secretaresse en de magazijnbeheerder zijn beide personeelslid. Je hebt dus een algemene class Personeelslid en de class Secretaresse en de class magazijnbeheerder erven hier van. [code:1:a8362c70fc] public class Secretaresse : Personeelslid { // enz. } [/code:1:a8362c70fc] Wat jij wil bereiken (denk ik dan), en wat ik beschreef, is een opdeling in verschillende lagen (tiers) en de communicatie daartussen. Een aspx is overigens nooit een bepaalde BusinessEntiteit (bijv. Directeur). Dus die gedachte/metafoor moet je vergeten. Mijn kennis van deze materie is niet compleet (ben geen developer (meer)). Het zou dus mooi zijn als iemand met wat meer ervaring mijn klok-klepel verhaal zou kunnen verifiëren/aanvullen/verbeteren.[/quote:a8362c70fc] Klopt. De vergelijking van Wiep klopt niet. De magazijnmed, Magazijnbeh, Secr en directeur horen allemaal in de DAL thuis. [code:1:a8362c70fc] +--------------------------------+ | Database | | /\ | | database | | \/ | (Database server) +--------------------------------+ | /\ | | | | \/ | | Data Access Layer | Namespaces/classes, objecten, etc. | /\ | | (Web server) | | \/ | +--------------------------------+ | /\ | | | | \/ | | Business Layer | .cs/.vb | /\ | | (Web server) | | \/ | +--------------------------------+ | /\ | | | | \/ | .aspx | User Interface | (Browser client) +--------------------------------+ [/code:1:a8362c70fc] Er zit altijd een overlap tussen de verschillende lagen. Het is ook maar net hoever je wilt gaan. De .cs hoort eigenlijk bij de .aspx. Vanuit de .cs beinvloed je de userinterface. Daarnaast moet de business layer de verschillende componenten/classes tot een werkbaar geheel maken. Op een andere manier is het volgens mij bijna niet op te lossen, of in ieder geval niet gebruikelijk. Als je niet bekent bent met object georienteerd programmeren, zie je heel vaak dat de data access layer ontbreekt. Met mogelijk spaghetti code tot gevolg. In het 'ideale geval' zou je de implementatie van een laag moeten kunnen veranderen, zonder dat de andere lagen daar hinder van ondervinden. Maar ja, iedereen weet dat de theorie en de praktijk ver uit elkaar liggen 8)