[alg] enterprise applicatie - totaal oplossing.

Pagina: 1 2 Laatste
Acties:
  • 460 views sinds 30-01-2008
  • Reageer

Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Ik ben de laatste tijd veel bezig met het design van enterprise applicaties en er worden allerlei mooie ontwerp technieken in gebruikt. Je maakt een scheiding tussen je data laag en je domein laag, en je maakt een scheiding tussen je domein laag en je gui.

Je krijgt er ook allerlei fraaie design patterns bij die het leven veel aangenamer maken. Maar uiteindelijk vind ik het een beetje vreemd dat er niet wat meer totaal oplossingen zijn voor dit probleem. Stel dat je bv via MVC je datalaag met je gui laag laat communiceren, dan ben ik afgezien van mijn en mbravenboer zijn opgevoerde basis domein objecten/ gui objecten nog geen kant en klare oplossing hiervoor tegen gekomen: een ontwerper loopt dus iedere keer weer met de hand allerlei event code aan te sluiten.

Hetzelfde geldt voor de datalaag. Uit het boek van martin fowler: "patterns of enterprise applicaties architecure' doe je echt een schat van ideeen op. Een van de dingen waar je tegen aanloopt, is welke domein objecten je wilt gaan saven (als je wilt saven). Je kan natuurlijk alle objecten die in je geheugen staan naar de database sturen, dit kan natuurlijk allerlei vervelende problemen met zich mee brengen. Een zeer eenvoudige maar doeltreffende oplossing die hij geeft is om een vlag aan ieder domein object toe te voegen waarin staat of hij dirty is of niet.

Dit zijn allemaal dingen die al 10.000 keer door ontwerpers/programmeurs moeten zijn bedacht en uitgevoerd. Waarom zijn er niet kant en klare objecten die hiervoor gebruikt worden? (opm1) Ik snap dat niet iedere applicatie hetzelfde is en je daarom niet altijd iets aan zo`n library hebt. Maar veel van de dingen die bij mij opkomen die hebben toch wel een gelijke 'structuur' en daar hoef je alleen nog maar je domein logica in elkaar te zetten en verder is het eigelijk dom toepassen van allerie standaard structuren: Registry, LazyLoader, Mapper etc etc.

Wat ik dus wil weten of ik nu zo gek ben en er schijnbaar toch niet zo veel van snap waarom zo`n standaard library waar je in ieder geval 90% van de tijd mee uit de voeten kan handig (en dus enorm tijdsbeparend) kan zijn.

opm1:
Ik ben thuis in EJB, maar EJB is niet overal voor toepasbaar. Ik ben uit op een discussie over hoe mensen hun enterprise applicaties opzetten, en hoe ze het kunnen volhouden om iedere keer hetzelfde te implementeren (en zichzelf daar eigelijk mee in de vingers snijden: je loopt werk voor niets te doen).

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Ten eerste heb je de 2 complementaire delen: stateful en stateless. Een stateful applicatie is niet te vergelijken met een stateless applicatie. Er zijn slimmeriken die mengvormen hebben bedacht, dus per tier bepalen of deze stateful danwel stateless is. (waarbij je dus facade tiers nodig hebt voor vertalingen van stateful objects naar stateless 'hulls' met functionaliteit die je meteen weggooit zodra de actie klaar is). Ten tweede is n-tier ontwikkeling een manier om op abstracte wijze functionaliteit te groeperen, en heeft weinig met implementatie te maken. Dit wordt verduidelijkt hieronder.

