[alg] enterprise applicatie - totaal oplossing.

[whoami]

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

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

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

_MSDN

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

n-tier development

[Verwijderd]

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

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

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

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

een snelle hack voor weinig

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

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

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

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

[Verwijderd]

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

[...]

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

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

[Alarmnummer]

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

[mbravenboer]

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

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

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

[EfBe]

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

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

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

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

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

[mbravenboer]

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

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

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

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

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

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

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

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

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

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

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

[Alarmnummer]

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

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

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

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

[Verwijderd]

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

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

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

[Alarmnummer]

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

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

[mbravenboer]

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

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

[Alarmnummer]

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

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