[alg] enterprise applicatie - totaal oplossing.

[Scare360]

Standaard oplossingen:

EntityBroker
Objectz.NET

nog zoiets: http://www.pragmatier.com/

[ Voor 12% gewijzigd door Scare360 op 12-02-2003 11:48 ]

[Alarmnummer]

Dit zijn alleen OR-mappers en niet 'volledige' oplossingen. Java heeft ook allemaal van dit soort tools: OJB, JDO, EJB-CMP, Toplink.

ps: totaal oplossingen zijn niet mogelijk omdat er idd te veel diversiteit aan eisen is.

[ Voor 4% gewijzigd door Alarmnummer op 11-02-2003 22:42 ]

[EfBe]

Alarmnummer schreef op 11 February 2003 @ 21:28:
Maar als je dus werkt met een stateless applicatie dan hou je dus nooit objecten zelfs in het geheugen? Als je bv een houttype hebt, met een bijbehorende prijs, dan ga je die iedere keer opnieuwe uit de database halen of ga je hem toch cachen (met als gevolg dat je wel met een dirty houttype kan blijven zitten omdat er tussentijd een update is geweest mbt de prijs).

Als je houttype nodig hebt, haal je dat op uit de database ja. In sommige theoretische situaties wellicht trager, maar de keerzijde van de medaille is dat je de data in een centrale storage moet opslaan buiten de database, die threadsafe is. In een webapplicatie is die er eigenlijk niet, behalve de database. Je verlost jezelf bij een stateless app tevens van de sync rompslomp en vergis je niet, die is erg complex.

En op dit moment zit ik nog met een andere applicatie in mijn hoofd. Ik heb ooit eens een applicatie gemaakt waarin je trappen kon samenstellen en deze trap objecten waren vrij complex. Ik loop hier nog regelmatig over na te denken om dat ik zo 1001 dingen weet die voor verbetering vatbaar zijn.
Ik zou het logischer vinden om deze objecten gewoon in het geheugen van mijn applicatie te houden omdat er bv ook van alles gevisualiseerd moet worden en dan pas aan het einde in 1 run te gaan saven. Ik weet verder wel dat alle trap objecten naar de database gestuurd kunnen worden, en dat bv de houttypes niet gesaved hoeven te worden (daarvoor moet je ergens anders zijn), maar dan moet je overal weer rekenining mee houden. En verder is het niet overal even duidelijk.

Je kunt per user wel dingen bewaren, die behoren dan tot de userstate, bv de stappen van een wizard. Maar je moet t.a.t. voorkomen dat je data die gedeeld moet kunnen worden tussen users (dus A wijzigt info en B heeft die gewijzigde info nodig) in memory gaat houden, want dat wordt te complex om efficient en onderhoudbaar te bouwen: code heeft dan niet 1 bron van gegevens maar een veelvoud.

Je kunt bij een stateless applicatie besluiten static data te cachen, dus lookup tables in memory te houden, waarbij je weet dat die tables niet wijzigen, of alleen bij hoge uitzondering en je dan de app herstart, zodat bv bij het volgende request alles opnieuw in cache wordt geladen. Echter, dit zijn noodgrepen, je design moet zonder dat soort dingen kunnen en zonder die noodgrepen solide in elkaar zitten. Stateful applicaties vallen bijna altijd om, tenzij het een 1 of 2 tier appje is op iemands desktop, single user.

[EfBe]

paulgielens schreef op 11 February 2003 @ 22:33:
Standaard oplossingen:
Objectz.NET

Whoa, als dat niet traag is als dikke kak in een te nauwe trechter dan weet ik het ook niet meer

[Verwijderd]

Sorry ff semi offtopic

Heb je toevallig linkjes naar die Delphi frameworks (behalve Bold), heb wel eens en ander gezien maar dat stelde allemaal niet zoveel voor.

LordLarry schreef op 11 February 2003 @ 10:29:
Er worden weldegelijk kant en klare raamwerken geleverd. Vaak alleen niet de presentatie laag, omdat dit zeer kan verschillen per programmeertaal. Delphi heeft wel enkele complete raamwerken op dat gebied.

[Scare360]

EfBe schreef op 11 februari 2003 @ 22:55:
[...]

Whoa, als dat niet traag is als dikke kak in een te nauwe trechter dan weet ik het ook niet meer

Beargumenteer dat eens. Niet dat het niet zo is, maar toch...

[PhoneTech]

paulgielens schreef op 11 February 2003 @ 22:33:
Standaard oplossingen:

EntityBroker
Objectz.NET

Heb daarnet even Objectz.NET geinstalleerd....wat een *** programma zeg!

Het ziet er niet uit, werkt erg [b]on[b]overzichtelijk, en doet volgends bijna precies het zelfde als LLBLGen (die wel gratis is)

Ik begin een dezer dagen met een eigen generator, omdat geen van alle de features heeft die ik nodig heb...Ik zou het in de gaten houden!

Ik heb zo het idee dat het allemaal nog veel en veel beter kan met de DAL generatoren.