Je probleem komt voort uit het feit dat het concept van n-tier development eigenlijk vrij abstract is. Het vertelt nl. over een idee hoe je een applicatie op zou kunnen zetten en dan ook nog in dermate algemene termen dat je er niet een 1:1 afbeelding van kunt maken op code zodat je daarmee altijd hetzelfde raamwerk krijgt, ongeacht het gebruikte platform. Een voorbeeld hiervan is bv hoeveel tiers ga je gebruiken? 2, 3, 5 wellicht? Heb je meerdere vormen van dezelfde tier in je applicatie? (gui's voor web, windows en linux plus een thin client die een webservice interface aanspreekt?).

n-tier development is bedoeld om functionaliteit in abstracte vorm te gieten waardoor een raamwerk ontstaat (in meerdere vormen mogelijk) dat dan ingevuld wordt door het implementeren van die functionaliteit in het gewenste doelplatform, op zo'n manier dat het vooraf gevraagde abstractie-niveau niet wordt aangetast. Dus, je bouwt bv een webapplicatie met een gui, een aantal business rules en een database, dan kun je gaan voor 3 tiers, 1 voor de gui, 1 voor de business rules en 1 voor de database control. Je deelt de applicatie op in die 3 tiers waarbij je dan ook automatisch die tiers voor de andere tiers abstract maakt, dwz, ze communiceren wel met elkaar maar weten niet hoe de ander te werk gaat. Een 5-tier benadering (veel gebruikt in vrij omvangrijke, complexe applicaties) vraagt al om een andere verdeling van de functionaliteit, maar vraagt wel om hetzelfde niveau van abstractie!

Je zult begrijpen dat dat dus niet in 1 of 2 concrete raamwerken is te gieten, zodanig dat je met die raamwerken in de hand kunt zeggen: zo ziet je applicatie eruit, globaal, programmeer de details er maar in, dan ben je klaar. N-tier development staat op een veel hoger abstractieniveau.

Er zijn uiteraard voor 'gelijkende' applicaties vaststaande stramienen denkbaar. Zo zal een website met een gui-tier, een business-logic tier en een database-tier veelal hetzelfde werken als een andere website met dezelfde tier-setup. Dat is ook de reden waarom er tegenwoordig steeds meer generatoren op de markt komen om in ieder geval de tiers die veelal hetzelfde zijn te genereren. Echter, om een complete applicatie-generator te maken is erg complex, zeker omdat je op een dermate abstract niveau bezig bent dat de hoeveelheid details erg groot is die verschilt per applicatie, en dat is nu net de reden waarom je soms voor een stateful en soms voor een stateless benadering kiest, soms voor 3, soms voor 5 tiers etc.

Als je kijkt hoe je een applicatie zou moeten bouwen, volgt daar al uit dat een implementatiestructuur niet belangrijk is. Immers: door te kijken naar de functionaliteit die gerealiseerd moet worden, moet je je applicatie vorm geven, niet andersom. Wanneer je daarmee klaar bent kun je de keuze maken hoe je de functionaliteit gaat invullen, realiseren zeg maar. Dat kan dus op 1001 manieren. Zoals gezegd zullen sommige manieren veel overlap met elkaar hebben, en een n-tier benadering zorgt voor een vergroting van die overlap, zeker tussen tiers op gelijke levels, waardoor je functionaliteit aangeboden door een tier kunt delen in andere applicaties. Echter, de bron is je functionaliteit, niet de manier waarop je het realiseert. Veel mensen staren zich daar blind op en verzanden in oeverloos gezever over implementatiedetails die er niet toe doen.

[ Voor 6% gewijzigd door EfBe op 11-02-2003 10:05 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
Kort samengevat: Je kan geen generiek raamwerk hebben omdat enterprise applications totaal verschillend van elkaar zijn. Ieder bedrijf heeft z'n eigen business rules, ik heb nog nooit 2 identieke databases gezien, ....

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
whoami schreef op 11 februari 2003 @ 10:12:
Kort samengevat: Je kan geen generiek raamwerk hebben omdat enterprise applications totaal verschillend van elkaar zijn. Ieder bedrijf heeft z'n eigen business rules, ik heb nog nooit 2 identieke databases gezien, ....
Dan heb je niet helemaal begrepen wat ik bedoel :)

Ik vraag me dus af waarom er niet grotere bouwstenen om mee te werken. Ik heb voor mvc een paar 'types' geschreven, waar ingebouwde observable in zit en gui componenten die hier rechtstreeks mee kunnen communiceren doordat ze observer zijn.

Je krijgt dan zoiets:

Java:
1
2
3
4
5
6
7
8
9
class Persoon{
    IntM _leefijdM = new IntM(10);
}

class PersoonPanel{
     PersoonPanel(Persoon p){
          add(new IntMLabel(p));
     }
}


Om dirty objecten mee te checken, zou je ieder domein object bv een DirtyMarker interface kunnen laten implementeren en die aan die types mee te geven zodat je via een callback domein objecten automatisch genotified worden als er iets aan hun dirty is geworden.

Maar het is iedere keer toepassen van dezelfde technieken. En dat maakt het maken van een enterprise applicatie in dit opzicht onnodig duur (en saai),

[edit]
Ik zal Otis zijn reply even goed doorlezen.

[ Voor 14% gewijzigd door Alarmnummer op 11-02-2003 10:24 ]


Acties:
  • 0 Henk 'm!

  • LordLarry
  • Registratie: Juli 2001
  • Niet online

LordLarry

Aut disce aut discede

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. Borland heeft zelfs een belangrijke en grote speler (Bold) op dat gebied gekocht en bijgeleverd in de aller duurste versie van D7. Deze maakt het zelfs mogelijk direct vanuit RationalRose of ModalMaker via UML de boel te 'programmeren'.

Ook zijn er kant en klare BO's te krijgen toegespits op brance zodat je niet elke keer zelf class Person hoeft te maken. Ze zijn meestal alleen aardig prijzig en voor een zeer specialistisch public zodat je ze niet zoveel tegenkomt.

We adore chaos because we like to restore order - M.C. Escher


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Alarmnummer schreef op 11 February 2003 @ 10:21:
[...]
Dan heb je niet helemaal begrepen wat ik bedoel :)
Ik denk het wel, ik denk dat jij niet begrijpt dat je op een te laag niveau (qua detaillering/abstractie) zit te mieren ;) :)
Ik vraag me dus af waarom er niet grotere bouwstenen om mee te werken. Ik heb voor mvc een paar 'types' geschreven, waar ingebouwde observable in zit en gui componenten die hier rechtstreeks mee kunnen communiceren doordat ze observer zijn.
Die grotere bouwstenen zijn er wel, maar t.a.t zit je met het fenomeen: functionaliteit vertalen naar implementatie. Bij standaard bouwstenen moet je dus functionaliteit mappen op die standaard bouwstenen. Dit zie je bij sommige database frameworks die bv worden aangeboden: je mapt business rules op die frameworks en dan werkt het. Bizztalk server van Microsoft is ook zoiets maar dan op een hoger abstractieniveau: je 'designed' je business logica, je datastreams in je organisatie in een grafische omgeving en de tool genereert dan de implementatie mbv standaard bouwstenen (of bouwstenen die je aandraagt). Jij zit op een erg gedailleerd niveau te denken hoe je toch een methodiek die werkt op een hoog abstractieniveau moet gaan toepassen. Dat gaat niet werken: je moet 20 stappen terugnemen en EERST je functionaliteit in abstracte layers plaatsen, DAN die layers invullen, dwz de functionaliteit verder detailleren in die layers en die functionaliteit dan vertalen naar code. DAN kun je eventueel besluiten, heee, dit stukje code heb ik al eens gebouwd. Maar niet andersom, want dan ga je vanuit de code je functionaliteitsabstractie bepalen en als je iets niet moet doen is dat het wel. :)
Om dirty objecten mee te checken, zou je ieder domein object bv een DirtyMarker interface kunnen laten implementeren en die aan die types mee te geven zodat je via een callback domein objecten automatisch genotified worden als er iets aan hun dirty is geworden. Maar het is iedere keer toepassen van dezelfde technieken. En dat maakt het maken van een enterprise applicatie in dit opzicht onnodig duur (en saai),
Welnee. Als je bv stateless werkt heb je geen dirty objects, want je state zit niet in je app, maar in de database.

