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.