Met het maken / genereren van een DAL laag hou je meestal geen rekening met de GUI, daar komt bij mij de BLL bij kijken die de data in een mooie vorm giet om zo de GUI te voorzien van data. Daarom denk ik ook dat de GUI en de BLL eigenlijk voor elk project specifiek zijn en niet makkelijk te genereren zijn (deel ik nu Efbe's mening?)

Otis (of Efbe, i'm a bit confused) is bezig met LLBLGen 2.0. Ik ben zeer benieuwd wat daar uit komt.

Ik denk in de Enterprise ontwikkeling, dat DAL generatoren bijna onmisbaar zijn in .NET omdat het zo veel werk scheelt.
Misschien zijn er componenten die je makkelijk in een BLL kan zetten. Hierbij denk ik aan Principal objecten met meer informatie dan alleen de userid en de rollenstrings.

edit: Added bold on, omdat het overzichtelijk niet echt bij mijn rant past

[ Voor 4% gewijzigd door PhoneTech op 12-02-2003 08:41 ]

[EfBe]

paulgielens schreef op 11 February 2003 @ 23:24:
[...]
Beargumenteer dat eens. Niet dat het niet zo is, maar toch...

Mapping is nog tot daar aan toe, als je de mapping maar in compiled code hebt. (dus bv een class die datatable fields copieert naar class properties en vice versa). Hier echter gebruiken ze XML voor de mapping. Bij elk gebruik van de mapping moet je dus de XML doorploegen, om de mappings tot stand te brengen. Nu weet ik het niet, maar dat is toch wel erg veel overhead. Sommige LLBLGen gebruikers zitten met tables met meer dan 100 kolommen. (!) Dat performt voor geen meter met grote XML files die bij elk access moeten worden geinterpreteerd. Het idee van die mappings is goed en logisch, het zou alleen niet in xml moeten worden uitgevoerd maar in code die gecompileerd wordt in het project.

[Scare360]

EfBe: ben ik het helemaal mee eens, daarom gebruik ik ook uitsluitend de LLBLGen (aangepaste versie "to fit my needs".

PhoneTech: inderdaad, de LLGLGen is zeker zo functioneel alleen het design van LLBLGen is niet geschikt voor zware modificaties en zal dus gedurende de life-cyle niet veel meer veranderen kwa opzet. De LLBLGen 2.0 zal geen open-source meer zijn. Ik ben bang dat indien Otis geen "demo" versie released veel bedrijven de sprong niet durven te maken, tenzij er duidelijke voordelen zijn tov de 1.0 versies.

[EfBe]

Uiteraard komt er een demo. Maar trust me, de voordelen zullen je wel bekoren (en hij gaat geen grof geld kosten zoals de concurrentie)

Op de DOTNET-CLR mailinglist van developer.com overigens loopt dezelfde discussie: iemand die op zoek is naar een framework voor persistent objects voor gebruik in grote applicaties. Een developer van EntityBroker wees al op hun eigen product . Wat ik opmaak uit de woorden van de persoon die er om vroeg was dat het kennelijk toch niet zoveel uitmaakt of de mapper-tool trage code oplevert, als het maar gemakkelijk is, dus veel tijd bespaard. Ik snap dat aan de ene kant wel, maar aan de andere kant vind ik het ook weer een wel erge hang naar gemakzucht ten koste van wel heel zware offers.

[Scare360]

Ik denk dat er eerder behoefte is aan een "real-life" example. Alle voorbeelden op MSDN zijn web-based en vaak toch_net iets anders dan je in het normale leven tegen komt.

Een demo applicatie n-tier (DAL, OOP, BLL, BFAC, USL (desktop & web) zou wenselijk zijn.

[whoami]

paulgielens schreef op 12 February 2003 @ 09:19:
Ik denk dat er eerder behoefte is aan een "real-life" example. Alle voorbeelden op MSDN zijn web-based en vaak toch_net iets anders dan je in het normale leven tegen komt.

Een demo applicatie n-tier (DAL, OOP, BLL, BFAC, USL (desktop & web) zou wenselijk zijn.

Daar zou men mij ook een plezier kunnen mee doen....

Ik heb eens IBuySpy portal van MS bekeken, maar daar ben je echt niks mee als voorbeeldapplicatie. Er zit geen business-logic in, er is zelfs geen BL-layer.

Ik zou ook wel eens een 'real-life' example willen zien van een n-tier enterprise application met de nodige layers en hoe de communicatie tussen die layers is.

[Verwijderd]

paulgielens schreef op 12 February 2003 @ 09:19:
Een demo applicatie n-tier (DAL, OOP, BLL, BFAC, USL (desktop & web) zou wenselijk zijn.

Microsoft hanteert in de praktijk een redelijke minimalistische kijk op N-tier ontwikkeling. Beste voorbeeld hiervan is de Microsoft her-implementatie van de J2EE Petstore. Waar Sun koos voor een theoretisch heel mooi N-tier model gebasseerd op EJB's koos Microsoft voor een meer praktische oplossing.

De resultaten waren duidelijk: dramatisch beter perf en, misschien nog wel belangrijker, grote verschillen in de LOC (lines of code) nodig om dezelfde functionaliteit te bouwen.

Moraal van het verhaal: in veel gevallen zijn N-tier applicaties een hele goede oplossing om complexe problemen op te lossen, maar gebruik geen N-tier "for N-tier's sake": voor heel veel scenario's is een simpele 2-tier oplossing (GUI-DB) voldoende, zeker als je bijv. met ASP.NET of WinForms al een scheiding kunt maken tussen GUI design en events, waardoor je misschien zou kunnen spreken van een 2.5 tier oplossing: (GUI(Events)DB).

Dat doet natuurlijk niets af aan het feit dat het slim is om goed naar architectuurvoorbeelden te kijken en waar nodig deze te gebruiken in je eigen applicaties, wat ik wil zeggen is dat in dit soort discussies het KISS principe (Keep It Simple, Stupid) vaak vergeten wordt.

[whoami]

Verwijderd schreef op 12 February 2003 @ 17:31:
[...]


Microsoft hanteert in de praktijk een redelijke minimalistische kijk op N-tier ontwikkeling. Beste voorbeeld hiervan is de Microsoft her-implementatie van de J2EE Petstore. Waar Sun koos voor een theoretisch heel mooi N-tier model gebasseerd op EJB's koos Microsoft voor een meer praktische oplossing.

De resultaten waren duidelijk: dramatisch beter perf en, misschien nog wel belangrijker, grote verschillen in de LOC (lines of code) nodig om dezelfde functionaliteit te bouwen.

MS heeft die ombouwing 'verneukt' om de snelheid van .NET aan te tonen. Niet om een goed n-tier applicatie op te zetten.

Moraal van het verhaal: in veel gevallen zijn N-tier applicaties een hele goede oplossing om complexe problemen op te lossen, maar gebruik geen N-tier "for N-tier's sake": voor heel veel scenario's is een simpele 2-tier oplossing (GUI-DB) voldoende, zeker als je bijv. met ASP.NET of WinForms al een scheiding kunt maken tussen GUI design en events, waardoor je misschien zou kunnen spreken van een 2.5 tier oplossing: (GUI(Events)DB).

Hier ben ik het niet geheel mee eens. N-tier zorgt ervoor dat je veel 'onafhankelijker' werkt. Als je naast een Web interface ook een Windows of Mobile interface nodig hebt, dan hoef je enkel een presentatie laag te schrijven voor deze UI's. Als je data uit andere gegevensbronnen moet kunnen halen, dan hoef je enkel voor die data-sources een bijkomende data-layer te schrijven.
Als je echter ook business logica opneemt in de WinForms of in de WebForms (in de presentatie-laag dus), dan heb je gewoon veel meer werk als er een nieuwe presentatie-laag bijkomt. Je hebt dan trouwens ook geen duidelijke scheiding meer.
Martin Fowler geeft in z'n boek trouwens een voorbeeldje;
Stel, je hebt een applicatie die orders beheert van klanten. Stel dat je de klanten die een ordertotaal hebben van > 10000 euro in het groen wilt zetten, waar (in welke laag) ga je dat doen, en waarom?
Hoe zou jij daar op antwoorden?

Dat doet natuurlijk niets af aan het feit dat het slim is om goed naar architectuurvoorbeelden te kijken en waar nodig deze te gebruiken in je eigen applicaties, wat ik wil zeggen is dat in dit soort discussies het KISS principe (Keep It Simple, Stupid) vaak vergeten wordt.

't Is maar te zien wat je simpel vind. Als je een duidelijke scheiding tussen de verschillende lagen simpel vind, dan moet je het zo doen. Het verhoogt alleszins het abstractie-niveau.
Als jij een bestaande webapplicatie ook naar een Windows versie moet porten, dan ga je veel werk hebben als die applicatie niet in lagen opgebouwd was.

[Verwijderd]

whoami schreef op 12 February 2003 @ 17:56:
[...]
MS heeft die ombouwing 'verneukt' om de snelheid van .NET aan te tonen. Niet om een goed n-tier applicatie op te zetten.

Dat ligt er maar net aan van welke kant je het bekijkt. Je zou ook kunnen zeggen dat Sun's Petshop, die inderdaad als reference applicatie zo in elkaar is gezet dat veel 'best practices' op het gebied van enterprise applicaties erin gebruikt zijn, misschien wel overkill was op dat gebied.

Hartstikke leuk hoor, al die layers, maar denk je nou echt dat het dhr. McNealy (de eigenaar van de Sun Petshop ) een moer kan schelen dat zijn Petshop helemaal perfect multitier is opgezet? Ik denk dat hij eerder jaloers is op de Petshop van dhr. Gates aan de overkant, die op dezelfde hardware een veelvoud van het aantal transacties kan uitvoeren terwijl de applicatie aanmerkelijk goedkoper is (ervan uitgaande dat >LOC == >prijs, een hele redelijke aanname toch?)

N-tier zorgt ervoor dat je veel 'onafhankelijker' werkt. Als je naast een Web interface ook een Windows of Mobile interface nodig hebt, dan hoef je enkel een presentatie laag te schrijven voor deze UI's. Als je data uit andere gegevensbronnen moet kunnen halen, dan hoef je enkel voor die data-sources een bijkomende data-layer te schrijven.
Als je echter ook business logica opneemt in de WinForms of in de WebForms (in de presentatie-laag dus), dan heb je gewoon veel meer werk als er een nieuwe presentatie-laag bijkomt. Je hebt dan trouwens ook geen duidelijke scheiding meer.

Mijn punt is: Soms (vaak?) is die mooie scheiding niet nodig. Kijk eerst goed naar de applicatie die je moet bouwen om te beoordelen of de N-tier aanpak de juiste is. Ik denk dat we het wel eens kunnen worden dat de N-tier aanpak pas bij een bepaald complexitieitsniveau zijn vruchten gaat afwerpen. Onder dat niveau is het vooral lastig: veel extra code (ref:Petshop), veel extra complexiteit, minder performance.

Uitgangspunt voor de te bouwen applicatie is niet 'hoe kan ik mijn applicatie zo goed mogelijk in elkaar zetten' maar 'hoe kan ik mijn klant zo goed mogelijk van dienst zijn'. De beste technische oplossing is niet noodzakelijkerwijs ook de beste 'business' oplossing: dat is pas Business Logic .

Laat voorop staan dat dit vooral geen betoog is tegen N-tier ontwikkelen, ik ben volledig overtuigd van de voordelen van die aanpak, mits op de juiste tijd en plaats gebruikt.

Martin Fowler geeft in z'n boek trouwens een voorbeeldje;
Stel, je hebt een applicatie die orders beheert van klanten. Stel dat je de klanten die een ordertotaal hebben van > 10000 euro in het groen wilt zetten, waar (in welke laag) ga je dat doen, en waarom?
Hoe zou jij daar op antwoorden?

BLL bevat de juiste methoden om de informatie op te vragen, zeg maar:

code:

Customer[] GetCustomersByTurnover() {...}

Frontend bevat de 'logica' om de klanten met een ordertotaal van >10000 groen te maken, als je dat in de BLL zou stoppen begrijp je duidelijk niet waar je mee bezig bent. Wat natuurlijk wel zou kunnen is een methode die de 'groene' klanten apart teruggeeft uit de BLL, omdat deze blijkbaar een bijzonder betekenis voor het bedrijf hebben.

't Is maar te zien wat je simpel vind. Als je een duidelijke scheiding tussen de verschillende lagen simpel vind, dan moet je het zo doen. Het verhoogt alleszins het abstractie-niveau.
Als jij een bestaande webapplicatie ook naar een Windows versie moet porten, dan ga je veel werk hebben als die applicatie niet in lagen opgebouwd was.

Niet mee eens dus. Je moeten binnen de restricties van het budget en de tijd de best mogelijke applicatie bouwen. Iedereen die N-tier kan ontwikkelen kan ook een eenvoudiger oplossing bouwen (andersom is zeker niet het geval!) en soms is dat de enige optie gezien de eerdergenoemde restricties.

Jouw laatste punt (porten van web naar win) wil ik graag aangrijpen om met een voorbeeld duidelijk te maken wat ik bedoel:

Stel, jij hebt besloten om een nieuwe autootje te gaan kopen want je bent helemaal ziek van de NS. Na veel wikken en wegen heb je besloten een Toyota Starlet te gaan kopen (hey, it happens ). Je komt bij de dealer met de mededeling dat je graag een Starlet wilt bestellen. De verkoper kijkt je denigrerend aan: "Maar meneer, een Starlet? Hoe moet dat dan straks als er kinderen komen? Die passen daar toch nooit in! Ik stel dus voor te gaan voor een grotere stationwagon, daar passen ze zeker in. Oh, trouwens, stel nou dat je een keer met die kids naar het bos wilt, dan kom je met die station vast te zitten in de modder. Geen probleem, gaan we kijken bij deze mooi LandCruiser! Is trouwens ook nog een stuk veiliger dan zo'n Starlet! Daar kun je de Paris-Dakar nog wel mee rijden! Heel verstandig meneer! Oh ja, die LandCruiser is wel pas over anderhalf jaar te leveren, maar da's geen probleem, want de trein is zo gek nog niet!

Dit zouden wij van een autoverkoper nooit pikken, maar vreemd genoeg denken sommige IT'ers wel dat ze hun klanten op kunnen zadelen met een gigantische extra kostenpost en ellenlange oplevertermijnen. Allemaal vanuit het oogpunt dat wij het toch beter weten.

Een paar jaar geleden kon dit nog wel maar tegenwoordig is dit toch echt passe. Voor mij is EJB echt het paradepaardje van de arogante ontwikkelaar: je kunt er (theoretisch) echt de mooiste dingen mee bouwen, echt fantastisch. Echter, het kost gigantisch veel tijd en geld om er iets mee op te zetten en als het dan staat werkt het nog maar half (vergeleken met andere oplossingen). Zelf ben ik wat dat betreft meer gecharmeerd van de Microsoft aanpak: architectonisch een stukje minder, maar het werkt wel!

[Scare360]

Tis, Paullooijmans voor mij toch wikken en wegen t.a.v. jouw post. Ergens heb je gelijk en ergens geef je me het gevoel dat je de grote steen nog nooit bent tegengekomen "om" er uberhaupt tegen aan te stoten. Het verhaal van de autohandelaar is zekers "to the point" en geeft direct aan waar we eigenlijk over praten. Feit is dat je n-tier van twee kanten kunt bekijken, reusability en/of maintenance, wat er op neer komt dat je als purist altijd de architectuur van een stukje software analyseert alvorens in het diepe te springen. Dit is toch wel een van de belangrijkste lessen wat er toe geleid heeft dat men hyped over standaarden, methodiek etc. Als uitgangspunt neem ik ALTIJD, de klant is gebaat bij een informatie systeem wat de mogelijkheid biedt mee te groeien met de onderneming… en dan denk ik dat je bovenop de gebruikelijke usability, feasibility en functionele requirements alles wel afgevangen hebt.

Moeilijk, moeilijk…moeilijk… ik ondervind nagenoeg dezelfde problemen in mijn huidige project, maar gelukkig kan Fowler de kritische beslissingen uit handen nemen.

[EfBe]

Verwijderd schreef op 12 februari 2003 @ 21:49:
Hartstikke leuk hoor, al die layers, maar denk je nou echt dat het dhr. McNealy (de eigenaar van de Sun Petshop ) een moer kan schelen dat zijn Petshop helemaal perfect multitier is opgezet? Ik denk dat hij eerder jaloers is op de Petshop van dhr. Gates aan de overkant, die op dezelfde hardware een veelvoud van het aantal transacties kan uitvoeren terwijl de applicatie aanmerkelijk goedkoper is (ervan uitgaande dat >LOC == >prijs, een hele redelijke aanname toch?)

Nee. De petshop van Sun was bedoeld als illustratief voorbeeld hoe je een multi-tier applicatie met java zou kunnen maken, en de nadruk lag op het educatieve, het illustratieve. Zoals bij F&M en IBuySpy dat ook zo is. Die zijn ook intern niet echt je van het, maar zijn ook niet bedoeld als kick-ass implementaties, maar als illustratie, hoe zou het kunnen worden gedaan. Dat de petshop naar .NET is geport is leuk, maar niet meer dan dat.

Mijn punt is: Soms (vaak?) is die mooie scheiding niet nodig. Kijk eerst goed naar de applicatie die je moet bouwen om te beoordelen of de N-tier aanpak de juiste is. Ik denk dat we het wel eens kunnen worden dat de N-tier aanpak pas bij een bepaald complexitieitsniveau zijn vruchten gaat afwerpen. Onder dat niveau is het vooral lastig: veel extra code (ref:Petshop), veel extra complexiteit, minder performance.

Nee. Complexiteit neemt t.a.t. af in een n-tier applicatie. Flexibiliteit neemt toe en de onderhoudbaarheid ook. Ik zal dat in een posting hieronder toelichten door het posten van het n-tier artikel dat ik geschreven heb in de LLBLGen handleiding.

Uitgangspunt voor de te bouwen applicatie is niet 'hoe kan ik mijn applicatie zo goed mogelijk in elkaar zetten' maar 'hoe kan ik mijn klant zo goed mogelijk van dienst zijn'. De beste technische oplossing is niet noodzakelijkerwijs ook de beste 'business' oplossing: dat is pas Business Logic .

Dat zijn 2 dingen die tijdens verschillende stadia van een ontwikkeltraject naar voren komen, niet in hetzelfde stadium. 'Hoe kan ik mijn klant zo goed mogelijk van dienst zijn' komt naar voren tijdens de ontwerpfase, waarbij je functioneel en technisch onderzoek doet. Als die fase is afgerond komen pas de vragen hoe je het beste de gewenste functionaliteit kunt realiseren. 'beste' wordt in die fases gedefinieerd, ook aan de hand van de klant. Echter, de voordelen van n-tier development zijn uniform en 'klant-onafhankelijk'. Sterker: de klant heeft geen ruk te maken en MOET ook geen ruk te maken hebben met implementatie-details. De klant bestelt functionaliteit. Die krijgt de klant. Hoe dat wordt gerealiseerd is voor de klant niet belangrijk, zolang de bestelde functionaliteit maar beantwoord aan de vraag die de klant had en blijft beantwoorden aan die vraag.

Laat voorop staan dat dit vooral geen betoog is tegen N-tier ontwikkelen, ik ben volledig overtuigd van de voordelen van die aanpak, mits op de juiste tijd en plaats gebruikt.

Noem mij 1 voorbeeld van een applicatie die je voor een klant zou maken waar n-tier niet zou voldoen. Let op: een gui app voor single user met eventhandle code NIET direct achter de buttons is al 2-tier.

[...]
Niet mee eens dus. Je moeten binnen de restricties van het budget en de tijd de best mogelijke applicatie bouwen. Iedereen die N-tier kan ontwikkelen kan ook een eenvoudiger oplossing bouwen (andersom is zeker niet het geval!) en soms is dat de enige optie gezien de eerdergenoemde restricties.

Kennelijk snap je de ballen van n-tier applicaties. N-tier applicaties zijn juist simpeler te bouwen! Je hoeft nl. niet bezig te zijn met de spagetti van functionaliteit die in elkaar gevlochten zit in 1 executable. Je kunt abstract de grenzen bepalen van functionele groepen en die ook implementeren in delen van de applicatie (tiers) die jedaarvoor aanwijst, je weet dus waar welke functionaliteit is geimplementeerd. Dat weet je niet bij een grote logge 1-tier app, tenzij je alles opdeelt in libraries, maar wat is dan het verschil?

Jouw laatste punt (porten van web naar win) wil ik graag aangrijpen om met een voorbeeld duidelijk te maken wat ik bedoel:
Stel, jij hebt besloten om een nieuwe autootje te gaan kopen want je bent helemaal ziek van de NS. Na veel wikken en wegen heb je besloten een Toyota Starlet te gaan kopen (hey, it happens ). Je komt bij de dealer met de mededeling dat je graag een Starlet wilt bestellen. De verkoper kijkt je denigrerend aan: "Maar meneer, een Starlet? Hoe moet dat dan straks als er kinderen komen? Die passen daar toch nooit in! Ik stel dus voor te gaan voor een grotere stationwagon, daar passen ze zeker in. Oh, trouwens, stel nou dat je een keer met die kids naar het bos wilt, dan kom je met die station vast te zitten in de modder. Geen probleem, gaan we kijken bij deze mooi LandCruiser! Is trouwens ook nog een stuk veiliger dan zo'n Starlet! Daar kun je de Paris-Dakar nog wel mee rijden! Heel verstandig meneer! Oh ja, die LandCruiser is wel pas over anderhalf jaar te leveren, maar da's geen probleem, want de trein is zo gek nog niet! Dit zouden wij van een autoverkoper nooit pikken, maar vreemd genoeg denken sommige IT'ers wel dat ze hun klanten op kunnen zadelen met een gigantische extra kostenpost en ellenlange oplevertermijnen. Allemaal vanuit het oogpunt dat wij het toch beter weten.

Wij weten het ook beter, want als de klant het zelf beter wist zou hij het niet bestellen bij ons, maar lekker zelf doen. De klant wil functionaliteit. De klant vraagt niet om 'geef me software'. Die vraagt om een OPLOSSING voor een PROBLEEM. Dat wordt geregeld door functionaliteit te leveren die die oplossing (veelal deels, de rest is organisatorisch) impliceert voor het probleem. Jij begaat de grote blunder door te stellen dat n-tier development automatisch inhoudt dat je met iets erg groots bezig bent en veelal tegen veel hogere kosten oploopt. Niets is minder waar. n-tier development heeft juist een versimpeling in zich van wat er gerealiseerd moet worden, en levert dus in zijn geheel niet een complexer systeem, dat later wordt opgeleverd en duurder is. Dit is geen gel*l van een theoreticus, ik heb zelf een aantal asp sites gebouwd in de tijd dat het net opkwam (zelfs nog 1 met idc's en htx's) waarbij alle code in de pages zat. 1-tier. Daarna alleen maar 3- / 5- tier apps gebouwd en wat een verademing. Qua tijd maakt het niets uit, want hergebruik van objects, de overzichtelijkheid en de flexibiliteit winnen het altijd. Je vergeet dat je ook bij een 1-tier applicatie de functionaliteit echt moet implementeren. Bij een n-tier applicatie heb je een beetje overhead, maar dat valt in het niet bij de voordelen van de n-tier constructie, o.a. hergebruik van de middle-tier objects in bv verschillende pages en de abstractie-levels die met n-tier development gepaard gaan.

Een paar jaar geleden kon dit nog wel maar tegenwoordig is dit toch echt passe. Voor mij is EJB echt het paradepaardje van de arogante ontwikkelaar: je kunt er (theoretisch) echt de mooiste dingen mee bouwen, echt fantastisch. Echter, het kost gigantisch veel tijd en geld om er iets mee op te zetten en als het dan staat werkt het nog maar half (vergeleken met andere oplossingen). Zelf ben ik wat dat betreft meer gecharmeerd van de Microsoft aanpak: architectonisch een stukje minder, maar het werkt wel!

Waarom is knoeiwerk van een clubje prutsers dat toevallig de technologie verkeerd toepassen een argument om maar geen n-tier applicaties te bouwen? Ik meen het serieus als ik zeg dat iedere 'programmeur' die (limieten van de gebruikte software daargelaten, zoals php) voor een 1-tier model kiest bij een website, beter iets anders kan gaan doen, want prutsers hebben we genoeg in de IT, helaas.

[stylee]

offtopic:
Kunnen jullie mij goede literatuur aanraden over de hier besproken onderwerpen?

Dank

[EfBe]

Ik heb het artikel maar even online gezet, het hier pasten was teveel werk mbt het omzetten van de html naar rml Vooral de punten die ik noem mbt n-tier development zijn imho t.a.t. zaken die een project voordelen bieden boven een 'snelle hack voor weinig'.

http://www.sd.nl/software/llblgendocs/ntier.htm

[whoami]

stylee schreef op 13 February 2003 @ 10:09:

offtopic:
Kunnen jullie mij goede literatuur aanraden over de hier besproken onderwerpen?

Dank

offtopic:
Patterns for Enterprise application Architecture van Martin Fowler

[Alarmnummer]

Ik vind het niet nodig om altijd een multitier applicatie op te zetten, maar een applicatie zet je sowieso altijd op in layers. Data layer, domein layer, gui layer en eventueel nog een hele lading service layers. Een gui met logica gaan combineren en dan ook nog een potje sql queries erdoor heen komt me vrij bekend voor. Dat is namelijk de bagger waar ik nog een aantal dagen aan mee moet helpen debuggen. Er is totaal geen overzicht waar je iets kan aanpassen. Queries liggen over het hele systeem verspreid, er is geen overzicht van de business rules etc etc.

Probeer dus je applicatie in ieder geval altijd op te zetten van layers. Verder is het verschil tussen een layer en een tier een beetje vaag. Voorwaarde aan een tier is dat het ook op fysiek verschillende lokatie moet staan, en bij een layer niet. Een three tier applicatie zou je ook in dit opzicht kunnen vergelijken met een 3 layer applicatie

[ Voor 20% gewijzigd door Alarmnummer op 13-02-2003 10:21 ]

[Alarmnummer]

Verwijderd schreef op 12 February 2003 @ 21:49:
Een paar jaar geleden kon dit nog wel maar tegenwoordig is dit toch echt passe. Voor mij is EJB echt het paradepaardje van de arogante ontwikkelaar: je kunt er (theoretisch) echt de mooiste dingen mee bouwen, echt fantastisch. Echter, het kost gigantisch veel tijd en geld om er iets mee op te zetten en als het dan staat werkt het nog maar half (vergeleken met andere oplossingen). Zelf ben ik wat dat betreft meer gecharmeerd van de Microsoft aanpak: architectonisch een stukje minder, maar het werkt wel!

Als je een multitier systeem gaat opzetten, dan is EJB zeer interesssant. Bij EJB hoef je je voornamelijk bezig te houden met de logica van het domein en zaken erom heen zoals concurrency, middelware etc worden allemaal voor je geregeld.

Ik zet sneller een multitier applicatie op met EJB dan een met de hand geschreven server omdat EJB gewoon alle andere zaken voor je doet.

Ik ben het met je eens dat EJB niet overal voor toepasbaar is.

En verder denk ik dat het meningsverschil tussen jou en Otis is ontstaan doordat niet goed overgekomen is dat jij je systeem wel in layers opzet maar tiers niet altijd nodig vind. (althans een gedeelte van het meningsverschil)

[ Voor 3% gewijzigd door Alarmnummer op 13-02-2003 10:49 ]

[EfBe]

als je het in layers opzet, ben je al n-tier bezig, want je moet data distribueren tussen de tiers/layers. Een 'tier' is niet een fysiek programma, het is een abstracte black box (pleonasme ), net als een layer dat behoort te zijn in een programma. Zodra je shortcuts gaat toepassen in een layered applicatie is je applicatie sec geen layered applicatie meer.

[Alarmnummer]

Ik had begrepen dat een extra voorwaarde aan een tier was dat de tiers op verschillende fysieke lokaties moesten staan. Maarja.. tis ook beetje miereneuken (waar we op /14 trouwens vaak erg goed in zijn )

[ Voor 28% gewijzigd door Alarmnummer op 13-02-2003 11:02 ]

[Alarmnummer]

En wat vind jij trouwens van een taal/omgeving zoals Clarion. Hiermee kan je veel code genereren en veel met macro`s en templates werken. Het schijnt dat je er in een fractie van de tijd applicaties mee kan opzetten. Verder weet ik er eigelijk ook niet veel van, maar vraag me soms wel af of het nog te rechtvaardigen valt dat er grote bedragen te vragen zijn voor applicaties. Aan de andere kant is het natuurlijk een stuk vakwerk en laat maar eens een timmerman komen om een kamer te verspijkeren, dan ben je ook een smak geld kwijt terwijl daar veel minder kennis in zit.

[EfBe]

Alarmnummer schreef op 13 februari 2003 @ 11:01:
Ik had begrepen dat een extra voorwaarde aan een tier was dat de tiers op verschillende fysieke lokaties moesten staan. Maarja.. tis ook beetje miereneuken (waar we op /14 trouwens vaak erg goed in zijn )

heh ik zie dat niet zo zwart/wit hoor. n-tier development is een semantische zaak, niet een syntactische, dwz het is puur een methodiek die op een hoger niveau ligt dan het niveau waar implementatiedetails de grenzen bepalen. Op veel platforms kun je overigens een layer in een library zo op een andere doos draaien en via remoting bv deze layer benaderen. Bv een COM object: plaats dat in MTS/COM+ op een andere doos, genereer een setup.exe mbv COM+ / MTS en installeer die setup op de client bak. Die maakt simpele monikers aan zodat de client denkt dat hij lokaal de COM objects benadert maar dat gewoon via DCom remote doet

Clarion klinkt wel bekend maar kan er niets over zeggen, die website is ook niet 1 2 3 duidelijk overigens.

Over prijzen van software: je metafoor mbt een timmerman lijkt me voor zich spreken. Maatwerk kost geld, daar doe je weinig aan. Spullen die van de plank komen en waarbij de massale verkopen in feite de lage prijs rechtvaardigen zijn daar niet mee te vergelijken.

[ Voor 17% gewijzigd door EfBe op 13-02-2003 11:28 ]

[Alarmnummer]

Deze is beter:
http://softvelocity.com

The Clarion development paradigm provides dramatically faster, and easier application development... from prototyping to deployment of a production system, and ongoing application maintenance.

Clarion employs breakthrough, template driven technology to create sophisticated database-driven applications. Clarion is designed to help developers ensure standards, reduce coding time, eliminate errors, and bring their projects to completion in record time.

[ Voor 86% gewijzigd door Alarmnummer op 13-02-2003 11:37 ]

[Alarmnummer]

EfBe schreef op 13 februari 2003 @ 11:25:
heh ik zie dat niet zo zwart/wit hoor. n-tier development is een semantische zaak, niet een syntactische, dwz het is puur een methodiek die op een hoger niveau ligt dan het niveau waar implementatiedetails de grenzen bepalen.

Ik vind het voor mezelf in ieder geval welk makkelijk om wel/geen netwerk onderscheid te maken zodat ik in iedergeval weet wat voor complexiteit ik voor de kiezen ga krigjen.

Op veel platforms kun je overigens een layer in een library zo op een andere doos draaien en via remoting bv deze layer benaderen. Bv een COM object: plaats dat in MTS/COM+ op een andere doos, genereer een setup.exe mbv COM+ / MTS en installeer die setup op de client bak. Die maakt simpele monikers aan zodat de client denkt dat hij lokaal de COM objects benadert maar dat gewoon via DCom remote doet

Ik ken het fenomeen. Het proxy design patterns maakt dit mogelijk en dit wordt oa ook gebruikt voor RMI. Het probleem aan deze aanpak is dat je dan een erg fijnmazige interface het internet laat opkruipen met als gevolg dat je een enorme lading remote calls loopt te maken (zonder dat je er zelf misschien erg in hebt). Hierdoor zal je de performance van je applicatie gigantische problemen gaan ondervinden.

Als je iets met remote calls wilt gaan doen, moet je daar in principe wel rekening mee gaan houden en interfaces daarvoor gaan optimaliseren. Het is idd niet fijn oo, maar anders bestaat de kans dat je applicatie supertraag gaat worden.

[Alarmnummer]

En nu even een stukje ECHTE BAGGER. Dit is dus een klassiek voorbeeld zoals je dus geen applicaties moet opzetten. Er wordt verder geen gebruik gemaakt van layers. Domein logica zit onder de event code, er worden verder geen classes gebruikt, en de sql code zit ook gewoon fijn tussen de gui code. Oja, niemand heeft van exceptions gehoord, daar doen we niet aan. Alles gaat altijd goed.

Oja, en het is niet zo dat het uitlijnen door GoT verkeerd gaat, maar het is dus niet uitgelijnd en

Java:

type
  TNieuwVolmachtForm = class(TForm,IMasterFrame)
    Label2: TLabel;
    RadioGroup1: TRadioGroup;
    StaticText1: TStaticText;
    StaticText2: TStaticText;
    CheckListBox1: TCheckListBox;
    StaticText3: TStaticText;
    StaticText4: TStaticText;
    Edit2: TEdit;
    StaticText5: TStaticText;
    StaticText6: TStaticText;
    Edit5: TEdit;
    StaticText7: TStaticText;
    StaticText8: TStaticText;
    StaticText9: TStaticText;
    Edit6: TEdit;
    Edit7: TEdit;
    Edit8: TEdit;
    StaticText10: TStaticText;
    StaticText11: TStaticText;
    StaticText12: TStaticText;
    Edit9: TEdit;
    Edit11: TEdit;
    StaticText13: TStaticText;
    ComboBox1: TComboBox;
    StaticText14: TStaticText;
    StaticText15: TStaticText;
    Edit3: TEdit;
    RadioButton1: TRadioButton;
    RadioButton2: TRadioButton;
    RadioButton3: TRadioButton;
    RadioButton4: TRadioButton;
    Edit10: TMaskEdit;
    Edit4: TMaskEdit;
    Edit1: TMaskEdit;
    RadioGroup2: TRadioGroup;
    StaticText16: TStaticText;
    Panel4: TPanel;


    procedure FormMouseWheelDown(Sender: TObject; Shift: TShiftState;
      MousePos: TPoint; var Handled: Boolean);
    procedure FormMouseWheelUp(Sender: TObject; Shift: TShiftState;
      MousePos: TPoint; var Handled: Boolean);
    procedure BitBtn4Click(Sender: TObject);
    procedure FormShow(Sender: TObject);
    procedure BitBtn2Click(Sender: TObject);
    procedure ComboBox1Change(Sender: TObject);
    procedure RadioGroup1Click(Sender: TObject);
    procedure UpdateErfgenamenVolmachtInfo;
    procedure BitBtn3Click(Sender: TObject);
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
    procedure BitBtn1Click(Sender: TObject);
    procedure RadioGroup2Click(Sender: TObject);
    procedure CheckListBox1Click(Sender: TObject);

  private
    { Private declarations }
    m_volcode : integer;
    m_erfcode : integer;
    m_notcode : integer;
    procedure setVolCode();   overload;
  public
    { Public declarations }
    procedure setVolCode(volcode : integer);   overload;
    procedure setErfCode(erfcode : integer);
    procedure setNotCode(notcode : integer);
    procedure Init(ErfCode : integer);
    procedure Clear();
    procedure SaveQuery();
    procedure UpdateQuery();
    procedure LoadQuery();
    procedure DeleteQuery();
    procedure mySetEnabled();
  end;

var
  NieuwVolmachtForm: TNieuwVolmachtForm;
  RdGrpint           : integer;
  genavona           : string;
  genachna           : string;
  delbool            : boolean;
implementation

uses HoofdMenuFormUnit, DeleteDialogUnit;

{$R *.DFM}

procedure TNieuwVolmachtForm.setVolCode(volcode : integer);
begin
  m_volcode:=volcode;
end;
procedure TNieuwVolmachtForm.setVolCode();
var
  s : string;
  c : c_string;
begin
    getmem(c,20480);
  s:='SELECT '+
    'MAX(GevCode) '+
       'FROM '+
     'Gevol ;';

  PasToC(s,c);

  db_do_sql_query(c,1);  // 1 kolommen ophalen...
  if (db_next_row) then begin;
    db_do_get_value(0,c); m_volCode:=StrToInt(PasStr(c));
  end;

  FreeMem(c);
end;

procedure TNieuwVolmachtForm.setErfCode(erfcode : integer);
begin;
  m_erfcode:=erfcode;
end;

procedure TNieuwVolmachtForm.setnotCode(notcode : integer);

 var
  s : string;
  c : c_string;

begin
    getmem(c,20480);
  s:='SELECT '+
     'NotCode '+           {1}
     'FROM '+
     'Erflater WHERE ErfCode='+IntToStr(m_erfCode)+';';

  PasToC(s,c);

  db_do_sql_query(c,1);  // 28 kolommen ophalen...
  if (db_next_row) then begin;
    db_do_get_value(0,c); m_notCode:=StrToInt(PasStr(c));

  end;
  FreeMem(c);
end;


procedure TNieuwVolmachtForm.Init(ErfCode : integer);
var
  s : string;
  c : c_string;
begin
  m_erfcode:=Erfcode;
  VertScrollBar.Position:=0;
  Clear();
  delbool:=false;  //23 januari 2003
   if exebool then begin
   Radiobutton4.visible:=false;
   Radiobutton1.visible:=true;
   Radiobutton2.visible:=true;
   Radiobutton3.visible:=true;
// Messagedlg('hallo',mtinformation,[mbok],0);

  end;
  if not exebool then begin
  Radiobutton4.visible:=true;
  Radiobutton1.visible:=false;
  Radiobutton2.visible:=false;
  Radiobutton3.visible:=false;
  end;

  getmem(c,20480);
  s:='SELECT Boedvol FROM Verklaar WHERE ErfCode='+IntToStr(m_erfcode)+';';
  PasToC(s,c);
  db_do_sql_query(c,1); // Informatie uit 1 kolom ophalen

  if db_next_row then begin
    db_do_get_value(0,c); if PasStr(c)='0' then RadioGroup2.ItemIndex := 1;
    if PasStr(c)='1' then RadioGroup2.ItemIndex := 0;
  end;
  freemem(c);


  if (m_volcode<>-1) then begin
    LoadQuery;
     RadioGroup1Click(nil);
     RadioGroup2Click(nil);
  end else begin
    berekenerfdeel(m_erfcode);
    //alleen langstlevende geeft volmacht 31-01-2003 vh
    if erfvwbool then begin
      vulerfchecklistbox(checklistbox1,kanervenll,volmacht);
   end
 else begin
 vulerfchecklistbox(checklistbox1,kanervenenverwerptniet,volmacht);
 // vulerfcombobox(combobox1,kanervenenverwerptniet);
//  Messagedlg('kanervenverwerptniet',mtinformation,[mbok],0);
 end;
 //einde van toevoeging 31-01-2003 vh
    vulerfcombobox(combobox1,kanervenenverwerptniet);
  end;
  ComboBox1Change(nil);
end;


procedure TNieuwVolmachtForm.Clear();
begin
  RadioGroup1.ItemIndex:=-1;
  RadioGroup2.ItemIndex:=-1;
  Edit1.Text:='';
  Edit2.Text:='';
  Edit3.Text:='';
  Edit4.Text:='';
  Edit5.Text:='';
  Edit6.Text:='';
  Edit7.Text:='';
  Edit8.Text:='';
  Edit9.Text:='';
  Edit10.Text:='';
end;


procedure TNieuwVolmachtForm.UpdateErfgenamenVolmachtInfo;
var
  s : string;
  c : c_string;
  i : integer;
  e : PErfDeelInfo;
begin
  getmem(c,20480);
  for i:=0 to CheckListBox1.Items.Count-1 do begin
    e:=PErfDeelInfo(CheckListBox1.Items.Objects[i]);
    e^.volmacht:=CheckListBox1.Checked[i];
    s:=format(e^.qvolmacht,[integer(e^.gevolmachtigde),integer(e^.volmacht)]);
    PasToC(s,c);
    db_do_sql_query(c,0);

  end;
  freemem(c);
end;

procedure TNieuwVolmachtForm.DeleteQuery();
var
  c        : c_String;  {de c string om op te slaan}
  s        : string;    {de pascal string}
begin
    getmem(c,20480);
  s:='UPDATE Gevol SET '+
     'GevErfg=null,'+
     'GevNot=null,'+
     'GevExec=null,'+
     'GevDerde=null,'+
     'GevVoNa=null,'+
     'GevAcNa=null,'+
     'GevGeb=null,'+
     'GevGpl=null,'+
     'GevId=null,'+
     'GevAf=null,'+
     'GevNat=null,'+
     'GevAd=null,'+
     'GevPost=null,'+
     'GevPl=null '+' '+
     'WHERE Erfcode='+IntToStr(m_erfcode)+';';
  PasToC(s,c);
  db_do_sql_query(c,0); // informatie uit 0 kolommen ophalen
     delbool:=true;

  s:='UPDATE Verklaar SET '+
     'BoedVol=null '+
     'WHERE ErfCode = '+intToStr(m_ErfCode)+' ;';
  PasToC(s,c);
  db_do_sql_query(c,0); // Informatie uit 0 kolommen opslaan

  s:='DELETE DatumVol '+
     'FROM Nalaat '+
     'WHERE ErfCode = '+intToStr(m_ErfCode)+' ;';
  PasToC(s,c);
  db_do_sql_query(c,0); // Informatie uit 0 kolommen opslaan

  FreeMem(c);

  // set de Form klaar voor een nieuwe entry
  m_volCode :=  -1;
end;

[ Voor 25% gewijzigd door Alarmnummer op 13-02-2003 12:45 ]

[EfBe]

db_do_sql_query(c,0); // Informatie uit 0 kolommen opslaan

LOL ja die '0' was wel helder, die 'c' echter niet. Oh wacht, dat is.. 'informatie'. aha

[Verwijderd]

EfBe schreef op 13 februari 2003 @ 10:02:
Noem mij 1 voorbeeld van een applicatie die je voor een klant zou maken waar n-tier niet zou voldoen. Let op: een gui app voor single user met eventhandle code NIET direct achter de buttons is al 2-tier.

Dit vind ik flauw. Maar goed, als je het zo wil spelen dan zal ik mijn stelling scherper stellen: Waar ik tegen protesteer is het onbeargumenteerd en overbodige gebruik van 'tiers'. Wat ik in sommige berichten las was dat N-tier ontwikkeling intrinsiek beter is dan niet N-tier ontwikkelen. Als je jouw bovenstaande definitie van N-tier ontwikkelen hanteert heb je gelijk, maar dan kom je wel heel erg snel in N-tier gebied terecht en is de hele discussie nutteloos.

Waar we het mijns inziens over hebben is over het invoegen van een x aantal extra lagen in een applicatie om de complexiteit te verminderen (en flexibiliteit te verhogen etc. etc.). Mijn stelling is dat een applicatie wel eerst als 'te ingewikkeld' geclassificeerd moet worden voordat je de keuze maakt een laag toe te voegen. Ik vond dat punt in de voorgaande discussie onderbelicht en dat vind ik een kwalijke zaak.

Praktijkvoorbeeld: ik bouw vaak imho aardig complexe webapplicaties, sinds een jaar of 2 met ASP.NET. Voor die tijd had ik soms al mijn bedenkingen bij het toepassen van een VB Business Logic Layer bij sommige applicaties omdat deze tussenlaag vaak niet meer deed dan het doorgeven van variabelen aan een stored procedure. Met de introductie van ASP.NET en de event-based manier waarop dit framework werkt zijn die bedenkingen alleen maar toegenomen: de applicatie moet toch echt wel aardig complex zijn en voldoende mogelijkheden tot hergebruik van objecten bieden wil ik besluiten een volledige Business Logic Layer toe te voegen. Ben ik nu een slechte programmeur? Nee imho, ik ben een programmeur met voldoende ervaring om in te zien dat de eenvoudigste oplossing vaak de beste is.

Nogmaals, dit is geen betoog tegen N-tier ontwikkeling, slechts een betoog tegen overbodig 'architectionisme'.

De petshop van Sun was bedoeld als illustratief voorbeeld hoe je een multi-tier applicatie met java zou kunnen maken, en de nadruk lag op het educatieve, het illustratieve.
[...]
Nee. Complexiteit neemt t.a.t. af in een n-tier applicatie. Flexibiliteit neemt toe en de onderhoudbaarheid ook. Ik zal dat in een posting hieronder toelichten door het posten van het n-tier artikel dat ik geschreven heb in de LLBLGen handleiding.

Precies, Petshop was de applicatie die mensen moest tonen hoe ze een EJB oplossing in elkaar moesten zetten. Dat maakt het des te kwalijker dat Sun zich overduidelijk te buiten is gegaan aan voornoemd 'architectionisme'. Zeker, de applicatie is schitterend verdeeld in lagen: GUI - BLL - DAL - DB. Maar waar heeft dit toe geleid. Kijken we naar Lines of Code:

Sun Petshop: 14000 regels.
MSFT Petshop: 4000 regels.

En we hebben het over precies dezelfde functionaliteit!

Veel mensen hebben de MSFT versie van Petshop een 'verkrachte', 'simplistische' of zelfs 'quick hack' oplossing genoemd maar daarmee onderkennen ze imho het belang van een goede analyse: is het project wel complex genoeg om een extra laag toe te voegen?

Als jij kan beweren dat de 14000 regels van Sun minder complex, flexibeler en makkelijker onderhoudbaar zijn dan de .NET zonder in de lach te schieten dan mag jij van mij deze discussie winnen :-)

Ik weet dat bovenstaand voorbeeld gechargeerd is, maar geef toe dat er wel degelijk scenario's denkbaar zijn waarin de complexiteit van een applicatie niet hoog genoeg is om een extra tussenlaag te verantwoorden!

Sterker: de klant heeft geen ruk te maken en MOET ook geen ruk te maken hebben met implementatie-details. De klant bestelt functionaliteit. Die krijgt de klant...

[...]

Wij weten het ook beter, want als de klant het zelf beter wist zou hij het niet bestellen bij ons, maar lekker zelf doen....

Ja ja, net zoals de klant in mijn voorbeeld de functionaliteit mobiliteit (=auto) bestelt en geen ruk te maken heeft met de precieze eigenschappen van die functionaliteit (grootte, complexiteit, flexibiliteit en meest belangrijk: prijs).

Het is jouw taak als programmeur om de klant in gewoon nederlands duidelijk te maken wat zijn opties zijn: de keuze ligt echter nog steeds bij hem. Het feit dat ons werkveld ingewikkelder is dan dat van een autoverkoper is nog geen excuus om zelf maar alle beslissingen te gaan nemen.

Kennelijk snap je de ballen van n-tier applicaties....

[...]

Jij begaat de grote blunder door te stellen dat n-tier development automatisch inhoudt dat je met iets erg groots bezig bent en veelal tegen veel hogere kosten oploopt...

Beetje vriendelijker mag trouwens wel hoor, het is maar een discussie. Ik denk niet dat jij uit mijn reacties tot dusver over dit onderwerp kan opmaken of ik N-tier ontwikkeling wel of niet onder de knie heb, dus laat die blunders en ballen in het vervolg weg.

Ik zeg niet dat je automatisch tegen hogere kosten oploopt: wat ik zeg is dat de extra investering die nodig is voor het bouwen van een extra laag zichzelf pas terugverdient als een bepaald complexitieitsniveau bereikt is (of een bepaald flexibiliteitsniveau gevraagd wordt etc.). Sommige applicaties hoeven nu eenmaal niet van database te wisselen of naar windows of mobile geport te worden: We're not all building the next version of Windows or the next Amazon.com

Hoe dan ook, ik vind het hier in P&W wel gezellig zo, ik denk dat ik nog even blijf

[Scare360]

Uhm: paullooijmans

Het gaat fout hier, de truc is simpel (Martin Fowler)...

if (_complexiteit>7.42) { _iShouldUse = "Domain Model"; }
else { _iShouldUse = "Transaction Script | Table Module; }

In andere woorden... wordt het aangeraden tenminste altijd een Table Module te gebruiken. Een argument hiervoor is encapsuleren van stored procedures en de "natural fit" in .NET gezien .NET gebouwd is op Recordset Sets ideen. Transaction Script, dus praktisch het koppelen van een DataReader aan een combobox middels een SQL command niet echt je_van_het is.

Ow: Verder ben ik het wel met je eens, maar zie wel het belang van n-tier dev in.

[ Voor 11% gewijzigd door Scare360 op 14-02-2003 08:49 ]

[EfBe]

Verwijderd schreef op 13 februari 2003 @ 21:36:
[...]
Dit vind ik flauw. Maar goed, als je het zo wil spelen dan zal ik mijn stelling scherper stellen: Waar ik tegen protesteer is het onbeargumenteerd en overbodige gebruik van 'tiers'. Wat ik in sommige berichten las was dat N-tier ontwikkeling intrinsiek beter is dan niet N-tier ontwikkelen. Als je jouw bovenstaande definitie van N-tier ontwikkelen hanteert heb je gelijk, maar dan kom je wel heel erg snel in N-tier gebied terecht en is de hele discussie nutteloos.

Waarom is die discussie dan nutteloos? Ik wil de prutsers die ook vandaag nog direct db code achter een button click event handler hangen niet graag de kost geven. Waar ik telkens op hamer is dat n-tier development een abstract begrip is, bedoeld voor applicatie designers. Developers, dus de code-kloppers zeg maar, vullen dan de tiers in. Wanneer de developer (dus de codetyper) gaat beslissen waar welke code moet komen, kun je NOOIT EN TE NIMMER meer garanderen dat je applicatie uberhaupt beheer(s)baar is, domweg omdat je geen design hebt van je applicatie. Welnu, als je dus je applicatie goed designed, kom je veelal, tenzij het een klein progseltje is, bij een setup uit waarbij je praat over afgebakende gebieden, abstracte 'tiers' of 'layers'. Die kunnen wellicht naast elkaar bestaan, zoals een asp.net + een webservice gui/interface. Deze thread ging over enterprise applicatie development, en dan hebben we het niet over Jan Sysadmin's commandline hulptooltjes.

Waar we het mijns inziens over hebben is over het invoegen van een x aantal extra lagen in een applicatie om de complexiteit te verminderen (en flexibiliteit te verhogen etc. etc.). Mijn stelling is dat een applicatie wel eerst als 'te ingewikkeld' geclassificeerd moet worden voordat je de keuze maakt een laag toe te voegen. Ik vond dat punt in de voorgaande discussie onderbelicht en dat vind ik een kwalijke zaak.

Het gaat niet om 'dit is ingewikkeld, dit moet in lagen'. Het gaat erom HOE je enterprise-like applicaties bouwt, dus niet alleen code typen, maar ook designen: hoe zet je zoiets op, en hoe bouw je daarna wat je hebt opgezet succesvol tot een applicatie die PRECIES reflecteert wat jij als functionaliteit beoogde in het begin. N-tier development helpt daarbij, want het wordt al vroeg in het traject geintroduceerd, nog voordat Kees van development ook maar zn editor heeft opengeklikt.

Jouw argument(en) komen m.i. erop neer dat de middelen die gebruikt worden bij het ontwerpen van een juiste invulling van de beoogde functionaliteit rekening moeten houden met implementatie-limieten/nadelen. Dus, dat je bij het ontwerpen niet teveel in abstractielevels mag gaan denken, want dat impliceert meer overhead en code.

Ik vind dat iewat kortzichtig, want het druist tegen de wijze in waarop software gebouwd zou moeten worden: onderzoek-ontwerpen-ontwerp implementeren-testen-opleveren. Je gaat nl ook niet tijdens het onderzoek welke functionaliteit er gewenst is, rekening houden met implementatiedetails. Waarom doe je dat dan wel tijdens het opdelen van de functionaliteit in abstractielagen?

Praktijkvoorbeeld:

Even voor de goede orde: praktijkvoorbeelden zeggen geen r**t. Ik hoest er ook zo 20 op die het tegendeel bewijzen en anders is er ergens op de aardkloot wel iemand met een praktijkvoorbeeld dat jouw praktijkvoorbeeld ondermijnt. Argumenten die op theorie zijn gebaseerd zijn m.i. te prefereren, praktijkvoorbeelden zijn nl. veelal resultaten van invloeden die vaak niet genoemd worden in het praktijkvoorbeeld, ipv dat ze het resultaat zijn van het punt ter discussie waar het praktijkvoorbeeld als argument voor wordt aangedragen.

ik bouw vaak imho aardig complexe webapplicaties, sinds een jaar of 2 met ASP.NET. Voor die tijd had ik soms al mijn bedenkingen bij het toepassen van een VB Business Logic Layer bij sommige applicaties omdat deze tussenlaag vaak niet meer deed dan het doorgeven van variabelen aan een stored procedure. Met de introductie van ASP.NET en de event-based manier waarop dit framework werkt zijn die bedenkingen alleen maar toegenomen: de applicatie moet toch echt wel aardig complex zijn en voldoende mogelijkheden tot hergebruik van objecten bieden wil ik besluiten een volledige Business Logic Layer toe te voegen. Ben ik nu een slechte programmeur? Nee imho, ik ben een programmeur met voldoende ervaring om in te zien dat de eenvoudigste oplossing vaak de beste is.

Wat is jouw definitie van 'beste' in dit verhaal? Want ik vrees dat die niet dezelfde is als de mijne. Ik heb net een 3-tier ASP.NET applicatie afgerond (op een paar puntjes na) en ben erg blij met mn middle layer, ookal doet deze veelal niet zo bar veel meer dan datatables omzetten naar een sorted view / filtered view of wat data in meerdere tables stoppen. Ik kan nl. in de gui werken met objects als "SecurityManager" ipv met "Users" en "Roles" tables. Het is dat soort abstractie dat een applicatie simpeler maakt. Eenvoudiger, zoals je wilt.

Nogmaals, dit is geen betoog tegen N-tier ontwikkeling, slechts een betoog tegen overbodig 'architectionisme'.

Ik heb nog geen argument gezien daartegen eerlijk gezegd. Een praktijkvoorbeeld dat iets ademt van "deze code is overbodig en kan dus weg". Veel website code IS in de ogen van sommigen overbodig en herhalend, en dus saai om te bouwen. Vandaar dat men steeds meer zn toevlucht zoekt in generatoren en frameworks die al die 'common' code aanbieden zodat je alleen de lijm ertussen nog moet implementeren. Daarnaast vind ik dat een developer, dwz de codetyper, wel een mening mag hebben over wat hij moet implementeren, maar geen applicatie-designer is, en dus dat die mening niet echt telt wanneer het gaat om wat het beste is voor applicatie-development.

[...]
Precies, Petshop was de applicatie die mensen moest tonen hoe ze een EJB oplossing in elkaar moesten zetten. Dat maakt het des te kwalijker dat Sun zich overduidelijk te buiten is gegaan aan voornoemd 'architectionisme'. Zeker, de applicatie is schitterend verdeeld in lagen: GUI - BLL - DAL - DB. Maar waar heeft dit toe geleid. Kijken we naar Lines of Code:

Sun Petshop: 14000 regels.
MSFT Petshop: 4000 regels.

En we hebben het over precies dezelfde functionaliteit!

Ik denk dat als je alles achter het form prakt dat je nog minder code kwijt bent. Is het aantal regels code belangrijk? Ik heb liever 20.000 regels code waarbij ze duidelijk zijn en helder dan 5.000 waarbij ik 2 weken meer kwijt ben om alles uit elkaar te trekken voordat ik de extra functionaliteit kan toevoegen. Zelfde discussie kun je voeren over commentaar in code, het al dan niet ontwerpen van je database middels een methodiek als ORM/NIAM ipv direct E/R prut te gaan knoeien etc. Het extra werk dat het kost is niet iets dat verloren is of geen doel dient, integendeel.

Veel mensen hebben de MSFT versie van Petshop een 'verkrachte', 'simplistische' of zelfs 'quick hack' oplossing genoemd maar daarmee onderkennen ze imho het belang van een goede analyse: is het project wel complex genoeg om een extra laag toe te voegen?

Het is een quick hack voor marketing. Net zoals de F&M site die als .NET example te downloaden is een prutser-applicatie is, want degenen die het gebouwd hebben snapten niet wat educatie inhoudt. Verder vind ik het hilarisch als je MS' knoeiwerk in het kader van de Petshop app een resultaat vind van 'goede analyse'. Er _IS_ geen analyse mogelijk, want het is een virtual shop, de shop bestaat niet. Je kunt wel aannames doen, en het zo implementeren, maar MS heeft de Sun implementatie gepakt en die geoptimized. Niks analyse. Alles is gedaan om de snelheid. Ze hebben ook DataReaders gebruikt, juist om dat doel. Zodra je DataReaders in een webapplicatie ziet weet je dat je met knoeiwerk te maken hebt.

Als jij kan beweren dat de 14000 regels van Sun minder complex, flexibeler en makkelijker onderhoudbaar zijn dan de .NET zonder in de lach te schieten dan mag jij van mij deze discussie winnen :-)

Ik heb niet inhoudelijk (dus naar de code) naar de Sun implementatie gekeken, dus ik kan er niet over oordelen. Ik weet wel dat de MS oplossing een knoeiersbende is en ZEKER niet onderhoudbaar is. Het gaat me trouwens niet om deze implementatie-details, want Sun heeft 1 ding goed gedaan: ze hebben functionaliteit in abstracte lagen gegoten en die daarna geimplementeerd. MS niet.

In het kader van 'beter' als in 'beter design', wint Sun het met vlag en wimpel. MS echter gebruikt hun implementatie voor benchmarktests voor marketing: Java vs .NET. Lekker belangrijk. Net zo dom als de discussie wat beter is: handmatig een newspage aanpassen of een edit-applicatie bouwen voor 1 newspage. Handmatig de newspage aanpassen is echt veel sneller geimplementeerd dan een edit-applicatie voor een newspage, want die is niet 1 2 3 gerealiseerd (database, security etc etc).

Ik weet dat bovenstaand voorbeeld gechargeerd is, maar geef toe dat er wel degelijk scenario's denkbaar zijn waarin de complexiteit van een applicatie niet hoog genoeg is om een extra tussenlaag te verantwoorden!

Je snapt nog steeds niet echt wat de volgorde is waarin de zaken aan bod komen, krijg ik de indruk. Als een applicatie simpel is qua functionaliteit, HEB je geen extra tussenlagen. Je implementeert dan die lagen die je hebt ontworpen, klaar. Je gaat niet tijdens het code-typen denken... "ik heb een extra tussenlaag nodig", want dat is de omgekeerde wereld!

Het is jouw taak als programmeur om de klant in gewoon nederlands duidelijk te maken wat zijn opties zijn: de keuze ligt echter nog steeds bij hem. Het feit dat ons werkveld ingewikkelder is dan dat van een autoverkoper is nog geen excuus om zelf maar alle beslissingen te gaan nemen.

Sinds wanneer praat een programmeur met een klant? Een programmeur bouwt code, als implementatie van gewenste functionaliteit. Welke functionaliteit dat is, is geanalyseerd door de systeemarchitecten en systeemanalysten; hoe de applicatie innerlijk qua structuur eruit ziet is ontworpen door de systeemarchitect(en). De klant heeft daar geen moer mee te maken, en kan ook niets met die info. Wat de klant wil is een oplossing voor een probleem. De opdrachtnemer levert die oplossing, in het geval van deze discussie in de vorm van een softwareapplicatie. Hoe die applicatie intern werkt, wat moet die klant met die info? Mensen die het moeten beheren, die moeten info hebben omtrent bv scalability en tiers en hoe de geimplementeerde zaken daarin te passen zijn.

Beetje vriendelijker mag trouwens wel hoor, het is maar een discussie. Ik denk niet dat jij uit mijn reacties tot dusver over dit onderwerp kan opmaken of ik N-tier ontwikkeling wel of niet onder de knie heb, dus laat die blunders en ballen in het vervolg weg.

Qua volgorde van development-traject en besef op welk level n-tier development wordt ingezet (dus op code-klopper niveau of daarboven) maak je toch wel een paar lelijke missers en baseert daarop je argumentatie.

Ik zeg niet dat je automatisch tegen hogere kosten oploopt: wat ik zeg is dat de extra investering die nodig is voor het bouwen van een extra laag zichzelf pas terugverdient als een bepaald complexitieitsniveau bereikt is (of een bepaald flexibiliteitsniveau gevraagd wordt etc.). Sommige applicaties hoeven nu eenmaal niet van database te wisselen of naar windows of mobile geport te worden: We're not all building the next version of Windows or the next Amazon.com

Nogmaals: die extra lagen worden niet verzonnen achter het toetsenbord door Karel de Codert, maar door Sjaak de Designert. M.a.w.: de complexiteit van de applicatie is T.A.T. duidelijk ten tijde van het design. DAN kun je beslissen wat je doet. Tijdens het bouwen is het simpelweg implementeren van het ontwerp, beslissingen welke lagen er gebouwd dienen te worden moeten dan allang gemaakt zijn. Je argument over wel/niet extra laag is dus m.i. flauwekul.

Je hebt gelijk als een ontwerper doorschiet en een ferrari wil bouwen terwijl een opel gevraagd wordt. Dat heeft echter niets met n-tier/single-crud te maken.

Je argument dat niet alles tot in den treure uitbreidbaar hoeft te zijn is in zekere zin valide, maar is geen argument tegen n-tier development ook niet in sommige gevallen, domweg omdat n-tier development zichzelf scaled naar complexiteitsgraad: hogere complexiteit: meer tiers, lagere complexiteit: minder tiers. Het argument dat je aanvoert is overigens ook gebruikelijk ten favore van eXtreme Programming, waarbij niet gekeken wordt naar eventuele toekomstige toeters en bellen maar alleen hetgeen men NU wil wordt geimplementeerd. M.i. meteen de nagel aan de doodskist van de methodiek.

[maikel]

Ik denk dat paullooijmans het belang van n-tier dev. goed inziet hoor.
En mijns inziens heeft ie gelijk: voor een klein project is het nogal overbodig om het helemaal n-tier op te zetten.
Het bouwen van een extra lagen gaat over het algemeen aardig wat tijd kosten. En zeker voor kleinere projecten is het nutteloos om daar erg veel tijd in te steken terwijl het project zonder extra lagen in zeer korte tijd af kan zijn.
Ik weet dat je dan wat minder flexibel bent, maar voor sommige klanten is de oplevertijd van groter belang dan de flexibiliteit (die soms totaal niet nodig is).

En wat betreft het contact tussen programmeur en klant: dat vind ik helemaal niet slecht. De programmeur kan veel gerichtere vragen stellen en al op voorhand problemen voorleggen. Daarbij is er door de directere communicatiestroom minder kans op verwarring.

[whoami]

[nohtml]

EfBe schreef op 14 February 2003 @ 10:29:
Ik heb net een 3-tier ASP.NET applicatie afgerond (op een paar puntjes na) en ben erg blij met mn middle layer, ookal doet deze veelal niet zo bar veel meer dan datatables omzetten naar een sorted view / filtered view of wat data in meerdere tables stoppen. Ik kan nl. in de gui werken met objects als "SecurityManager" ipv met "Users" en "Roles" tables. Het is dat soort abstractie dat een applicatie simpeler maakt. Eenvoudiger, zoals je wilt.

Ff een vraagje....
Hoe ziet jouw business layer eruit? Ik bedoel dan - als je even dat boek van Fowler erbij neemt -, maak je gebruik van een Table Module of van een Domain Model? Gebruik je (typed) datasets in je BL of maak je gebruik van custom objects?

[EfBe]

maikel schreef op 14 februari 2003 @ 10:39:
Ik denk dat paullooijmans het belang van n-tier dev. goed inziet hoor. En mijns inziens heeft ie gelijk: voor een klein project is het nogal overbodig om het helemaal n-tier op te zetten.

Wat is 'helemaal n-tier' ? Als ik jou de vraag stel: voor een klein project is het dan geoorloofd om in de asp pages meteen SELECT * FROM TABLE te prakken ja of nee? wat is dan je antwoord daarop? (uberhaupt, wat is een klein project?)

Het bouwen van een extra lagen gaat over het algemeen aardig wat tijd kosten. En zeker voor kleinere projecten is het nutteloos om daar erg veel tijd in te steken terwijl het project zonder extra lagen in zeer korte tijd af kan zijn.

Beargumenteer 'gaat over het algemeen aardig wat tijd kosten' eens. Implementatie is veelal maar de helft van de tijd dat een project duurt. Een middle tier kan nl. ook besparing opleveren qua code, je kunt nl. aardig wat code sharen, plus je kunt, ook heel belangrijk, complexe development taken scheiden van minder complexe development taken. Zo kan ik hier HTML-ers met een klein beetje ASP kennis de GUIs laten bouwen met componenten die zijn aangeleverd door anderen, terwijl bij een 1-tier app dat niet gekund zou hebben, want ze moeten dan zelf de querylogica etc erin bouwen.

Ik weet dat je dan wat minder flexibel bent, maar voor sommige klanten is de oplevertijd van groter belang dan de flexibiliteit (die soms totaal niet nodig is).

Oplevertijd is van groter belang dan flexibiliteit? Sinds wanneer gaan klanten voor one-shot applicaties? De enige vorm van one-shot applicaties die we kennen zijn games: nu bouwen, hergebruik is niet aan de orde.

En wat betreft het contact tussen programmeur en klant: dat vind ik helemaal niet slecht. De programmeur kan veel gerichtere vragen stellen en al op voorhand problemen voorleggen. Daarbij is er door de directere communicatiestroom minder kans op verwarring.

Welke 'gerichtere' vragen zou een programmeur moeten stellen in het kader van de informatie-analyse en de analyse van gegevensstromen, bottlenecks in de organisatie en hoe die op te lossen door bv ombuiging van gegevensstromen, digitalisering van gegevensstromen en bv integratie van externe gegevensstromen in de organisatie? Ik zou er geen weten.

[whoami]

maikel schreef op 14 February 2003 @ 10:39:
Ik denk dat paullooijmans het belang van n-tier dev. goed inziet hoor.
En mijns inziens heeft ie gelijk: voor een klein project is het nogal overbodig om het helemaal n-tier op te zetten.
Het bouwen van een extra lagen gaat over het algemeen aardig wat tijd kosten. En zeker voor kleinere projecten is het nutteloos om daar erg veel tijd in te steken terwijl het project zonder extra lagen in zeer korte tijd af kan zijn.
Ik weet dat je dan wat minder flexibel bent, maar voor sommige klanten is de oplevertijd van groter belang dan de flexibiliteit (die soms totaal niet nodig is).

Dat is hetgeen dat EfBe min of meer zegt; het is de designer/architect die beslist hoe de applicatie eruit komt te zien: hij beslist welke lagen er zijn.
Minimaal is het zo dat je toch een scheiding hebt tussen business logica en data logica en GUI. Je gaat zowiezo toch geen BL en Data Logic gaan vermengen, en in de GUI ga je ook geen data-logic of BL verweven.

De oplevertijd zal in jouw geval misschien wel korter zijn, maar wiens oplevertijd zal er het kortst zijn als er nadien nog aanpassingen moeten komen?

Feit is gewoon dat een n-tier applicatie veel beheersbaarder is dan een 1 - tier.

En wat betreft het contact tussen programmeur en klant: dat vind ik helemaal niet slecht. De programmeur kan veel gerichtere vragen stellen en al op voorhand problemen voorleggen. Daarbij is er door de directere communicatiestroom minder kans op verwarring.

Welke gerichte vragen kan hij dan stellen? Een programmeur moet in z'n rol als programmeur geen contact hebben met de klant. Is die programmeur echter ook analyst, dan kan hij in die hoedanigheid wel contact hebben met de klant.
Wat moet een programmeur vragen aan de klant? De programmeur spreekt technisch en gaat ook van een technisch oogpunt uit, de klant gaat uit van een functioneel oogpunt.

[ Voor 3% gewijzigd door whoami op 14-02-2003 10:55 ]

[EfBe]

whoami schreef op 14 February 2003 @ 10:49:
Hoe ziet jouw business layer eruit? Ik bedoel dan - als je even dat boek van Fowler erbij neemt -, maak je gebruik van een Table Module of van een Domain Model? Gebruik je (typed) datasets in je BL of maak je gebruik van custom objects?

Ik ken het boek niet, dus ik moet op gevoel nu een juist antwoord zien te formuleren . Ik gebruik een gegenereerde DAL, die gericht is op tables, dus per table heb je je logica gegroepeerd. Daarnaast heb ik extra code die gericht is op relaties tussen entiteiten in de database. Zitten ook in de DAL. Daarbovenop heb ik een layer, de BL, die niet gericht is op tables maar op functionaliteit. Die heeft dus classes per functionaliteitsgroep, zoals security. De gui praat met die layer, en kan zich puur richten op de functionaliteitsgroep. Ik heb een 3-tier strategie gekozen zonder typed classes en niet een 5-tier met typed classes, omdat ik die complexiteit niet nuttig vond ik dit kader. Ik werk dus met dataviews in de gui, aangeleverd door de BL, en data die naar de database toe moet wordt geinsert door static methods die arraylists of bv strings en ints accepteren.

Achteraf gezien had ik toch graag die extra tier er wel bijgewild, dus typed collections met daarin objects met data per entiteit, dus geen rows in een dataview. Dit heeft als voordeel dat je eventuele database aanpassingen op een centrale plek kunt wijzigen voor je complete applicatie: in de mapperroutine, ipv dat je in de gui daar dingen voor moet wijzigen op wellicht meerdere plekken, maar goed dit is uiteraard afhankelijk van je wijzigingen in de database.

[maikel]

EfBe schreef op 14 februari 2003 @ 10:51:
Wat is 'helemaal n-tier' ? Als ik jou de vraag stel: voor een klein project is het dan geoorloofd om in de asp pages meteen SELECT * FROM TABLE te prakken ja of nee? wat is dan je antwoord daarop? (uberhaupt, wat is een klein project?)

Een klein project is bijv. een website met weinig funtionaliteiten waarbij bijv. alleen wat overzichten getoond worden.
Hierbij is het in mijn ogen onnodig daarvoor een aantal classes te bouwen die de gegevens ophalen. Het enige wat die classes dan zouden doen is het ophalen van de gegevens uit de database en die vervolgens direct doorgeven. Wat is dan de toegevoegde waarde van een extra laag?
Volgens mij niets. Het dient alleen als doorgeefluik voor data.

Beargumenteer 'gaat over het algemeen aardig wat tijd kosten' eens. Implementatie is veelal maar de helft van de tijd dat een project duurt. Een middle tier kan nl. ook besparing opleveren qua code, je kunt nl. aardig wat code sharen, plus je kunt, ook heel belangrijk, complexe development taken scheiden van minder complexe development taken. Zo kan ik hier HTML-ers met een klein beetje ASP kennis de GUIs laten bouwen met componenten die zijn aangeleverd door anderen, terwijl bij een 1-tier app dat niet gekund zou hebben, want ze moeten dan zelf de querylogica etc erin bouwen.

Het goed opzetten van extra lagen kost extra tijd. Vooral om ze zo flexibel en herbruikbaar mogelijk te maken. En als die lagen enkel data doorgeven zonder zelf daar complexe bewerkingen op uit te voeren is dat dus overbodig.
Veel classes zijn overigens ook project-specifiek. Elk project zit weer anders in elkaar (andere DB, andere voorkant, etc.) en daar moeten dus ook weer nieuwe classes voor gebouwd worden.
Overigens zou je die classes dan weer op kunnen splitsen in extra lagen, waarbij de ene laag dus wel generiek is. Maar dat heeft MS dus al voor ons gedaan in het framework.

Oplevertijd is van groter belang dan flexibiliteit? Sinds wanneer gaan klanten voor one-shot applicaties? De enige vorm van one-shot applicaties die we kennen zijn games: nu bouwen, hergebruik is niet aan de orde.

Aan wat voor projecten werk jij dan?
Er zijn genoeg scenario's te verzinnen waarbij de klant snel een website online wil hebben die vervolgens nooit meer verandert. Ik heb ooit een site gemaakt waarbij mensen zich konden inschrijven voor informatiesessies. De klant zelf kon sessies toevoegen, wijzigen, etc.
Maar er waren maar een bepaald aantal sessies. Moet ik daarvoor dan een hoop tijd gaan steken in tiers?
Die klant wil vooral dat de site snel online staat zodat die gebruikt kan worden, niet dat het mogelijk is om zelf via een onderhoudsomgeving de hele site aan te passen!

Welke 'gerichtere' vragen zou een programmeur moeten stellen in het kader van de informatie-analyse en de analyse van gegevensstromen, bottlenecks in de organisatie en hoe die op te lossen door bv ombuiging van gegevensstromen, digitalisering van gegevensstromen en bv integratie van externe gegevensstromen in de organisatie? Ik zou er geen weten.

Dus volgens jou bespreekt een niet-programmeur (een commercieel iemand dus) alle ins en outs van een project?
Wat dan als er een hoop functionaliteiten achteraf, door technische beperkingen of door tijdsgebrek, niet mogelijk blijken te zijn?
Een programmeur kan zulke problemen al ruim van de voren aan zien komen en daar dus met de klant een andere oplossing voor vinden. De programmeur is degene met de kennis over de implementatie. En daar draait het volgens mij toch om.
Ik zeg niet dat de programmeur van begin tot eind bij elke vergadering aanwezig moet zijn, maar 'helemaal nooit' is volgens mij ook niet goed. In mijn ogen is een programmeur toch echt wel wat meer dan iemand die met oogkleppen op code zit te kloppen.

[whoami]

[nohtml]

maikel schreef op 14 February 2003 @ 11:19:
[...]


Dus volgens jou bespreekt een niet-programmeur (een commercieel iemand dus) alle ins en outs van een project?
Wat dan als er een hoop functionaliteiten achteraf, door technische beperkingen of door tijdsgebrek, niet mogelijk blijken te zijn?

Ik denk dat je hier wat mist.
Jij ziet het een beetje te zwart/wit. Niet alle 'niet-programmeurs' zijn commerciele mensen hoor.
Een verkoper probeert de klant misschien te overhalen om toe te happen. Een systeemanalist gaat dan naar de klant, en vraagt wat hij wil, hoe hij het wil, wat hij niet wilt, .... Hier komt er al geen verkoper meer aan te pas.
De systeemanalyst is de brug tussen de klant en het ontwikkelteam (designers/architecten/programmeurs).

Een programmeur kan zulke problemen al ruim van de voren aan zien komen en daar dus met de klant een andere oplossing voor vinden. De programmeur is degene met de kennis over de implementatie. En daar draait het volgens mij toch om.

Hm. De klant is diegene met kennis over de functionaliteit. De klant weet wat hij wil. De programmeur moet dat implementeren, maar die 2 spreken dus een totaal andere taal.

[maikel]

Volgens mij moet er toch echt wel iemand bij zitten die weet wat er precies mogelijk is en welke problemen er kunnen optreden.
De klant weet inderdaad de functionaliteiten, maar weet niet wat de gevolgen van bepaalde wensen zijn. Als de klant iets wil wat haast onmogelijk is, gaat hem dit veel geld of veel tijd kosten. En het is maar de vraag of de klant dat er voor over heeft.
Een programmeur kan hierin meer duidelijkheid verschaffen en ervoor zorgen dat het project eerder opgeleverd kan worden.

Overigens zijn er ook veel klanten die zelf niet eens precies weten wat ze willen.

[whoami]

maikel schreef op 14 February 2003 @ 11:30:
Volgens mij moet er toch echt wel iemand bij zitten die weet wat er precies mogelijk is en welke problemen er kunnen optreden.
De klant weet inderdaad de functionaliteiten, maar weet niet wat de gevolgen van bepaalde wensen zijn. Als de klant iets wil wat haast onmogelijk is, gaat hem dit veel geld of veel tijd kosten. En het is maar de vraag of de klant dat er voor over heeft.

Een analyst weet meestal ook wel wat er mogelijk is en wat niet.

Overigens zijn er ook veel klanten die zelf niet eens precies weten wat ze willen.

Lol, dat moet ik toch nog tegenkomen hoor..... Als een klant niet weet wat hij precies wil, dan heeft hij die applicatie ook niet nodig. In de huidige economische tijden weten klanten maar al te goed wat ze willen.


Trouwens, we gaan hier meer en meer off-topic.

[whoami]

[nohtml]

EfBe schreef op 14 February 2003 @ 11:03:
[...]

Daarbovenop heb ik een layer, de BL, die niet gericht is op tables maar op functionaliteit. Die heeft dus classes per functionaliteitsgroep, zoals security. De gui praat met die layer, en kan zich puur richten op de functionaliteitsgroep. Ik heb een 3-tier strategie gekozen zonder typed classes en niet een 5-tier met typed classes, omdat ik die complexiteit niet nuttig vond ik dit kader. Ik werk dus met dataviews in de gui, aangeleverd door de BL, en data die naar de database toe moet wordt geinsert door static methods die arraylists of bv strings en ints accepteren.

Dus heb je geen DataSets in je BL zitten?
Je table-functionaliteit in je DAL bevat dus een aantal static methods die gewoon een SP oproepen om de gewenste data in te saven/deleten/whatever?

[EfBe]

whoami schreef op:
[nohtml]
[...]

Dus heb je geen DataSets in je BL zitten?
Je table-functionaliteit in je DAL bevat dus een aantal static methods die gewoon een SP oproepen om de gewenste data in te saven/deleten/whatever?

Correct, ik werk niet met datasets maar met datatables. DataSets hebben het nadeel dat ze de DAL abstractie breken in een BL die gefocussed is op functionaliteit, immers als je in een gui een actie in 1 scherm doet, kan dat bv gevolgen hebben voor meerdere tables. De gui roept dan een method aan van het object dat die functionaliteit herbergt, bv SecurityManager. Die regelt het wel in welke tables wat terecht komt. Omdat de DAL gegenereerd is is het bouwen van de applicatie een peuleschil.

[EfBe]

maikel schreef op:
Volgens mij moet er toch echt wel iemand bij zitten die weet wat er precies mogelijk is en welke problemen er kunnen optreden.
De klant weet inderdaad de functionaliteiten, maar weet niet wat de gevolgen van bepaalde wensen zijn. Als de klant iets wil wat haast onmogelijk is, gaat hem dit veel geld of veel tijd kosten. En het is maar de vraag of de klant dat er voor over heeft. Een programmeur kan hierin meer duidelijkheid verschaffen en ervoor zorgen dat het project eerder opgeleverd kan worden.

Dat zijn implementatieproblemen en _NOOIT_ het probleem van de klant. Als ik ergens een stukje hardware bestel en de leverancier begint te piepen dat het vervoer uit Taiwan problematisch is en hij daardoor wellicht kleinere marges moet gaan rekenen en daardoor erg zielig is dan is dat mijn probleem niet. Als de klant een probleem ABC voorlegt aan een oplosser en die oplosser zorgt voor een oplossingsbeschrijving en gaat daarna met prutsers dat realiseren, dan is de oplosser een knoeier en zijn de problemen t.a.t. voor zijn rekening. De klant vroeg om een oplossing, als je die als oplosser dan zegt te kunnen leveren, zijn daarna de problemen die dat met zich meebrengt ook voor jouw rekening. Wat doet een goede oplosser dus? Die consulteert mensen die advies kunnen geven op bepaalde trajecten. Die adviseurs kunnen programmeurs zijn, maar ook collega-designers. Die praten echter niet met de klant, want dat voegt niets toe aan de analyseresultaten.

[ Voor 3% gewijzigd door EfBe op 14-02-2003 13:07 ]

[Scare360]

Er bestaat ook nog zoiets als refactoring, bestaande transaction script patterns voorzien van nieuwe functionaliteit noemen we HACKEN en entiteiten, business entities met daarbij behorende business rules noemen we REFACTOREN. Refactoren is goed te doen en staat zeker niet in de weg bij herbruikbaarheid.

Een model met een Table Module, Domain Model is wel niet van_de_plank herbruikbaar, maar is zeker een goed uitgangspunt (gestandariseerd).

Enne EfBe, DataRaders voor visualisatie zouden al duiden op een slecht ontwerp, zekers niet, voor het vullen voor een comboboxje ga je geen DataTable of DataSet in-memory trekken, maar dat doe je gewoon om de BLL laag heen. Fowler deelt die mening overigens.

[EfBe]

maikel schreef op:
Een klein project is bijv. een website met weinig funtionaliteiten waarbij bijv. alleen wat overzichten getoond worden.
Hierbij is het in mijn ogen onnodig daarvoor een aantal classes te bouwen die de gegevens ophalen. Het enige wat die classes dan zouden doen is het ophalen van de gegevens uit de database en die vervolgens direct doorgeven. Wat is dan de toegevoegde waarde van een extra laag?
Volgens mij niets. Het dient alleen als doorgeefluik voor data.

I take that as a 'yes'.

Webbased overzichten van data uit een database... wat voor data? Data dat ook gebruikt wordt in andere applicaties? Is het dan niet verstandiger die middletier te gebruiken voor je webapp? (het idee achter webservices). Het delen van functionaliteit is 1 van de pijlers van n-tier development. Het kortzichtige one-shot denken snijdt teveel mensen nogaltijd elke dag in de vingers.

Het goed opzetten van extra lagen kost extra tijd. Vooral om ze zo flexibel en herbruikbaar mogelijk te maken. En als die lagen enkel data doorgeven zonder zelf daar complexe bewerkingen op uit te voeren is dat dus overbodig.

Zoals al eerder gezegd: het opzetten van abstractieniveaus, het onderscheiden van layers, kost geen extra tijd want het zit in je ontwerpfase en maakt dus deel uit van de manier waarop je je applicatie ontwerpt. Sterker, ik durf de stelling wel aan dat DOORDAT je alles gelaagd en abstract het weggewerkt, je tijd bespaart, omdat je bij de bouw van iedere page weet waar welke functionaliteit is gebouwd en je meteen die functionaliteit aan je page kunt koppelen, ipv dat je elke keer de functionaliteit opnieuw moet bouwen of op zoek moet naar een soortgelijke page en de code moet copy/pasten (in de volksmond: broddelen).

Veel classes zijn overigens ook project-specifiek. Elk project zit weer anders in elkaar (andere DB, andere voorkant, etc.) en daar moeten dus ook weer nieuwe classes voor gebouwd worden. Overigens zou je die classes dan weer op kunnen splitsen in extra lagen, waarbij de ene laag dus wel generiek is. Maar dat heeft MS dus al voor ons gedaan in het framework.

Hergebruik van generieke code is iets anders. N-tier development levert hergebruik van code BINNEN de applicatie op. Op basis van functionaliteit, niet op basis van implementatiedetails.

Aan wat voor projecten werk jij dan?
Er zijn genoeg scenario's te verzinnen waarbij de klant snel een website online wil hebben die vervolgens nooit meer verandert. Ik heb ooit een site gemaakt waarbij mensen zich konden inschrijven voor informatiesessies. De klant zelf kon sessies toevoegen, wijzigen, etc. Maar er waren maar een bepaald aantal sessies. Moet ik daarvoor dan een hoop tijd gaan steken in tiers? Die klant wil vooral dat de site snel online staat zodat die gebruikt kan worden, niet dat het mogelijk is om zelf via een onderhoudsomgeving de hele site aan te passen!

Ik bouw websites sinds het begin van www, dus sinds netscape 0.x, en al mn klanten hebben wijzigingen gevraagd in de loop der tijd aan de website. Een one-shot 'even dit doen online' sites ken ik niet, wel delen van sites die een of meerdere keren kort werden gebruikt. Doordat vele onderdelen binnen zo'n site al beschikbaar waren, was het bouwen van dat soort sites simpel, itt 1-tier sites die men (en ik dus ook) in het begin maakte met perl/cgi en idc/htx en later asp, waarbij je je een slag in de rondte knoeide met al die code pal achter een page: hergebruik binnen het project uitgesloten.

Dus volgens jou bespreekt een niet-programmeur (een commercieel iemand dus) alle ins en outs van een project?

Ja. Namelijk iemand die veel verstand heeft van functionaliteit en analyses op dat vlak. Iemand met een nerdblik zit alleen maar zichzelf in de weg want neemt tijdens de analyse beslissingen op basis van eventuele implementatieproblemen die daar eventueel achterweg zouden kunnen komen, wat als gevolg heeft dat de klant niet een oplossing krijgt die gebouwd is op basis van gewenste/noodzakelijke functionaliteit, maar op basis van functionaliteit die voortkomt uit de technische capaciteiten van het technisch iemand. Dat soort software is gedoemd te mislukken.

Wat dan als er een hoop functionaliteiten achteraf, door technische beperkingen of door tijdsgebrek, niet mogelijk blijken te zijn?

Tijdens een functionele analyse denk je niet aan implementatie. Je functioneel ontwerp mag ook geen implementatie-details bevatten of beslissingen daarop gebaseerd. In je technisch ontwerp van de functionele subset van het functioneel ontwerp ga je pas kijken hoe je welke functionaliteit het beste kunt realiseren en laat je je adviseren door mensen die weten waarover ze praten. Een developer heeft nl. veelal een tunnelblik die gevormd wordt door de prioriteiten die de developer stelt aan details die samenhangen aan de implementatie van de functionaliteit. Daarom moet je een developer ook invulling laten geven aan functionaliteit waarbij je de grenzen afbakend vooraf. Ik ben zelf een developer en heb dat al lang geleden geleerd. Zelfs na 9 jaar prof. software development vraag ik nog altijd de meest basale dingen aan mensen die daar veel beter in zijn als ik, bv gui design beslissingen en functionele prioriteitstellingen: een developer kan iets belangrijk vinden, wat voor het resultaat an sig geen voordeel biedt, maar wel andere zaken ten nadele beinvloedt. Een developer is ook ondergeschikt aan de software-designer: de designer designt de software die developer bouwt en niet andersom. Wellicht niet leuk voor een developer, maar zo werkt het wel. Developers die de designers gaan zitten verbeteren helpen een project veelal van de regen in de drup (ik hoef hopelijk geen voorbeelden van handmatige aanpassingen aan databasetabellen aan te halen).

Een programmeur kan zulke problemen al ruim van de voren aan zien komen en daar dus met de klant een andere oplossing voor vinden. De programmeur is degene met de kennis over de implementatie. En daar draait het volgens mij toch om.

NEE!!! het draait om de functionaliteit! Hoe die geimplementeerd wordt is ondergeschikt aan de functionaliteit die moet worden opgeleverd. Dit houdt dus OOK in dat als je een Microsoft-jehova bent als developer en op Linux is toevallig het geheel beter te realiseren, je eigenlijk daarvoor moet kiezen. Omdat de developer die beslissingen niet rationeel kan maken wordt dat voor hem gedaan, en geeft precies aan waarom de developer de designer volgt en niet andersom.

Ik zeg niet dat de programmeur van begin tot eind bij elke vergadering aanwezig moet zijn, maar 'helemaal nooit' is volgens mij ook niet goed. In mijn ogen is een programmeur toch echt wel wat meer dan iemand die met oogkleppen op code zit te kloppen.

Binnen een team dat de applicatie bouwt kan de developer natuurlijk meevergaderen en problemen signaleren en oplossingen daarvoor aandragen. Echter altijd als ondersteuning van de designer. Immers: alleen dat levert een ontwerp op dat je als basis kunt gebruiken!! Alle andere 'ad hoc' aanpassingen van wat ooit eens ontworpen is door de developer worden niet toegevoegd aan het ontwerp of erger: worden niet verwerkt in het ontwerp en vanaf daar doorgerold naar de implementatie. Bv 'even een veldje in de database erbij'. Mensen die dat doen/denken vernaggelen zoveel in de IT-business, dermate veel dat anno 2003 de IT-business nog steeds een slechte naam heeft, mede door dat soort prutsers. Ipv dat ze het datamodel aanpassen in ORM/NIAM of andere hogere orde methodiek en daarna daaruit een E/R model distilleren en DAN de database daarmee gaan aanpassen.... Zie je het verschil? Het eerste, ff dat veld erbij, is zo gedaan, kost weinig moeite en weinig overhead. Het laatste is echter solide en waarborgt een zekere zekerheid dat het project niet verknoeid wordt gedurende de developmentfase.

[EfBe]

paulgielens schreef op:
Enne EfBe, DataRaders voor visualisatie zouden al duiden op een slecht ontwerp, zekers niet, voor het vullen voor een comboboxje ga je geen DataTable of DataSet in-memory trekken, maar dat doe je gewoon om de BLL laag heen. Fowler deelt die mening overigens.

Wie is Fowler? Ik ken hem niet, dus wat zijn mening is laat me eerlijk gezegd koud. Een datareader exporteren naar je gui, plakt je dal in je gui, een datareader is nl. een open database connectie, je moet in je gui record-checking doen om door de rows te lopen. Een datatable / dataview opleveren in je BL heeft die nadelen niet, en je levert een herbruikbaarheid op. Zo kan ik de ene keer een repeater vullen met mn roleview, en de andere keer een comboboxje met mn roleview op een andere page. Ik weet dat dat solide in elkaar zit, want ik kan zonder gezeik mn tiers verplaatsen naar andere bakken, zoals bv dit forum ook doet, een webfarm inzetten uberhaupt, wat veel sites tegenwoordig doen. Het gaat om de semantiek van het geheel: datareaders vernaggelen erg veel aan je ontwerp. Gebruik je datareaders, hou dan ook asjeblieft op met jezelf voor de gek houden dat je n-tier bezig bent, en prak lekker alles in de codebehinds.

[Alarmnummer]

Martin Fowler


boeken

[ Voor 17% gewijzigd door Alarmnummer op 14-02-2003 13:50 ]

[EfBe]

Oh dear, een extreme programming aanhanger. Vandaar dat hij er anders over denkt dan ik.

[Scare360]

Wat Fowler zegt goes, en jij snapt extreme programming niet Lees eens iets over refactoring zou ik zeggen, dan kun je misschien EX plaatsen zoals het bedoeld is.

Een stafull/stateless omgeving is goed te combineren hoor... het beste van 2 werelden kan ook wel eens lekker zijn.

[EfBe]

paulgielens schreef op 14 February 2003 @ 14:28:
Wat Fowler zegt goes, en jij snapt extreme programming niet Lees eens iets over refactoring zou ik zeggen, dan kun je misschien EX plaatsen zoals het bedoeld is.

heh. Ik heb serieus me verdiept in Extreme Programming (EX) (ik zeg maar even geen 'XP' om verwarring met het ms os te voorkomen ) en het enige dat me erg aanstond was de 2-mans programmeertandems. Echter, men mag pas van EX spreken als je een heel scala aan rules (begrijpelijk) accepteert en ik ben pertinent tegen inmening van klanten tijdens ontwikkeltrajecten. Refactoring klinkt inderdaad leuk, maar is een implementatie-technisch truukje. Aanpassingen op basis van functionele wijzigingen gaan veel verder dan je met wat refactoring kunt verhelpen. (zoals je wel sourcecode met de hand wat kunt gaan optimizen, maar een ander algoritme of algoritme-reeks kan veel meer opleveren)

Een stafull/stateless omgeving is goed te combineren hoor... het beste van 2 werelden kan ook wel eens lekker zijn.

Als we praten over stateful los van de altijd aanwezige userstate, dan lijkt het me totaal niet te combineren met een stateless ontwerp. Ik zie overigens zelden nog het nut in van stateful ontwerpen, wellicht alleen bij single-user client applicaties, waarbij je er zeker van kunt zijn dat de data die de applicatie nodig heeft, gewoon in de usersessie geladen kan worden, immers er is maar 1 user.

[Alarmnummer]

EfBe schreef op 14 February 2003 @ 14:45:
[...]

heh. Ik heb serieus me verdiept in Extreme Programming (EX) (ik zeg maar even geen 'XP' om verwarring met het ms os te voorkomen ) en het enige dat me erg aanstond was de 2-mans programmeertandems. Echter, men mag pas van EX spreken als je een heel scala aan rules (begrijpelijk) accepteert en ik ben pertinent tegen inmening van klanten tijdens ontwikkeltrajecten.

Je kunt ook gerust afzonderlijke technieken van XP gebruiken, zoals idd pairprogramming maar ook design patterns, unit testing en refactoring.

Refactoring klinkt inderdaad leuk, maar is een implementatie-technisch truukje. Aanpassingen op basis van functionele wijzigingen gaan veel verder dan je met wat refactoring kunt verhelpen.

Je hebt gelijk dat op het gebied van architectuur aan een systeem niet echt veel veranderd met refactoring. Maar slechte code waar nog een beetje structuur in zit, kan je in ieder geval wel een stuk toegankelijker en logischer maken. Verder kan je als je zelf genoeg inzicht bezit ook gerust een systeem kapot breken en dan alsnog een betere architectuur erin plaatsen (voor zover dit mogelijk is natuurlijk, soms kan je beter opnieuw beginnen *kijkt naar het kut project voor hem*

(zoals je wel sourcecode met de hand wat kunt gaan optimizen, maar een ander algoritme of algoritme-reeks kan veel meer opleveren)

Refactoring gaat niet over het sneller maken van code, maar om het verbeteren van de kwaliteit.

[Alarmnummer]

Ik heb je laatste stuk verkeerd begrepen. Je maakt een vergelijking tussen een beter algoritme en een betere architectuur tegenover een geoptimaliseerde algoritme en een bijgeschaafde architectuur.

Soms is het handig om niet alles weg te gooien, maar gewoon wat punten bij te schaven. Ik doe het ook genoeg met allerlei projecten van mezelf omdat ik ook genoeg heb bijgeleerd. Soms gooi ik het helemaal weg, maar meestal is het nog dermate goed van kwaliteit dat er alleen wat bijschaafwerkzaamheden verricht hoeven te worden.

[EfBe]

Alarmnummer schreef op 14 februari 2003 @ 15:31:
Ik heb je laatste stuk verkeerd begrepen. Je maakt een vergelijking tussen een beter algoritme en een betere architectuur tegenover een geoptimaliseerde algoritme en een bijgeschaafde architectuur.

Precies:
beter algoritme DEF vs geoptimaliseerd algoritme ABC als metafoor voor
betere structuur DEF vs bijgeschaafde structuur ABC.

Natuurlijk heeft refactoring zn plaats. Echter, je moet je ook realiseren dat als je veel refactoring nodig hebt, je ook tijd in feite weggooit, immers had je iets meer tijd besteed aan het nadenken, had je het wellicht in 1 keer goed gedaan. Een van de redenen waarom sommigen het wel eens wensten dat ze de mogelijkheid hadden in hun veel te dure IDE (VS.NET ) maar ook weer niet zovaak dat het een nijpend gemis blijkt

Soms is het handig om niet alles weg te gooien, maar gewoon wat punten bij te schaven. Ik doe het ook genoeg met allerlei projecten van mezelf omdat ik ook genoeg heb bijgeleerd. Soms gooi ik het helemaal weg, maar meestal is het nog dermate goed van kwaliteit dat er alleen wat bijschaafwerkzaamheden verricht hoeven te worden.

Tuurlijk, net zoals er geen programmeur op aarde is te vinden die lovend zal zijn over iemand anders zn stukje code, zo zal er ook geen programmeur ter wereld te vinden zijn die na een tijdje niet denkt "dat had wellicht anders gekund" bij het bekijken van eigen code. Het opnieuw implementeren van al gerealiseerde functionaliteit of het aanpassen van bestaande implementaties is overigens een discussie op zich

[Verwijderd]

Heren, ik denk dat we het op veel punten eens zijn met elkaar wat betreft N-tier ontwikkeling, de voordelen zijn voor mij overduidelijk. Wat ik probeer duidelijk te maken is dat er, zoals met bijna alles in het leven, naast voordelen ook nadelen verbonden zijn aan het kiezen voor een bepaalde oplossing.

Ik zal proberen de discussie nog scherper te stellen, zodat we hopelijk tot een compromis kunnen komen. Van het slechts ventileren van onze eigen meningen worden we immers niet veel wijzer.

Waar het in deze volgens mij om gaat is de vraag: kies ik voor de oplossing GUI/Events + BLL/DAL + SP/DB of ga ik voor de oplossing GUI/Events + SP/DB.

Als ik de argumentatie van EfBe volg zou de laatste optie zo ongeveer bij wet verboden moeten worden op straffe van 15 jaar eenzame opsluiting, want het zou de IT in een kwaad daglicht stellen, applicaties volledig on-onderhoudbaar maken en nog meer van dat soort ergs. Ik denk dat als we nog even doorgaan dat EfBe ook nog wel links ontdekt tussen 1-tier programmeren en Osama Bin Laden

Zelf kies ik, ingegeven door mijn praktijkervaring, toch voor een iets genuanceerde opstelling. De kern van mijn betoog wordt gevormd door de stelling dat het opzetten van een BLL/DAL, zelfs met het gebruik van code generators, initieel meer tijd kost dan het opzetten van een functioneel vergelijkbare applicatie zonder een dergelijke tussenlaag. Over onderhoudbaarheid en flexbiliteit hoor je van mij niets, ik ben het volledig eens met de stelling dat deze door het gebruik van een BLL/DAL laag verbeterd worden. Dat het op termijn misschien wel goedkoper wordt om functionaliteit bij te bouwen wil ik ook nog wel geloven.

Die tijd dus, daar zit mijn pijn. Tot zover de theorie. Over naar de praktijk:

Zoals EfBe al terecht opmerkte hebben we het hier over enterprise development, niet over de website over de poppenverzameling van tante Sjaan. Dat klinkt natuurlijk heel duur, enterprise development, maar waar het in de praktijk op neerkomt is dat deze enterprises zoveel mogelijk waar voor hun geld willen hebben en snel ook want er moet geld verdient worden met die applicatie. Nou weet ik niet hoe het bij EfBe, whoami,paulgielens en Alarmnummer gaat, maar ik heb dus meestal te maken met fixed price en vaak ook fixed date.

Jullie zijn vast allemaal bekend met de driehoek prijs-tijd-functionaliteiten. De klant mag met die drie variabelen schuiven, maar het moet allemaal wel in balans blijven: meer functionaliteiten in minder tijd == meerprijs. Een mindere prijs leidt tot minder functionaliteiten en/of een langere doorlooptijd etc. etc.

Als we nu uitgaan van voornoemde driehoek en aannemen dat prijs en tijd vastgezet zijn en verder er van uit gaan dat we N-tier willen bouwen dan moet dat leiden tot de conclusie dat we toch echt minder functionaliteiten kunnen realiseren voor onze gewaardeerde klant.

En dit is waar het volgens mij allemaal op neerkomt: maak ik mijn klant wel blij als hij een perfect N-tier systeem krijgt als daar slechts de helft van de door hem gewilde functionaliteiten in verwerkt zitten? wat ga ik hem dan vertellen? Dat het systeem nu wel eenvoudig uitgebreid kan worden of dat hij nu wel van database kan wisselen zonder al te grote problemen? Sluit nu je ogen en visualiseer dat je dit tegen een klant verteld:

"Ja meneer, het systeem is op tijd af en binnen budget, zoals afgesproken. Het is verder volledig N-tier opgezet! Ik ben echt tevreden over mij opzet want ik heb DataTables gebruikt ipv DataReaders. Wat? Oh ja, die reporting, die hebben we er uit moeten laten want daar was geen tijd meer voor. Maar die is er eenvoudig bij te bouwen hoor, kost maar 10000 euro."

Ik weet niet wat jullie zien, maar ik zie een rood aangelopen en zeer pissige klant voor me. EfBe begrijpt dat dan waarschijnlijk niet want hij heeft toch DataTables gebruikt ipv DataReaders. Hoe kan de klant nu ontevreden zijn?

EfBe, ik heb veel respect voor de door jouw tentoongestelde kennis, je weet waar je over praat. Maar kom in godsnaam uit je ivoren toren, ik heb inmiddels voldoende ervaring in de loopgraven van IT om te weten dat deadlines ook invloed moeten hebben op jouw beslissingen. Je verhalen getuigen van een ouderwetse, achterhaalde manier van softwareontwikkeling: Laat het maar aan de IT over, "they know what's best", als de klant het beter weet dan zouden ze het wel zelf doen. Wrong! Het is JOUW verantwoordelijkheid om de beste oplossing voor je klant te kiezen, zoals je zelf gezegd hebt. Het is dus ook de klant die, impliciet (via de prijs die hij bereid is te betalen) of expliciet, de keuze moet maken voor een verantwoorde, qua architectuur correcte, oplossing of voor wat jij zou noemen de quick fix. Ik ben van mening dat een oplossing die gebruik maakt van GUI/Events/SP/DB de toets der kritiek in veel gevallen kan weerstaan. Ik zou het ook liever anders zien en ik zal blijven streven de meest verantwoorde oplossing te kiezen, ASP.NET is wat dat betreft al een hele vooruitgang vergeleken met ASP, zoals Stored Procedures ook al een flinke verbetering zijn tov SQL statements in de code. Ik kijk met veel interesse uit naar ontwikkelingen als MSFT Yukon/ObjectSpaces die het (hopelijk) een stuk eenvoudiger en dus minder tijdrovend moeten maken om een verantwoorde oplossing voor de klant neer te kunnen zetten.

whoami, paulgielens, jullie herhaalde referenties naar het boek van Fowler (die foto was echt niet nodig ) doen mij vermoeden dat ook jullie het gevaar lopen ten prooi te vallen aan het architectionisme/architectonisch fundamentalisme dat EfBe aanhangt. Ik vind het heel goed dat jullie je verdiepen in deze ingewikkelde materie en jullie hebben me zeker nieuwsgierig gemaakt naar het boek van Fowler, maar neem als leidraad voor je werk niet de beste technische oplossing maar wat de beste oplossing voor je klant is. En dat is zeker niet altijd dezelfde oplossing!

Heren, het was me een genoegen met u over dit onderwerp van gedachte te wisselen. Ik ben benieuwd of ik jullie met bovenstaande redenering heb kunnen overtuigen van de kwaliteiten van de not-so-many-tier oplossing

[maikel]

Amen !

Ik ben het hier dus volledig mee eens. (hoewel ik het zelf nooit zo mooi verwoord zou kunnen hebben )

[EfBe]

whoami schreef op 12 februari 2003 @ 14:17:
Ik zou ook wel eens een 'real-life' example willen zien van een n-tier enterprise application met de nodige layers en hoe de communicatie tussen die layers is.

Wellicht zijn je gebeden verhoord MS heeft een nieuw sample gereleased: http://www.windowsforms.n....aspx?tabIndex=7&tabId=44

[EfBe]

Verwijderd schreef op 14 februari 2003 @ 23:35:
Heren, ik denk dat we het op veel punten eens zijn met elkaar wat betreft N-tier ontwikkeling, de voordelen zijn voor mij overduidelijk. Wat ik probeer duidelijk te maken is dat er, zoals met bijna alles in het leven, naast voordelen ook nadelen verbonden zijn aan het kiezen voor een bepaalde oplossing.

N-tier development is schaalbaar, het past zich aan aan je situatie. Je refereert naar nadelen die er niet zijn.

Waar het in deze volgens mij om gaat is de vraag: kies ik voor de oplossing GUI/Events + BLL/DAL + SP/DB of ga ik voor de oplossing GUI/Events + SP/DB.

Nee, waat het om gaat is of je inziet dat n-tier development een design aangelegenheid is, die puur bedoeld is voor het abstract maken van functionaliteitsgroepen. Jij zit op het abstractieniveau van implementatie, ik niet, althans niet in deze discussie. En daar zit het hem nu in. Jij wilt niet begrijpen dat bij het ontwerpen van je software je de n-tier methodiek gebruikt, en dat je daarna pas gaat implementeren. Degene die de code intikt is niet bezig te verzinnen of hij n-tier development moet toepassen, dat is voor hem gedaan.

Nu stel je of een oplossing, bestaande uit gui/events + sp/db, valide is. Dat is niet te beoordelen, want dat hangt van de situatie af en TE ALLEN TIJDE van het ontwerp. M.a.w. het ontwerp dicteert of je 2 tiers hebt of 3, of 5. Zoals al eerder gezegd, schaalt n-tier met je mee en pas je het toe op basis van de functionaliteit die geimplementeerd moet worden. Alleen op die basis kies je voor je tier-hoeveelheid. Niet op basis van implementatiedetails als 'dat gaat overhead opleveren' of 'dat is traag'. Immers, beide moet je met cijfers kunnen aantonen dat het overhead oplevert t.o.v. een platgeslagen oplossing en dat het trager is dan een platgeslagen oplossing. Uit de losse pols redeneren dat dat dan wel zo zal zijn is, sorry, dom en kortzichtig.

Als ik de argumentatie van EfBe volg zou de laatste optie zo ongeveer bij wet verboden moeten worden op straffe van 15 jaar eenzame opsluiting, want het zou de IT in een kwaad daglicht stellen, applicaties volledig on-onderhoudbaar maken en nog meer van dat soort ergs. Ik denk dat als we nog even doorgaan dat EfBe ook nog wel links ontdekt tussen 1-tier programmeren en Osama Bin Laden

Ik snap niet waarom dit hier staat, en ik kap nu met deze discussie. Ik heb meerdere keren aangegeven waar in het ontwikkeltraject n-tier development aan de orde komt en hoe met als logisch gevolg dat wanneer je het in andere delen van het ontwikkeltraject toepast je verkeerd bezig bent. Verderop lees ik dat ik in een ivoren toren zit. Come again? Ik weet echt wel waarover ik praat en hoe je software ontwikkelt. Iedere universiteit en hogeschool zal je die methodieken leren. Als je zelf zo'n opleiding hebt gevolgd weet je dat. Je weet dan ook dat ik absoluut geen onzin praat als ik het heb over wie welke analyses doet en wie wat ontwerpt en wie die ontwerpen op welke wijze realiseert.

Ik ben van mening dat ik heb gezegd wat ik wilde zeggen in deze dicussie. Als je dat niet aanstaat meneer Looijmans, dan is dat jammer. Ik zou je wel willen waarschuwen voor je kortzichtigheid mbt het toepassen van technieken voor betalende klanten.

[EfBe]

maikel schreef op 15 February 2003 @ 03:48:
Amen !

Niks 'Amen'. Get yourself educated.

Ik ben het hier dus volledig mee eens. (hoewel ik het zelf nooit zo mooi verwoord zou kunnen hebben )

Dat lag in de lijn der verwachting. Heb je uberhaupt IETS begrepen van wat ik gezegd heb? Wellicht ten overvloede: wat ik gezegd heb is niet iets wat ik gisteren heb gelezen in een artikeltje, maar een voortvloeisel van lang nadenken over de materie, tests doen, in de praktijk brengen, evalueren, en dat al jarenlang.

Geen tijd gehad om het in boekvorm te gieten, maar misschien moet ik dat toch maar eens doen, dan word je kennelijk wel voor vol aangezien.

Maikel: herlees de teksten totdat je ze begrijpt. Je POV snap ik, die had ik jaren geleden vlak na mn afstuderen ook, maar zo zit de werkelijkheid niet in elkaar, althans de werkelijkheid waarbij softwareprojecten wel slagen.

[maikel]

EfBe schreef op 15 februari 2003 @ 10:26:
[...]

Niks 'Amen'. Get yourself educated.


[...]

Dat lag in de lijn der verwachting. Heb je uberhaupt IETS begrepen van wat ik gezegd heb? Wellicht ten overvloede: wat ik gezegd heb is niet iets wat ik gisteren heb gelezen in een artikeltje, maar een voortvloeisel van lang nadenken over de materie, tests doen, in de praktijk brengen, evalueren, en dat al jarenlang.

Geen tijd gehad om het in boekvorm te gieten, maar misschien moet ik dat toch maar eens doen, dan word je kennelijk wel voor vol aangezien.

Maikel: herlees de teksten totdat je ze begrijpt. Je POV snap ik, die had ik jaren geleden vlak na mn afstuderen ook, maar zo zit de werkelijkheid niet in elkaar, althans de werkelijkheid waarbij softwareprojecten wel slagen.

Ik begrijp heel goed wat jij zegt hoor. Maar ik begrijp ook heel goed wat paullooijmans te vertellen heeft. En daar ben ik het toch echt veel meer mee eens dan met jou standpunt. Ik begrijp goed wat je wilt zeggen, maar ik weet dat dat niet voor elke situatie geldt. Maar blijkbaar wil jij blijven vasthouden aan de theorieen die je ooit tijdens een opleiding hebt geleerd of ergens gelezen. Uit de praktijk blijkt echter dat de theorieen niet altijd toepasbaar zijn.

Uit de praktijk blijkt ook dat een heel groot deel van softwareprojecten uitlopen of teveel gaan kosten. En dat is volgens mij meer realiteit dan jouw 'realiteit'.
Misschien moet je eens een tijdje gaan rondkijken op http://www.dsdm.com/

PS.
Ik heb ook nog bij een bedrijf gewerkt die elke website n-tier opzette.
Die zijn nu failliet.

[ Voor 10% gewijzigd door maikel op 15-02-2003 10:49 ]

[Verwijderd]

EfBe schreef op 15 February 2003 @ 10:19:
[...]
N-tier development is schaalbaar, het past zich aan aan je situatie. Je refereert naar nadelen die er niet zijn.

Wie heeft het over schaalbaarheidsproblemen gehad dan? Ik niet hoor, ik heb EEN nadeel genoemd van het toepassen van een BLL/DAL en dat is dat het extra tijd kost. Ik weet dus niet waar je dit vandaan haalt.

Jij wilt niet begrijpen dat bij het ontwerpen van je software je de n-tier methodiek gebruikt, en dat je daarna pas gaat implementeren. Degene die de code intikt is niet bezig te verzinnen of hij n-tier development moet toepassen, dat is voor hem gedaan.

Dat wil ik wel begrijpen, wat ik wil zeggen is dat het, itt wat jij lijkt te beweren, geen doodzonde is om in de analysefase, wanneer de situatie daar om vraagt (door tijd/geld constraints of omdat de applicatie zich nu eenmaal niet leent voor hergebruik) te kiezen voor een oplossing zonder een BLL/DAL.

Nu stel je of een oplossing, bestaande uit gui/events + sp/db, valide is. Dat is niet te beoordelen, want dat hangt van de situatie af en TE ALLEN TIJDE van het ontwerp.

Mooi, dan ben je het blijkbaar toch met me eens, want in je eerdere posts miste ik deze nuance. Het leek alsof zo'n keuze NOOIT valide kon zijn.

Niet op basis van implementatiedetails als 'dat gaat overhead opleveren' of 'dat is traag'.

[...]

Uit de losse pols redeneren dat dat dan wel zo zal zijn is, sorry, dom en kortzichtig.

Dom en kortzichtig? Nee hoor, is gebaseerd op logica (>LOC == >tijd, meer analyse == >tijd) en ervaring.

Verderop lees ik dat ik in een ivoren toren zit. Come again? Ik weet echt wel waarover ik praat en hoe je software ontwikkelt. Iedere universiteit en hogeschool zal je die methodieken leren.

Dat je in een ivoren toren zit wil nog niet zeggen dat je niet weet waar je over praat, ik vind alleen dat jouw redenatie een bepaalde realiteitszin ontbeert die ik wel meer zie bij gesprekken over 'enterprise development', alsof dat een soort 'holy grail' is waarbij alleen maar de beste oplossingen bestaan: de 'beste' oplossing is niet altijd de meest architectonisch verantwoorde oplossing.

Ik vind het heel belangrijk dat in dit soort discussies een zeker nuance gebruikt wordt. Wat ik jou hoor zeggen is dat de GUI/Events/SP/DB architectuur altijd slecht is, dat ik er de ballen van snap, slecht en onverantwoord bezig ben etc. en daar ben ik het pertinent mee oneens. De beslissing om op die manier te bouwen kan, gegeven de omstandigheden in bepaalde projecten een goede design beslissing zijn. In je laatste post breng je die nuance volgens mij wel aan, dus denk ik dat we het wat dat betreft eens zijn.

Ik zou je wel willen waarschuwen voor je kortzichtigheid mbt het toepassen van technieken voor betalende klanten.

uhhmmmmm, thanks? Dan wil ik je waarschuwen om niet te gaan zwemmen binnen een uur na je maaltijd. Is ongeveer net zo to the point.

Jouw afkeer van moderne projectmethodieken zoals XP (DSDM zul je ook wel niets vinden) duidt erop dat je wat dat betreft nog ouderwets bezig bent en ik ben van mening dat jouw klanten daar niet altijd bij gedient zijn.

[Alarmnummer]

Als ik eerlijk ben zou ik het me ook niet kunnen voorstellen om nog een 2 tier applicatie op te zetten (applicatie,db). Op dit moment werk ik dus aan een systeem waar de business logica direct achter gui events zit (ook de db code) en het valt gewoon niet te onderhouden. Alles ligt overal verspreid en je krijgt gewoon geen overzicht van de functionaliteit.

Ik werk zelf liever met objecten die de concepten, zoals ik ze voor zie, uitbeelden. Zoals bv een Order, Klant etc. Op deze manier kan je heel eenvoudig alle logica overzien en eenvoudig functionaliteit toevoegen. En in een ander layers hou je dan bezig met andere zaken zoals bv gui of data. En als ik iets wil aanpassen, dan weet ik ook waar ik moet zijn. En daarnaast hoef ik ook niet bang te zijn dat er inconsistenties ontstaan als er business logic dubbel instaat, maar toch niet iets van elkaar verschilt. Probeer dit soort ellende maar eens te vinden in een 2 tier applicatie.

Ik ben het alleen wel met jullie eens dat er veel tijd gaat zitten in het bouwen van deze layers. En dat is dus ook de reden dat ik dit topic ben begonnen.

[Alarmnummer]

[half-offtopic]

Raden jullie ook nog literatuur aan?

[Verwijderd]

Het boek van Professor EfBe. WHAAHAHHAHAHAAHAHAHAHAHA...

Just kidding.

Persoonlijk denk ik dat de problemen in enterprise minder veroorzaakt worden door techniek en meer door mensen, of beter gezegd de gebrekkige communicatie tussen de ontwikkelaars en de klant, die mi alleen maar verergerd wordt als je er nog een analist tussen zet ook. Niet dat zo'n analist geen waardevolle rol kan spelen, maar ik zie hem als een lid van het team en niet als een tussenschakel.

Daarom vond ik het bericht van whoami waarin hij stelde dat klanten precies weten wat ze willen zo vreemd, mijn ervaring is dat, mede omdat de requirements vanuit de enterpise zo aan verandering onderheving zijn, de requirements en prioriteiten ook steeds veranderen en je dus vooraf, zelfs met een diepgaande analyse, niet precies kan achterhalen wat een klant precies nodig heeft.

Daarom sluit ik me bij deze aan bij maikel en adviseer ik je de website van DSDM (http://www.dsdm.nl) te bezoeken. Die ontwikkelmethodiek spreekt mij erg aan en bevat zeker informatie die je anders naar het opzetten van een enterprise applicatie zal laten kijken.

[Alarmnummer]

Maar dit is niet zozeer een ontwikkeltechniek waarmee je een architectuur bepaald, maar eerder een managment techniekn. Het heeft imo niets te maken met tiers/layers ed.

Verder kan ik me uitstekend in dsdm vinden.

En verder maakt het voor mij op dit moment niet zoveel uit of de analist nu wel of geen deel uitmaakt, want ik ben toch alles in 1 En thuis ben ik ook nog eens klant bij mijn testprojecten.

[ Voor 34% gewijzigd door Alarmnummer op 15-02-2003 13:08 ]

[Verwijderd]

Daar heb je gelijk in, ik dacht: als we dan toch half off-topic bezig waren dan kan dit er ook nog wel bij

Toch heeft het er, ergens, wel mee te maken: DSDM gaat er van uit dat een oplossing 'good enough' moet zijn en niet perfect, want daar is helaas geen tijd voor (beetje kort door de bocht).

Dat is mi ook een overeenkomst tussen DSDM en XP: prototyping, dus niet eerst heel de applicatie opzetten maar gaandeweg 'ontdekken' wat je nodig hebt. Heel erg gericht op de alledaagse praktijk dus.

Dat wil overigens niet zeggen dat er in die methodieken geen plaats zou zijn voor architectuur, maar het heeft zeker niet de standing die het in andere methodieken heeft.

[Alarmnummer]

XP wil niet zeggen dat je alles in 1 keer moet ontwikkelen hoor. Ontwikkelen is nu eenmaal een iteratief proces. Je zal in het begin wel een bepaalde basis architectuur moeten opzetten, maar alles van te voren gaan ontwerpen is onmogelijk.

[edit]
*loopt te blaten*... ik zie dat je DSDM ook beschouwt als iteratief. *had niet zoveel moeten drinken gisteren*

[ Voor 22% gewijzigd door Alarmnummer op 15-02-2003 13:13 ]

[tijn]

Alarmnummer schreef op 15 February 2003 @ 12:35:
[half-offtopic]

Raden jullie ook nog literatuur aan?

Ik zou het niet weten. IMHO staat het boek van Fowler op dit moment op eenzame hoogte omdat daarin een compleet beeld geschetst wordt van de mogelijkheden die er zijn. Hij is niet te beroerd om ook aandacht te besteden aan Transaction Script en Table Module oplossingen die door OO puristen vaak verfoeid worden.

[Alarmnummer]

tijn schreef op 15 February 2003 @ 13:13:
[...]

Ik zou het niet weten. IMHO staat het boek van Fowler op dit moment op eenzame hoogte omdat daarin een compleet beeld geschetst wordt van de mogelijkheden die er zijn. Hij is niet te beroerd om ook aandacht te besteden aan Transaction Script en Table Module oplossingen die door OO puristen vaak verfoeid worden.

Ik vind dat idd ook erg fijn aan zijn boek. Hij geeft een oplossing voor een bepaald probleem, maar ook meteen alternatieven en wanneer je beter zo`n alternatief kan gebruiken.

[whoami]

maikel schreef op 15 February 2003 @ 10:46:

Uit de praktijk blijkt ook dat een heel groot deel van softwareprojecten uitlopen of teveel gaan kosten. En dat is volgens mij meer realiteit dan jouw 'realiteit'.
Misschien moet je eens een tijdje gaan rondkijken op http://www.dsdm.com/

De grootste kost bij software-projecten zit hem meestal niet in de ontwikkeling van de applicatie. De grootste kost zit/zat hem meestal bij het onderhoud van de applicatie. En hoe komt dat denk je? Omdat het een groot kluwen was van business-logica, data-logica en presentatie - logica.
Waarom denk je dat alle grote software-bedrijven in n-tier zijn gaan denken? Waarom denk je dat Sun en Microsoft n-tier propageren? Niet noodzakelijk om hun eigen zak te vullen. Men heeft ingezien dat een n-tier opzet veel beheersbaarder is en dus ook minder geld zal kosten bij onderhoud en aanpassingen.
Ik daag je uit om eens een 1-tier applicatie te debuggen of te onderhouden.

Wat is de meerprijs om een applicatie in n-tier te ontwikkelen? De eerste keer dat je dat doet, zal je zeker meer werk hebben. Je zult op een andere manier moeten gaan denken, je hebt een iets ingewikkeldere architectuur nodig, maar die zorgt er dan wel voor dat het geheel logischer en duidelijker is.
Wat zijn de voordelen? Je kunt code hergebruiken (bij een 1-tier app. is dat niet het geval), code-reuse levert kortere ontwikkeltijden; Het geheel is beheersbaarder en onderhoudbaarder-> minder tijd en geld nodig om aanpassingen te doen. Het is schaalbaarder -> dus, de software kan langer gebruikt worden en is flexibeler.

Waarom zou iedere zichzelf respecterende ontwikkelaar voor n - tier gaan, als 1-tier volgens jou zoveel beter is?

PS.
Ik heb ook nog bij een bedrijf gewerkt die elke website n-tier opzette.
Die zijn nu failliet.

En wat wil je daar mee zeggen? Ik zie geen enkele correlatie tussen het failliet zijn van het bedrijf en het feit dat ze alles in n-tier opgezet hebben.

[Scare360]

Maar m.b.t. totaal oplossingen, die zijn er dus niet. Verder dan mapping (ORDAL) met alle beperkingen vandien komen we dus niet. EJB doet een poging, maar is gedeeltelijk geslaagd.

n-tier? Ik ben nog steeds van mening dat Fowler hier DE kijk op geeft in zijn meesterlijk boek, maar er lijkt nog steeds behoefte te zijn aan het opzetten en koppelen van een Domain Model aan je persist data scheme.

Het is en blijft afwegen van belangen, eigenwijsheid, methodische verantwoording waar we allemaal een ander idee over hebben. Met andere woorden het lijkt wel politiek hier.

ps: ik mis trouwens Martin en Otis in deze discussie


edit: Ik ben niet blij, geen Domain Model in die nieuwe MS-demo, en DAAR zit ik nu net op te wachten.

[ Voor 12% gewijzigd door Scare360 op 15-02-2003 13:42 ]

[Alarmnummer]

Otis is ook aanwezig

[Verwijderd]

whoami schreef op 15 februari 2003 @ 13:23:

[...]

Waarom zou iedere zichzelf respecterende ontwikkelaar voor n - tier gaan, als 1-tier volgens jou zoveel beter is?

[...]

Je polariseert de zaak whoami, maikel heeft helemaal nergens gezegd dat 1-tier ontwikkeling beter is. Maikel stelt, net zoals ik, dat het geen doodzonde is om niet N-tier te ontwikkelen als de situatie daarom vraagt. Ik geloof dat zelfs EfBe het met die stelling eens is.

Over hoe het optimaal moet kunnen wij het denk ik snel eens zijn: geef mij genoeg tijd en genoeg geld en ik bouw voor jou de mooiste BLL/DAL die je ooit gezien hebt. Maar de praktijk werkt anders en de praktijk is waar het gebeurt!

Mij lijkt niet de discussie over het optimale interessant, maar de discussie over wat minimaal nodig is voor een verantwoorde applicatie. Stored Procedures bijvoorbeeld, dat is voor mij een must. Ook al kosten die dingen tijd ik wil geen SQL in mijn codebehinds zien. Die zijn overigens ook een must: codebehinds. Maar een BLL/DAL, de initiele overhead is voor mij gewoon te groot in veel gevallen.

Beweer jij werkelijk dat elke applicatie die jij bouwt N-tier opgezet moet zijn? Jij zou jezelf geen serieuze programmeur vinden als je een 1-tier systeem moest bouwen? (ik ga er van uit dat je ASP.NET/CodeBehind/T-SQL SP/DB 1-tier vindt, ikzelf vindt dat iets te simplistisch maar goed).

[tijn]

Verwijderd schreef op 15 februari 2003 @ 13:48:
[...]

Mij lijkt niet de discussie over het optimale interessant, maar de discussie over wat minimaal nodig is voor een verantwoorde applicatie.

Leuk

Stored Procedures bijvoorbeeld, dat is voor mij een must.

In veel situaties verstandig, maar geen must.

Ook al kosten die dingen tijd ik wil geen SQL in mijn codebehinds zien.

Da's logisch want je stopt sowieso geen Data Access code in je code behind

Die zijn overigens ook een must: codebehinds.

Die krijg je gratis bij VS.NET. Als die ze niet zou genereren zou niemand ze gebruiken. Overigens moet je er voor waken om hier te veel dingen in te gaan doen. Als je forms wat complex worden verzandt het al snel in een onoverzichtelijke brij code.

Maar een BLL/DAL, de initiele overhead is voor mij gewoon te groot in veel gevallen.

Valt best mee. De methods die je vaak in de codebehind toevoegt kun je meestal ook wel kwijt in de BLL (of wat mij betreft de DAL als je de BLL skipt).

[whoami]

Verwijderd schreef op 15 February 2003 @ 13:48:
[...]


Je polariseert de zaak whoami, maikel heeft helemaal nergens gezegd dat 1-tier ontwikkeling beter is. Maikel stelt, net zoals ik, dat het geen doodzonde is om niet N-tier te ontwikkelen als de situatie daarom vraagt. Ik geloof dat zelfs EfBe het met die stelling eens is.

Daarin heb je gelijk. Als het niet nodig is, dan hoef je geen extra layer te creeëren. Echter, het gaat hier over Enterprise Applicaties. Dit wil dus zeggen dat die applicaties zeker de business-rules van dat bedrijf zal moeten omvatten. Dus, waarom zou je die business rules niet in een aparte laag onderbrengen? Je hebt ze dan op 1 centrale plaats, en als er later een andere interface moet gebouwd worden, kan je ze direct hergebruiken.
Als je een niet al te complexe set van business rules hebt, dan kan je eventueel overwegen om de DAL in de BL te verweven. Echter, naarmate de complexiteit groeit, zal het moeilijker zijn om aanpassingen uit te voeren aan je BL. Dan zal je op termijn toch nog je DAL in een andere laag moeten onderbrengen. Wat dan een hele hoop werk met zich meebrengt dat je, achteraf gezien, had kunnen uitsparen.
Mijn mening is dus, als het om EA's gaat, dan gebruik je best minimaal een 3 lagen structuur.

Over hoe het optimaal moet kunnen wij het denk ik snel eens zijn: geef mij genoeg tijd en genoeg geld en ik bouw voor jou de mooiste BLL/DAL die je ooit gezien hebt. Maar de praktijk werkt anders en de praktijk is waar het gebeurt!

Idd, de praktijk is waar het gebeurd. En in de praktijk zijn de meeste bedrijven toch echt wel bezig met n-tier development.

Mij lijkt niet de discussie over het optimale interessant, maar de discussie over wat minimaal nodig is voor een verantwoorde applicatie. Stored Procedures bijvoorbeeld, dat is voor mij een must. Ook al kosten die dingen tijd ik wil geen SQL in mijn codebehinds zien. Die zijn overigens ook een must: codebehinds. Maar een BLL/DAL, de initiele overhead is voor mij gewoon te groot in veel gevallen.

Tja, wat dacht je dan aan de overhead als het later blijkt dat je toch beter een scheiding in die 2 lagen had ondergebracht?

Beweer jij werkelijk dat elke applicatie die jij bouwt N-tier opgezet moet zijn? Jij zou jezelf geen serieuze programmeur vinden als je een 1-tier systeem moest bouwen? (ik ga er van uit dat je ASP.NET/CodeBehind/T-SQL SP/DB 1-tier vindt, ikzelf vindt dat iets te simplistisch maar goed).

neen, dat beweer ik niet. Ik beweer echter dat, for the sake of beheersbaarheid, je in enterprise applicaties (waar het toch gaat om meestal ingewikkelde business logica en een uitgebreide databank), je het best voor een scheiding zorgt tussen die 2 lagen. Voor een beheersbaarder, onderhoudbaarder, schaalbaarder, duidelijker systeem.

Tuurlijk heeft n-tier development nadelen, maar die wegen imho niet op tegen de voordelen. Ik zeg niet dat jij moet n-tier ontwikkelen, maar, ik ben er 100% zeker van dat, als jij een enterprise applicatie moet ontwikkelen (maar dat ga je nooit alleen moeten doen. , Daar zitten architecten, programmeurs, analysten, .... ook in het team), dat je die n-tier zult moeten opzetten. En als je dat niet moet doen, dan zal je imho zeker wel op de nadelen en beperkingen botsen van 1-tier development, en zal je inzien dat n-tier development niet zoveel verloren geld en tijd zal zijn zoals je gedacht had.

[whoami]

[nohtml]

tijn schreef op 15 February 2003 @ 14:18:
[...]

In veel situaties verstandig, maar geen must.

SP's zijn in veel situaties, zoniet alle, verstandig.
Als je een applicatie bouwt mbhv SQL Server, dan is de enige manier om je applicatie en gegevens echt veilig te krijgen: werken met stored procedures.
Wil je veiligheid en performance, dan moet je voor SP's gaan.

Die krijg je gratis bij VS.NET. Als die ze niet zou genereren zou niemand ze gebruiken.

Hmmm.... Dat denk ik niet. Moest VS.NET ze niet genereren, dan nog zou het de moeite waard zijn om het beetje extra werk te verrichten om code-behind te gebruiken.

[whoami]

EfBe schreef op 15 February 2003 @ 09:20:
[...]

Wellicht zijn je gebeden verhoord MS heeft een nieuw sample gereleased: http://www.windowsforms.n....aspx?tabIndex=7&tabId=44

Thx, ga ik zeker ff bekijken.

Hmmm.... Net ff gedownloaded, blijkt dat het een VB.NET app is.
* whoami heeft hier enkel C# installed staan.

[ Voor 17% gewijzigd door whoami op 15-02-2003 16:14 ]

[EfBe]

paulgielens schreef op 15 February 2003 @ 13:34:
ps: ik mis trouwens Martin en Otis in deze discussie
.

Ik deed wel degelijk mee, Paul

[EfBe]

maikel schreef op 15 February 2003 @ 10:46:
Ik begrijp heel goed wat jij zegt hoor. Maar ik begrijp ook heel goed wat paullooijmans te vertellen heeft. En daar ben ik het toch echt veel meer mee eens dan met jou standpunt. Ik begrijp goed wat je wilt zeggen, maar ik weet dat dat niet voor elke situatie geldt. Maar blijkbaar wil jij blijven vasthouden aan de theorieen die je ooit tijdens een opleiding hebt geleerd of ergens gelezen. Uit de praktijk blijkt echter dat de theorieen niet altijd toepasbaar zijn.

Wat denk je, dat ik op een universiteit werk oid? N-tier heb ik helemaal niet geleerd op mn opleiding, want toen bestond internet nog niet eens in de vorm van www, websites en de applicaties die daarbij horen, laat staan een visie op hoe je distributed computing kon gaan doen.

Uit de praktijk blijkt ook dat een heel groot deel van softwareprojecten uitlopen of teveel gaan kosten. En dat is volgens mij meer realiteit dan jouw 'realiteit'.
Misschien moet je eens een tijdje gaan rondkijken op http://www.dsdm.com/

Te hoge kosten voor een project ligt niet aan een zwakte van een gebruikte techniek, maar aan het slechte management van een project. Dit is logisch af te leiden uit het feit dat bij een goed ontwerp je nadat je het ontwerp hebt afgerond, je een redelijke inschatting kunt geven hoeveel het gaat kosten. Moet je wel vasthouden aan het ontwerp. Ad-hoc iets bouwen aan de hand van invloeden van de dag impliceert dat je vooraf geen idee hebt wat je moet gaan doen (qua totaalplaatje) wat resulteert in een natte-vinger begroting. Een van m'n argumenten tegen bv XP.

PS.
Ik heb ook nog bij een bedrijf gewerkt die elke website n-tier opzette.
Die zijn nu failliet.

Mijn 1e werkgever deed iets met Unix en databases en 4GL. Ook failliet. Lekker belangrijk.

[ Voor 3% gewijzigd door EfBe op 15-02-2003 17:07 ]

[EfBe]

Verwijderd schreef op 15 February 2003 @ 12:48:
Het boek van Professor EfBe. WHAAHAHHAHAHAAHAHAHAHAHA...
Just kidding.

Yeah, just kidding. Kom eens met argumenten die hout snijden ipv met loze opmerkingen met de strekking van "n-tier is veelal echt teveel overhead". Ik heb jou nog geen 1 argument zien maken waarom die overhead een dermate groot nadeel is dat het een project schaadt. (ooit aan gedacht dat je bij n-tier development weet in welke tier welke functionaliteit zit en je dus in andere tiers weet waar je welke functionaliteit moet zoeken? bij jouw 1-tier model heb je dat niet, kost veel tijd. )

Tot die tijd hou je je mond maar over professor EfBe.

[mbravenboer]

paulgielens: ik mis trouwens Martin en Otis in deze discussie

Sorry dat ik niet aktief bijdraag . Ik lees af en toe even door wat jullie allemaal besproken hebben en denk er over na door het te linken met het werk waar ik wel mee bezig ben. Ik ben hier dus niet concreet mee bezig en daarom heb ik ook niet het gevoel dat ik wat nuttigs kan bijdragen in de discussie ...

[Alarmnummer]

Als experiment ben ik nu aan het bedenken hoe ik zelf het beste een generator kan opzetten. Ik wil het niet al te gecompliceerd maken, maar meer beschouwen als goeie oefening om domain en data layers op te stellen. En verder houdt het me ook van de straat

[mbravenboer]

Alarmnummer: Als experiment ben ik nu aan het bedenken hoe ik zelf het beste een generator kan opzetten

Het belangrijkste voor de functionaliteit van de generator is natuurlijk de specificatie en het ontwerp wat je gebruikt in de gegenereerde code, maar de techniek voor code generatie is ook wel boeiend om over na te denken.

Code generatoren gebruiken op dit moment over het algemeen een van de volgende opties
1) Templates
2) Stringetjes plakken
3) AST opbouwen.

Optie (1) is het meest populair omdat het de gegenereerde code een beetje scheidt van de generator. Meestal is wordt het genereren van code er niet echt duidelijker op als je het doet via optie (2): de code opnemen in string literals en dit bij elkaar optellen.

Sommige systemen gebruiken het opbouwen van ASTs, maar uiteraard is dat een zeer verbose manier van werken. Dit werkt dus voor geen meter en wordt daarom vaak gecombineerd met optie (2) voor expressies en soms zelfs statements.

Alle systemen behalve de AST opbouwing hebben een fundamenteel probleem: het is alles behalve duidelijk of je correcte code genereert. Tekst gebaseerde generatie is op dit punt een zwakke manier van werken, net zoals tekst gebaseerde generatie van bijvoorbeeld XML.

Een goede oplossing is meta programming with concrete object syntax. Hierbij wordt de syntax van de taal van de code die je genereert (de object taal) gecombineerd met de taal waarin je genereert (C#, java, xslt, stratego). Hierdoor kan je in concrete syntax ASTs opbouwen, waardoor je dus het nadeel van ASTs opbouwen wegneemt.

Ik heb het hier al veel over gehad op Javahova, dus het zal vast niet nieuw in de oren klinken .

Publicatie van toepassing in Stratego:
http://www.stratego-langu...gWithConcreteObjectSyntax

Paar code fragmenten van C++ code generatie:
http://members.rott.chell...ntationClassification.pdf

Code fragmenten van XHTML generatie (zie mijn posts, sorry voor het vage topic ) :
http://forum.javahova.net/topic.php?id=921&pag=1

Code fragementen van Stratego en Haskell transformaties en Java code generatie (bijna laatste slide):
http://www.cs.uu.nl:80/gr...ransformation/IST-PT4.pdf

[Alarmnummer]

Ik ga met SableCC een parser maken en daarmee mijn eigen AST vullen. En verder kan ik mbv een backend implementatie wel output genereren. Maar ik ben op dit moment eerst bezig om uit te zoeken wat ik wil genereren en me nog niet bezig aan het houden hoe ik het wil genereren.

[Verwijderd]

EfBe schreef op 15 februari 2003 @ 17:13:
[...]
Yeah, just kidding. Kom eens met argumenten die hout snijden ipv met loze opmerkingen met de strekking van "n-tier is veelal echt teveel overhead". Ik heb jou nog geen 1 argument zien maken waarom die overhead een dermate groot nadeel is dat het een project schaadt.

Nee, inderdaad, je hebt me geen andere argumenten zien gebruiken. Omdat er wat mij betreft ook geen andere argumenten zijn. Maar doorlooptijd en kosten zijn wel twee hele belangrijke factoren tegenwoordig. Sterker nog, het zijn juist die twee factoren die IT zo'n slechte naam geven bij bedrijven: meer dan 3/4 van alle IT projecten hebben te maken met budget- en/of tijdoverschrijdingen!

Daar komt nog bij dat bedrijven er in de huidige economische omstandigheden alles aan doen om kosten te besparen, dat betekent dus voor weinig geld en snel (want de software zou geld moeten besparen) opleveren.

Het gaat niet om de kwantiteit van de argumenten, want ik ben het met je eens dat N-tier ontwikkelen leidt tot de inmiddels bekende voordelen, maar de kwaliteit van mijn argument dat het meer tijd/geld kost is mi belangrijk en door jou onderschat.

ooit aan gedacht dat je bij n-tier development weet in welke tier welke functionaliteit zit en je dus in andere tiers weet waar je welke functionaliteit moet zoeken? bij jouw 1-tier model heb je dat niet, kost veel tijd.

Ooit aan gedacht? Dit valt onder het door mij al onderschreven voordeel van betere onderhoudbaarheid. No argument there.

Tot die tijd hou je je mond maar over professor EfBe.

Sorry professor. Ok professor

[EfBe]

Alarmnummer schreef op 15 February 2003 @ 17:48:
Als experiment ben ik nu aan het bedenken hoe ik zelf het beste een generator kan opzetten. Ik wil het niet al te gecompliceerd maken, maar meer beschouwen als goeie oefening om domain en data layers op te stellen. En verder houdt het me ook van de straat

Ik heb ooit 4 ontwerptekeningen van LLBLGen 2.0 gepost:
http://gathering.tweakers.net/forum/view_message/15944722

[EfBe]

Verwijderd schreef op 15 februari 2003 @ 18:40:
Nee, inderdaad, je hebt me geen andere argumenten zien gebruiken. Omdat er wat mij betreft ook geen andere argumenten zijn. Maar doorlooptijd en kosten zijn wel twee hele belangrijke factoren tegenwoordig. Sterker nog, het zijn juist die twee factoren die IT zo'n slechte naam geven bij bedrijven: meer dan 3/4 van alle IT projecten hebben te maken met budget- en/of tijdoverschrijdingen!

Blabla, wollige taal zonder keiharde cijfers zegt zo weinig. Overschreden deadlines en specs die niet met de functionele eisen matchen maar wel de kosten omhoogjagen zijn gevolgen van iets, niet de problemen an sig. Ik heb echter nog geen cijfers van je gezien waaruit blijkt dat bv het gebruik van n-tier development een ontwikkeltraject langer maakt en duurder.

Daar komt nog bij dat bedrijven er in de huidige economische omstandigheden alles aan doen om kosten te besparen, dat betekent dus voor weinig geld en snel (want de software zou geld moeten besparen) opleveren.

Je hebt zelf een bedrijf (codeworks) toch? Dan weet je ook dat IT als snelle fix ingezet niets helpt en alleen maar geld kost. Een bedrijf dat TOCH zo'n opdracht aanneemt is slecht bezig, die zou moeten adviseren het geld in de zak te houden.

Het gaat niet om de kwantiteit van de argumenten, want ik ben het met je eens dat N-tier ontwikkelen leidt tot de inmiddels bekende voordelen, maar de kwaliteit van mijn argument dat het meer tijd/geld kost is mi belangrijk en door jou onderschat.

Ik heb alleen gezien van je DAT het kennelijk meer tijd (en daar verbindt jij meteen hogere kosten aan) kost maar meer dan die loze kreet komt er niet uit. Ik beweer het tegendeel. Wie heeft nu gelijk? Ik weet uit ervaring dat n-tier development de tijdsduur van een project korter maakt. Dat zegt niet zoveel in algemene zin, echter jouw loze opmerking zegt nog minder. Als je me wilt overtuigen zul je toch met cijfers moeten komen, tot die tijd is het hot-air.

Sorry professor. Ok professor

Mja...

[whoami]

De voordelen van n-tier development blijken hieruit:
Success Stories N-tier development

Goals of a Good N-Tier Application
N-tier design came about as a result of the failings of the client/server model. There are many goals that an n-tier application design should achieve. Here are some of them.

If you change the underlying data access methods, the client-side code should not have to change.
All data access routines should be exposed as objects instead of function calls. As an example, it is much easier to use ADO than the ODBC API calls.
SQL should be eliminated from the client-side code. The client code should just be concerned with methods and properties.
Table and column names should be eliminated from the client-side code. Typed datasets can present table and column names as properties, providing an IntelliSense list, as opposed to having to type in a string name. This means at compile time, checks can be made for data types and names of columns.
The client code should not care where the data comes from. It should just care that it can retrieve and modify the data in some object and the object will take care of the details.
The coding you need to do on the client side should be simplified. Instead of using many functions, your application should be able to use objects with properties and methods.
It becomes easier to create and use the classes than the function calls.
It becomes easier to add functionality to your applications, and change the functionality, without breaking the client-side code.

_MSDN

N-tier applications have become the norm for building enterprise software today. To most people, an N-tier application is anything that is divided into discrete logical parts. The most common choice is a three-part breakdown—presentation, business logic, and data—although other possibilities exist. N-tier applications first emerged as a way of solving some of the problems associated with traditional client/server applications, but with the arrival of the Web, this architecture has come to dominate new development.

n-tier development

[Verwijderd]

EfBe schreef op 15 February 2003 @ 18:50:
Ik heb echter nog geen cijfers van je gezien waaruit blijkt dat bv het gebruik van n-tier development een ontwikkeltraject langer maakt en duurder.

Net zo min als jij mij cijfers hebt laten zien die jouw beweringen van flexibiliteit en onderhoudbaarheid ondersteunen.

Ik heb alleen gezien van je DAT het kennelijk meer tijd (en daar verbindt jij meteen hogere kosten aan) kost maar meer dan die loze kreet komt er niet uit. Ik beweer het tegendeel.

Nee hoor, dat doe je niet. Je hebt in een eerdere post N-tier afgezet tegen:

een snelle hack voor weinig

Wel consistent blijven aub. Verder heb ik wel degelijk cijfers genoemd:

Sun Petshop: 14000 regels.
MSFT Petshop: 4000 regels.

Da's 350% meer code EfBe! Daar komt nog bij dat de analysefase voor een N-tier project langer duurt omdat je beter moet nadenken over hoe die tussenlagen er precies uitzien alvorens ze te gaan bouwen. Tel daarbij op de door al eerder genoemde analisten die er hun licht over moeten laten schijnen, terwijl de 1-tier oplossing in principe met wat begeleiding door een minder 'zware' programmeur te doen is.

Maar mijn beste EfBe, ik voel een lichte irritatie in jouw argumenten, dat is nergens voor nodig, it's all in good fun. Ik denk dat we het meer met elkaar eens zijn dan jij denkt.

[Verwijderd]

whoami schreef op 15 February 2003 @ 19:45:
De voordelen van n-tier development blijken hieruit:

[...]

Voordelen die ik ook nooit bestreden heb. Maar jullie geloven toch ook niet meer in sprookjes of wel? Elke oplossing heeft voor- en nadelen, ook N-tier development. Dat de voordelen van N-tier development voornamelijk technisch zijn en de nadelen voornamelijk bedrijfsmatig (tijd/geld) wil niet zeggen dat het niet jullie taak is de nadelen te kennen.

De voordelen van N-tier ontwikkelen zijn bij jullie bekend, wat ik heb geprobeerd is jullie duidelijk te maken wat de nadelen zijn en hoe deze vandaag de dag de beslissingen omtrent het wel of niet gebruiken van N-tier development beinvloeden.

[Alarmnummer]

Ik ben nu wat met Velocity aan het experimenteren om code te genereren, en het werkt echt super.

[mbravenboer]

Alarmnummer: Velocity om code te genereren, en het werkt echt super.

Tja, ik neem aan dat ik hier geen commentaar op hoef te leveren?

Op zich zal het als template engine wellicht heel aardig functioneren, maar ook hier is er geen enkele controle of garantie dat er wat zinnigs uitkomt. Omdat je niet alle mogelijke inputs kan testen, kan je dus ook nooit beweren dat je generator altijd geldige Java code (syntaxtisch gezien) zal produceren. Het lijkt mij waardevol als je generator wel gecontroleerd kan worden op deze eigenschappen door dus een krachtiger mechanisme te gebruiken.

[EfBe]

mbravenboer schreef op 15 February 2003 @ 21:34:
Op zich zal het als template engine wellicht heel aardig functioneren, maar ook hier is er geen enkele controle of garantie dat er wat zinnigs uitkomt. Omdat je niet alle mogelijke inputs kan testen, kan je dus ook nooit beweren dat je generator altijd geldige Java code (syntaxtisch gezien) zal produceren. Het lijkt mij waardevol als je generator wel gecontroleerd kan worden op deze eigenschappen door dus een krachtiger mechanisme te gebruiken.

Dat met die templates en de correcte output ben ik het eens. Echter ik zie niet 1 2 3 hoe je middels andere middelen kunt garanderen dat wat je genereert correct is. Het is alleen mogelijk indien je a) een manier vindt waarop de gebruiker middels simpele elementen een definitie kan samenstellen van de te genereren functionaliteit, waarbij je de definitie kunt testen op correctheid en b) dat je een 1:1 afbeelding kunt maken van die definitie op een gelaagd stelsel van template*, waarbij je kunt aantonen dat de wijze van afbeelden correct gebruik van de templates inhoudt, en omdat de templates zodanig zijn opgezet dat ze uit kleine elementen bestaan die 1:1 representaties zijn van de simpele elementen waarmee de gebruiker de definitie in elkaar zet, je daaruit kunt concluderen dat de generatie goede code oplevert.

* met gelaagd stelsel van templates bedoel ik niet de domme templates die nu veelal gebruikt worden in generatoren maar een hierarchie van templates van grof naar detail, waarbij je middels definitieparameters op elke laag kiest voor een versie van de beschikbare templates.

bijvoorbeeld, select stored procedure:
SELECT
[fieldlist]
FROM
[fromlist]
[orderlist]
[aggregatelist]

[fieldlist] wordt nu geevolueerd dmv nieuwe templates die fieldlists beschrijven. Ik ben dit nu aan het uitwerken voor mijn generator, want ik zit met hetzelfde probleem wat jij heel goed aanstipte: wat te doen bij code die niet goed werkt of niet compileert? Bijvoorbeeld deze select stored proc zal niet worden 'geparsed'
SELECT A, B, C FROM Foo GROUP BY A. Omdat B en C niet in een aggregate zitten, mogen ze niet in de fieldlist staan. Dit is althans zo in SqlServer. Maar hoe ga je dat nu inperken? Want wellicht wil iemand wel COUNT(B ) ipv B. Is het dan wel correct? Zeer complexe materie, die je imho alleen oplost wanneer je sets van templates definieert, waar de generator uit kan kiezen bij het genereren. Is een template dus niet beschikbaar, is de generator niet in staat iets te genereren.

[mbravenboer]

EfBe: Dat met die templates en de correcte output ben ik het eens. Echter ik zie niet 1 2 3 hoe je middels andere middelen kunt garanderen dat wat je genereert correct is.

Dat is ook absoluut niet eenvoudig. Ik legde ook niet voor niets de nadruk op syntaxtische correctheid . Syntaxtische correctheid van de output is goed te garanderen door een grammatica voor de object-taal te nemen (bijvoorbeeld XML, SQL, C#, Java) en deze te combineren met de grammatica voor de meta-taal (bijvoorbeeld C#, Java, XSLT, Stratego).

Je gebruikt dan concrete syntax voor de object taal in de meta taal. Bij het parsen worden de fragementen van de te genereren code ook geparsed en dus compileert de generator alleen als die fragementen syntaxtisch gezien correct zijn.

Dat garandeert nog niet dat de output van de generator ook in alle gevallen zal compileren, maar het is in ieder geval wel een flinke eerste stap.

Voor een volledige garantie moet je bijvoorbeeld ook de code fragementen in de generator gaan typechecken. Dit zorgt ervoor dat je de typechecker van de meta taal uit moet gaan breiden met een typechecker voor de object taal. Dat is absoluut geen triviale bezigheid omdat je typecheckers over het algemeen niet specificeert maar implementeert. Deze implementaties zijn meestal niet eenvoudig samen te stellen.

Syntax specificeer je over al het algemeen wel (in grammaticas dus) en die kan je daarom ook samenstellen als je syntax definitie formalisme althans samenstelling van grammatica's mogelijk maakt (SDF doet dat dus, de meeste andere systemen niet).

Een ander interessant voorbeeld wat waarschijnlijk aan zal spreken is een semantische controle van een XSL Transformatie die nagaat of de output gegarandeerd valid is ten opzichte van een bepaald schema. Dit heeft vrij veel te maken met het typechecking probleem van de code in een code generator.

bijvoorbeeld, select stored procedure
Bijvoorbeeld deze select stored proc zal niet worden 'geparsed'
SELECT A, B, C FROM Foo GROUP BY A. Omdat B en C niet in een aggregate zitten, mogen ze niet in de fieldlist staan.

Interessant voorbeeld . Het is geinig om zulke problemen te horen van iemand die ook daadwerkelijk aan een code generator werkt. Je begrijpt duidelijk exact waar het om gaat.

Dit is ook weer zo'n semantische analyse die te vergelijken is met typechecking. Syntaxtisch gezien is de SQL statement wel correct (hij zal dus wel parsen), maar semantisch gezien is hij niet juist. Zoals je zelf al aangeeft is het dus niet triviaal (op dit moment waarschijnlijk zelfs onmogelijk) om behalve de syntaxtische controle ook semantische controle uit te voeren op de code fragementen in de generator ...

[ Voor 11% gewijzigd door mbravenboer op 15-02-2003 22:36 ]

[Alarmnummer]

mbravenboer schreef op 15 February 2003 @ 21:34:
[...]

Tja, ik neem aan dat ik hier geen commentaar op hoef te leveren?

Op zich zal het als template engine wellicht heel aardig functioneren, maar ook hier is er geen enkele controle of garantie dat er wat zinnigs uitkomt. Omdat je niet alle mogelijke inputs kan testen, kan je dus ook nooit beweren dat je generator altijd geldige Java code (syntaxtisch gezien) zal produceren. Het lijkt mij waardevol als je generator wel gecontroleerd kan worden op deze eigenschappen door dus een krachtiger mechanisme te gebruiken.

Als ik syntactische correctheid wilt garanderen, dan kan ik dit ook uitstekend voor elkaar krijgen door te compileren. En verder is het niet bedoelt als serieuze oplossing, hiervoor kan ik veelbeter een van de vele or tools pakken. Maar door zelf templates ed te schrijven, moet je veel beter nadenken over mappings ed en alle structuren die erbij horen.

[Verwijderd]

Alarmnummer schreef op 16 February 2003 @ 11:24:
[...]

Als ik syntactische correctheid wilt garanderen, dan kan ik dit ook uitstekend voor elkaar krijgen door te compileren.

Probleem is dan dat je de errormsg in de gegenereerde code krijgt en niet in je template. Dit maakt het debuggen van wat complexere outputs lastig.

[Alarmnummer]

Dat ben ik met je eens. Maar tis beter dan alles met de hand te schrijven En verder is het alleen een experimentje.

[ Voor 22% gewijzigd door Alarmnummer op 16-02-2003 11:49 ]

[mbravenboer]

Alarmnummer: Als ik syntactische correctheid wilt garanderen, dan kan ik dit ook uitstekend voor elkaar krijgen door te compileren.

Dat is natuurlijk onzin (dat weet jij ook wel ). Compileren van een output is testen. Je test dus of een gegeven input een syntaxtisch correcte output oplevert. Testen is uiteraard niet volledig mogelijk en dus garandeer je op deze manier helemaal niets.

[Alarmnummer]

Je hebt gelijkt (purist ), maar zoals ik al zei, het is alleen een oefening. En verder ben ik wat aan het experimenteren met decorators ed.

[ Voor 29% gewijzigd door Alarmnummer op 16-02-2003 12:04 ]