Wat jij denk ik wilt is dat je een generieke manier vindt om een veelvoud van n-tier applicaties te bouwen, zodanig dat je die generieke manier dan in classes kunt stoppen of in een generator zodat je alleen de applicatiespecifieke details hoeft in te vullen en je bent klaar.

Wie wil dat niet? :) Er zijn zeker patronen te ontdekken in implementaties van functionaliteit over verschillende tiers. Zoals bv de data-access tier, die veelal is gefocussed op tables, en je dus mbv die tables de data-access tier kunt genereren. Business logic tiers zijn veelal gefocussed op business rules, waarbij je abstracte definities gebruikt van entiteiten en daar operaties op definieert, waarbij je de bronnen van de entiteiten en de resultaten van de bewerkingen weer afbeeldt op de aangeboden functionaliteit van de data-access tier. Echter het komt altijd weer neer op de functionaliteit die gewenst is: welke functionaliteit moet de applicatie in zich hebben en in welke tiers stop ik welke functionaliteit? Vooral dat laatste zal verschuivingen teweeg brengen tussen implementaties van tiers: stop je logica in een stored procedure of in een business object? Of achter een button in de gui? In een aparte tier?

Een Data-access tier formuleren uit tabellen, relaties tussen velden en andere constraints, dat is nog wel te doen. Business logic designen en die dan mappen op data-access functionaliteit is al onbegonnen werk haast, vanwege de oneindige verscheidenheid aan mogelijkheden en functionaliteit. Er zijn een aantal generatoren op de markt die zeggen dat ze het kunnen, maar geen van allen kan het ook echt. Wat ze allemaal doen is het aanbieden van een eenheidsworst die telkens een ander kleurtje heeft, maar in feite een generieke engine in zich heeft waar je mappings mee moet maken. Dit is zelden een optimale weg. Wil je een generieke implementatie die je kunt kneden naar de wensen en eisen van de applicatie waar je mee bezig bent zodanig dat het lijkt alsof de generieke implementatie geschreven is voor die applicatie (m.a.w. de optimale implementatie), dan wens ik je veel succes, maar je zult erachter komen dat het nagenoeg onmogelijk is om die generieke implementatie te bouwen. Je komt hooguit tot een setje helperclasses. De reden ook waarom n-tier applicaties bouwen juist NIET saai is :)

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Ik zie dat je 2 keer het hebt over statefull en stateless objects. Ik neem aan dat als je het over stateless applicatie hebt, dat iedere wijziging automatisch wordt weggeschreven naar de db?

Voor sommige applicaties is dit geen probleem, maar je kan er niet altijd efficient mee uit de voeten. Soms gaat het te langzaam om iedere wijziging naar de db te schrijven doordat het gewoon te langzaam is om iedere kleine wijziging naar de database te schoppen.

Zou je statefull,stateless en bovengenoemde kunnen toelichten?
Ik denk het wel, ik denk dat jij niet begrijpt dat je op een te laag niveau (qua detaillering/abstractie) zit te mieren
Ik weet het. Ik ben op dit moment bezig om een enterprise applicatie aan het schrijven voor een fruitwinkel. Dit leek me wel een aardige oefening omdat de complexiteit valt te overzien, en er allerlei leuke zaken aan bod komen, lazyloaders, enheritance etc.

Ik heb een analyse gemaakt van het domein (was niet erg ingewikkeld :P) en ik moet een vertaling maken naar code en het is iedere keer toepassen van een aantal patterns. Eerst ieder object een identifier, dan een registry om objecten aan te maken en vinden, een mapper om de db commnucatie op te zetten, een lazyloader om er voor te zorgen dat niet meteen de hele database wordt leeggetrokken, dirty flags aan de objecten zodat ik niet te veel loop weg te schrijven etc etc etc.

Het is vanaf dat punt eigelijk een saaie klus aan het worden en schreeuwt op dit moment om:
a) code generatie
b) een klopper die dit voor mij doet
c) hulpobjecten waarin je in ieder geval een gedeelte van de functionaliteit kan plaatsen.

[ Voor 52% gewijzigd door Alarmnummer op 11-02-2003 20:40 ]


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Alarmnummer schreef op 11 February 2003 @ 20:34:
Ik zie dat je 2 keer het hebt over statefull en stateless objects. Ik neem aan dat als je het over stateless applicatie hebt, dat iedere wijziging automatisch wordt weggeschreven naar de db?
Voor sommige applicaties is dit geen probleem, maar je kan er niet altijd efficient mee uit de voeten. Soms gaat het te langzaam om iedere wijziging naar de db te schrijven doordat het gewoon te langzaam is om iedere kleine wijziging naar de database te schoppen.
Zou je statefull,stateless en bovengenoemde kunnen toelichten?
je hebt userstate en application state. Userstate houdt in dat je de situatie van de user in de applicatie bijhoudt en dat is dus stateful, wordt bewaard in bv session variables of soortgelijke structuren. Application state is de toestand van de applicatie en wordt bewaard normaliter in de database. De reden daarvoor is dat in een multi-user applicatie iedere user asynchroon met de applicatie werkt tov andere users. Dus de enige gegarandeerde toestand van de applicatie, los van al die users, is in de database. Dit geeft veel voordelen, o.a. dat je als programmeur voor single user kunt ontwikkelen. Dit geeft zeer simpele code, je hoeft nl. niet data in memory op te slaan en multi-threaded syncing te gaan toepassen op deze structuur.

Als je als user een actie uitvoert dat bv 3 stappen heeft, is het wellicht niet handig om iedere stap naar de database te schrijven. Je doet dat alleen als de uiteindelijke stap is voltrokken. Als je tegen useracties aankijkt als modificaties van de applicatiestate, dan is het logisch waar je welke acties gaat plegen op de database. Ik heb nooit het gevoel gehad dat het inefficient was, in tegendeel: nooit hoef ik me zorgen te maken dat andere users met 'dirty data' te maken krijgen, want dat bestaat gewoonweg niet.
[...]
Ik weet het. Ik ben op dit moment bezig om een enterprise applicatie aan het schrijven voor een fruitwinkel. Dit leek me wel een aardige oefening omdat de complexiteit valt te overzien, en er allerlei leuke zaken aan bod komen, lazyloaders, enheritance etc.
Ik heb een analyse gemaakt van het domein (was niet erg ingewikkeld :P) en ik moet een vertaling maken naar code en het is iedere keer toepassen van een aantal patterns. Eerst ieder object een identifier, dan een registry om objecten aan te maken en vinden, een mapper om de db commnucatie op te zetten, een lazyloader om er voor te zorgen dat niet meteen de hele database wordt leeggetrokken, dirty flags aan de objecten zodat ik niet te veel loop weg te schrijven etc etc etc.
Denk goed na wat je doet met stateful data: als je multi-user op een applicatie zit te werken, is het erg lastig acties van user A te propageren naar user B's client, indien je niet een stateless applicatie hebt. Dit wordt erg complex zelfs al met een klein setje objects. Stateless is daarom sterk aan te bevelen. Ben je ook meteen van je dirty flags af :)

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Anoniem: 4283

Interessante discussie :).

Maar, betekent het feit dat er niet veel standaard libraries voor enterprise apps zijn, niet dat het nagenoeg onmogelijk is? Als het namelijk wel mogelijk zou zijn, dan waren d'r al tig bedrijven in dit gat gesprongen, want er is natuurlijk érg veel geld mee te verdienen...

Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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).

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.
Interessante discussie .

Maar, betekent het feit dat er niet veel standaard libraries voor enterprise apps zijn, niet dat het nagenoeg onmogelijk is? Als het namelijk wel mogelijk zou zijn, dan waren d'r al tig bedrijven in dit gat gesprongen, want er is natuurlijk érg veel geld mee te verdienen...
Dat ben ik idd met je eens. Maar ik wil gewoon zien hoe anderen ontwerpers hier mee omgaan, omdat dit iets dat zij ook tegen zijn gekomen.

Trouwens EJB doet ook veel voor je. Je concentreert je vooral op de implementatie van de domein objecten/logica en de rest wordt voor je gegenereerd (database persistence, middelware, synchronisatie etc etc). Maar dit is ook niet overal geschikt voor. Je zou bv niet een tekenprogramma gaan maken waarvan de teken objecten (vierkant, pixel, lijn) als EJB in een applicatie server zitten. Dat is gewoon te langzaam :)

[ Voor 31% gewijzigd door Alarmnummer op 11-02-2003 21:38 ]


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
[nohtml]
Alarmnummer schreef op 11 februari 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).
Toch wel toch?

Een stateless applicatie houdt gewoon zelf die gegevens niet bij. Stel bv, een webapplicatie in ASP.NET. Als je een pagina herlaadt (een roundtrip maakt), dan ben je normaal alle informatie in user-defined objecten kwijt. Die zul je dus toch ergens moeten gaan bewaren.
De state van de webcontrols op die pagina kan behouden worden dmv de ViewState.

Zie ook dit topic:
[rml][ .NET] State in ASP.NET bewaren adhv Reflection en Attribute[/rml]
voor informatie over een generieke manier om het behouden van state in asp.net

[ Voor 7% gewijzigd door whoami op 11-02-2003 22:01 ]

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
whoami schreef op 11 februari 2003 @ 22:00:
[nohtml]
[...]


Toch wel toch?

Een stateless applicatie houdt gewoon zelf die gegevens niet bij. Stel bv, een webapplicatie in ASP.NET. Als je een pagina herlaadt (een roundtrip maakt), dan ben je normaal alle informatie in user-defined objecten kwijt. Die zul je dus toch ergens moeten gaan bewaren.
De state van de webcontrols op die pagina kan behouden worden dmv de ViewState.

Zie ook dit topic:
[rml][ .NET] State in ASP.NET bewaren adhv Reflection en Attribute[/rml]
voor informatie over een generieke manier om het behouden van state in asp.net
Ok, maar dan is de server dus de statefull ipv de client. Het komt er in ieder geval op neer dat je dus of veel met de server moet praten voor berekeningen, of je moet de berekeningen volledig plaats laten vinden op de server. Voor sommige dingen zoals websites ed is dit handig, maar het lijkt me dat dit niet overal voor toepasbaar is.

Als ik nog een keer dat trappenontwerp programma erbij pak, dan wil je sommige objecten ook lokaal gaan cachen zoals bv een houtsoort. Je zit dan automatisch vast aan een statefull client omdat dit gevisualiseerd moet worden en als het volledig op de server plaats vind, ongelovelijk traag gaat worden.

[ Voor 14% gewijzigd door Alarmnummer op 11-02-2003 22:24 ]


Acties:
  • 0 Henk 'm!

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 31-12-2024
Standaard oplossingen:

EntityBroker
Objectz.NET

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

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


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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 ]


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Whoa, als dat niet traag is als dikke kak in een te nauwe trechter dan weet ik het ook niet meer :D

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Anoniem: 50683

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.

Acties:
  • 0 Henk 'm!

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 31-12-2024
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 :D
Beargumenteer dat eens. Niet dat het niet zo is, maar toch...

Acties:
  • 0 Henk 'm!

  • PhoneTech
  • Registratie: Mei 2000
  • Laatst online: 09-07 14:31
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 ]


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 31-12-2024
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.

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 31-12-2024
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.

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
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.

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

Anoniem: 78067

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.

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
Anoniem: 78067 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.

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

Anoniem: 78067

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:
1
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
  • Registratie: Juli 2001
  • Laatst online: 31-12-2024
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
  • Registratie: Januari 2000
  • Niet online
Anoniem: 78067 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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • stylee
  • Registratie: December 2000
  • Laatst online: 04-09-2021

stylee

blah zeg ik je

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

Dank

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
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

https://fgheysels.github.io/


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Anoniem: 78067 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
  • Registratie: Januari 2000
  • Niet online
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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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 :P )

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


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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
  • Registratie: Januari 2000
  • Niet online
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 :P )
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 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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 :r

Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
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
  • Registratie: Januari 2000
  • Niet online
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 :)

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Anoniem: 78067

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 :)

Acties:
  • 0 Henk 'm!

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 31-12-2024
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 ]


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Anoniem: 78067 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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • maikel
  • Registratie: Januari 2001
  • Laatst online: 11-07 15:14
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.

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
[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?

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
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 ]

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • maikel
  • Registratie: Januari 2001
  • Laatst online: 11-07 15:14
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.

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
[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.

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • maikel
  • Registratie: Januari 2001
  • Laatst online: 11-07 15:14
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.

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
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.

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
[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?

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 31-12-2024
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.

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Martin Fowler
Afbeeldingslocatie: http://www.martinfowler.com/mf.jpg

boeken

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


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Oh dear, een extreme programming aanhanger. Vandaar dat hij er anders over denkt dan ik.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 31-12-2024
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.

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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.

Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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.

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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 ;)

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

Anoniem: 78067

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 :)

Acties:
  • 0 Henk 'm!

  • maikel
  • Registratie: Januari 2001
  • Laatst online: 11-07 15:14
Amen !

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

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Anoniem: 78067 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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • maikel
  • Registratie: Januari 2001
  • Laatst online: 11-07 15:14
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.
toon volledige bericht
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 ]


Acties:
  • 0 Henk 'm!

Anoniem: 78067

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.

Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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.

Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
[half-offtopic]

Raden jullie ook nog literatuur aan?

Acties:
  • 0 Henk 'm!

Anoniem: 78067

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.

Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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 :D En thuis ben ik ook nog eens klant bij mijn testprojecten.

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


Acties:
  • 0 Henk 'm!

Anoniem: 78067

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.

Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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 ]


Acties:
  • 0 Henk 'm!

  • tijn
  • Registratie: Februari 2000
  • Laatst online: 01-04 22:09
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.

Cuyahoga .NET website framework


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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.

Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
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.

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 31-12-2024
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 ]


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
Otis is ook aanwezig ;)

Acties:
  • 0 Henk 'm!

Anoniem: 78067

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).

Acties:
  • 0 Henk 'm!

  • tijn
  • Registratie: Februari 2000
  • Laatst online: 01-04 22:09
Anoniem: 78067 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).

Cuyahoga .NET website framework


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
Anoniem: 78067 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.

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
[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.

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • whoami
  • Registratie: December 2000
  • Laatst online: 00:48
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 ]

https://fgheysels.github.io/


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
paulgielens schreef op 15 February 2003 @ 13:34:
ps: ik mis trouwens Martin en Otis in deze discussie
.
Ik deed wel degelijk mee, Paul :)

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Anoniem: 78067 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.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 07-10-2022
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 ...

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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 ;)

Acties:
  • 0 Henk 'm!

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 07-10-2022
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 :o ) :
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

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024
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.

Acties:
  • 0 Henk 'm!

Anoniem: 78067

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 })

Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
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
:)

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


Acties:
  • 0 Henk 'm!

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Anoniem: 78067 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...

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Pagina: 1 2 Laatste