Ο τίτλος είναι γενικός, συνεπώς πρέπει να σας εξηγήσω αναλυτικά περι τίνος πρόκειται:

Ο στόχος είναι μια εφαρμογή back-end η οποία θα παρέχει ένα data entry interface για βάσεις δεδομένων του SQL Server (2000/2005). Οι προϋποθέσεις και χοντρικά η λειτουργικότητα είναι όπως παρακάτω:

- Δημιουργούμε ή λαμβάνουμε μια database με μη προκαθορισμένο/γνωστό schema στην οποία όμως έχουν οριστεί με ακρίβεια πίνακες, keys και constraints (relationships) μεταξύ των πινάκων.
- Διαβάζουμε όλη αυτή τη μεταπληροφορία από την εφαρμογή μας και δημιουργούμε ASP.NET Webforms οι οποίες χρησιμεύουν για την καταχώρηση πληροφοριών στους πίνακες, ερμηνεύοντας με έξυπνο τρόπο τα constraints ωστε να αποφασίσουμε ή να έχουμε μια ένδειξη ποιές είναι οι κύριες οντότητές μας, ποιά τα lookups, και γενικά πώς ερμηνεύεται το σύνολο των δεδομένων μας.
- Φυσικά, η εφαρμογή θα συμπεριφερεται "έξυπνα" και θα επιδέχεται περαιτέρω ρυθμίσεις (ορισμός περαιτέρω validations σε πεδία, ή fine-tuning του ποιες είναι οι κύριες οντότητές μας και του πώς διαμορφώνονται οι σχέσεις μεταξύ τους), μέχρι κάποιο επίπεδο. Η εφαρμογή θα έχει πρόσθετες δυνατότητες, όπως το να "μαντεύει" ή να δέχεται από εμάς ορισμούς για το ποιές ομάδες πινάκων αντιπροσωπεύουν π.χ. ιεραρχίες, ωστε να παράγεται το αντίστοιχο interface, και άλλα τέτοια όμορφα.

Τα παραπάνω απλά αναφέρονται σαν ένδειξη του τι θα κάνει μια τέτοια εφαρμογή. Δεν εξετάζω σε αυτή τη δημοσίευση τη σκοπιμότητα ούτε το concept, μια και αυτά είναι παγιωμένα και υπάρχουν λόγοι για τους οποίους είναι απαραίτητη μια τέτοια λειτουργικότητα. Αυτό όμως που θέλω είναι να περιγράψω το πώς γίνεται αυτό σήμερα σε ένα prototype που υπάρχει κατασκευασμένο, και να παραθέσω πιθανές κατευθύνσεις στην ανάπτυξη της πραγματικής εφαρμογής ωστε να δούμε διαφορετικές απόψεις.

Ετσι λοιπον υπάρχει σήμερα ένα prototype που λειτουργεί ως generator: Παράγει εφαρμογή ASP.NET 1.1 (σελίδες ASPX που κάνουν τις εργασίες που αναφέρθηκαν παραπάνω) δημιουργώντας τις με απλά string concatenations (τόσο το designer όσο και το code behind κομμάτι).

Οι πιθανές κατευθύνσεις που έχουν πέσει στο τραπέζι για την ανάπτυξη της εφαρμογής σε full scale είναι οι εξής:

ΠΡΟΣΕΓΓΙΣΗ 1: Code generation του code behind (είχα κάνει και παλιότερα μια ερώτηση για codedom) με καποιον τρόπο (αξιοποιώντας το codeDom, το myGeneration ή άλλο/αλλα APIs για τη δημιουργία του code behind. Για τη δημιουργία του designer / UI μέρους, μια template - based προσέγγιση. Εκεί θα ήθελα κάποιες προτάσεις / λύσεις. Ο,τι έχει αναφερθεί αυτή τη στιγμή περιλαμβάνει τα εξής εναλλακτικά σενάρια (ανεξαρτήτως βιωσιμότητας): String concatenation, XML/XSLT, codeDom, myGeneration ή myGeneration-like προσέγγιση.

ΠΡΟΣΕΓΓΙΣΗ 2: Εναλλακτικά, δυναμική δημιουργία σελίδων στο runtime (σελίδες που κατασκευάζονται διαβάζοντας τα metadata της βάσης και τις πρόσθετες δικές μας ρυθμίσεις στο runtime). Σε αυτή την περίπτωση δεν θα έχουμε "παραγόμενη" εφαρμογή αλλά μία και μοναδική εφαρμογή διαχείρισης, η οποία θα λειτουργεί δυναμικά ανάλογα με τα metadata που θα την "ταϊζουμε".

Στην προσέγγιση 1 ειναι λογικό οτι με ένα σύστημα abstract/concrete κλάσεις θα είναι εύκολο το regeneration του όλου πράγματος αν αλλάξει το schema, χωρίς να χάνεται όποιο customization έχει (σχετικά εύκολα) γίνει στις concrete κλάσεις. Από την άλλη μεριά, στην προσέγγιση 2 έχουμε μεγαλύτερη ευελιξία αλλά βραδύτερο response και φυσικά ο μόνος τρόπος να κανουμε customization είναι να χώσουμε hooks τα οποία θα αξιοποιούμε με reflection.

Αν και καταλαβαίνω οτι θα μπορούσα να συνεχίσω να γράφω λεπτομέρειες, σταματώ εδώ. Θα ήθελα την δικής σας άποψη / ερωτήσεις και πρόσθετες / εναλλακτικές προτάσεις πάνω στο ποιά από τις δύο αυτές προσεγγίσεις κρίνετε πιό αποτελεσματική (ή αν έχετε να προτείνετε κάποια εναλλακτική προσέγγιση). Μιλάμε πάντοτε για Web-based interface με βασικούς άξονες την ευελιξία, τη συντηρησιμότητα και την ευκολία προσθήκης νέων features.

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Καλησπέρα Σωτήρη,

Μπορεί να το έχεις δει ήδη. Κάτι σαν αυτό που θέλεις να κάνεις (ΠΡΟΣΕΓΓΙΣΗ 2) είναι έτοιμοι να βγάλουν οι Developer Express. Το ονομάζουν ExpressApp framework και αυτή τη στιγμή επιτρέπει να τρέχεις δυναμικά WinForm και WebForm apps, ενώ το μόνο που κάνεις είναι να ορίζεις διάφορες παραμέτρους σε μια μορφή metadata σε XML (μέσω ενός editor που υπάρχει στο design time). Θα μπορούσες να πάρεις μερικές ιδέες από εκεί:

http://www.devexpress.com/Products/NET/Libraries/eXpressApp/

Εκτός από τη δομή του UI, όλο το business logic το γράφεις σε classes που βασίζονται στο XPO, ένα OPF γραμμένο πάλι από τους Developer Express, το οποίο βλέπει όλες σχεδόν τις δημοφιλείς βάσεις δεδομένων. Βέβαια, αυτό δε βολεύει ιδιαίτερα όταν θέλεις να ενσωματώσεις υπάρχουσες (legacy) βάσεις, αν και θεωρητικά μπορείς να κάνεις mapping των classes στους πίνακες. Κυρίως όμως είναι για νέες εφαρμογές που δεν έχουν ακόμα σχεδιαστεί.

---

Πέτρος

Πολύ ενδιαφέρον και άξιον μελέτης και σίγουρα θα του ρίξω μια ματιά.

Από μια πολύ γρήγορη πάντως ματιά που του έριξα, με κάθε επιφύλαξη βέβαια, θα τολμούσα να πω οτι ίσως είναι too much για αυτό που θέλω να κάνω. Δεν ξέρω αν θέλω να φτάσω στο σημείο να έχω ολοκληρωμένη εφαρμογή σε αυτό το επίπεδο, και σίγουρα όχι με το effort που απαιτεί το συγκεκριμένο framework. Περισσότερο ήθελα μια "point and shoot" (αν επιτρέπεται αυτός ο παραλληλισμός όρων) κατάσταση. (Δείξε μου τη ΒΔ να σου βγάλω το interface στα γρήγορα, και αμα θέλεις όρισε και περισσότερα πράγματα εκ των υστέρων).

Επιπρόσθετα, δεν δίνουν πληροφορίες για το κόστος του εν λόγω framework, πράγμα που με... φοβίζει λίγο :)

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Νομίζω Σωτήρη, ότι η λύση στο δίλημμά σου, είναι το ... abstraction.

Οριοθέτησε το interface που θές για ένα service, το οποίο θα γίνει parent σε 2 implementations, με κοινά semantics. Είναι το τυπικό
provider μοντέλο που ακολουθεί και το ASP.NET.

Off the top of my head τώρα, και καθώς γράφω, σκέφτομαι ότι  θα μπορούσες να χρησιμοποιήσεις ένα provider μοντέλο, με ένα απλό interface, υλοποιώντας έναν
IHttpHandlerFactory. Είναι κάτι σαν HttpHandler, αλλά ένα level πιό πάνω. 

Μέσα εκεί, και ανάλογα το configuration σου, θα μπορούσες να γυρίζεις στο ASP.NET instance της σελίδας η οποία θα εξυπηρετήσει το request. Αυτή μπορείς να την παράγεις
@ runtime, ή να τη φορτώσεις απο ένα assembly που θα έχει μέσα τα πάντα σαν embedded resources, ή απο ένα κανονικό ASP.NET installation, με τα aspx στο δίσκο κτλ. κτλ.

Τώρα, όσον αφορά την επιλογή ανάμεσα στα 2 implementations, όπως βλέπεις κι εσύ και όλοι, καθεμία λύση έχει υπέρ και κατά. Οπότε, προτιμώ να έχω απλώς τη δυνατότητα να διαλέξω, και κυρίως τη δυνατότητα να αλλάξω εύκολα την επιλογή μου ;]

-- Διόρθωση --

Βασικά, αυτό που σκέφτομαι είναι ότι αν μπορείς να το κάνεις @ runtime για μια σελίδα, τότε μπορείς να το κάνεις και ως batch διαδικασία για όλες τις σελίδες. Το μόνο που χρειάζεσαι είναι ενα site map.

---

Angel
O:]

(Ζαλίστηκα λίγο)

Η εγώ δεν το πολυέπιασα (πράγμα πολύ πιθανό) ή δεν έχω κάνει κατανοητό το intent μου (πράγμα επίσης πολύ πιθανό). Προτείνεις να φτιάξω κάτι το οποίο να λειτουργεί ΤΑΥΤΟΧΡΟΝΑ ως generator και ως runtime;

Επίσης την τελευταία σου πρόταση (στη διόρθωση) τολμώ να πω οτι δεν την κατανόησα καθόλου. Have mercy, είμαι μικρος ακομα :) (μονο 34 - σύντομα). :) Αν θέλεις, μπορείς να μου δώσεις λίγες περισσότερες λεπτομέρειες γύρω από το σύνολο των σκέψεών σου;

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Είμαι βέβαιος ότι το έχεις ψάξει αλλά γιατί τα codesmith+nettiers ή κάποιος άλλος έτοιμος code generator δεν σου κάνει ?

---

Harry Tsavdaris

Σκεφτόμουν το εξής:


Έρχεται ένα request στην εφαρμογή σου - Π.χ. η λίστα όλων για ένα συγκεκριμένο table.

Αυτό, θα απαντήθει τελικά απο ένα instance ενός Page. Αν είναι generated @ runtime, pre-compiled σε ένα DLL, ή "ανοιχτό" aspx και  .cs στο website root σου, βασικά δε σε ενδιαφέρει. Αυτό το οποίο σε ενδιαφέρει είναι ότι κάποιος πρέπει να σου δώσει ένα instance μιας σελίδας να εξυπηρετήσει το request σου.  Αυτός ο "κάποιος"  μπορεί να οριστεί σε ένα interface, και απο 'κεί και πέρα, υλοποιείς όσες μεθόδους θές για να δημιουργείς μια σελίδα απο metadata.

Στο σημείο μέσα στο ASP.NET processing  pipeline στο οποίο το σύστημα επιλέγει ποιά σελίδα  θα εκτελεστεί τελικά, μπορείς να παρέμβεις με έναν Systm.Web.IHttpHandlerFactory. Δίνεις το δικό σου implementation στο σύστημα, και επιλέγεις πλέον εσύ τη σελίδα - και εννοώ τη σελίδα ως live instance μιας κλάσσης, όχι απλώς ένα virtual path - που θα γυρίσεις στο ASP.NET.

Το IHttpHandlerFactory interface ορίζεται ώς εξής:

IHttpHandler GetHandler( HttpContext context, string requestType, string url, string pathTranslated );

void ReleaseHandler( IHttpHandler handler );

H βασική του διαφορά απο τον απλό IHttpHandler είναι οτι το IHttpHandlerFactory είναι .. ο πατέρας του, ένα σκαλί πιο κάτω στο σύστημα. Δέχεται το incoming request, και επιστρέφει το instance ενός IHttpHandler το οποίο τελικά θα εξυπηρετήσει το request.

Μέσα πλέον εκεί, και έχοντας κάνει deploy μιας ή περισσότερων μεθόδων παραγωγής σελίδων - είτε είναι pre-compiled assembly μετα απο code generation ενός ολόκληρου site, είτε μετά απο "συναρμολόγηση" δυναμικά απο τα metadata σου - επιστρέφεις το αποτέλεσμα αυτής της μεθόδου, χωρίς σχεδόν να ξέρεις πως παρήχθηκε η σελίδα.

Π.χ. ...

public IHttpHandler GetHandler( HttpContext context, string requestType, string url, string pathTranslated ) {
    // Get an isntance of my configured PageFactory for this url ...
     IPageFactory currFactory = PageFactory.GetFor(context, url);
    // okay, now tell him to create or retrieve a ready made page to handle my request ...
    return currFactory.BuildPageFor(context, url);
}

To έχω αφήσει επίτηδες 2 γραμμές, για να τονίσω το εξής. Μπορεί να συνδιάσεις έτσι πολλούς τρόπους παραγωγής σελίδων για το σύστημά σου.

• Μπορεί ας πούμε κάποιο sub-folder να προτιμάς να παράγεται απο κάποιο pre-compiled assembly, το οποίο περιέχει τόσο το code behind, όσο και το designer μέρος, όπως και τα aspx, σαν embedded resources. Ένα τελείως κλειστό σύστημα, ίσως για κάποιον κώδικα που δε θές να μοιραστείς ή για οποιονδήποτε άλλο λόγο.
• Ένα άλλο sub-folder, ίσως περιέχει admin για κάποια tables στη βάση, τα οποία αλλάζουν συνεχώς οι πελάτες σου. Οπότε, το κάνεις generated at runtime, για να έχεις την ευκολία της αλλαγής.
• Ίσως ακόμη κάποιο άλλο folder το έχεις τελείως με το standard ASP.NET τρόπο, μέσα στο site root. Aspx, .cs αρχεία, μια τελείως normal εγκατάσταση.

Αυτό το μοντέλλο σου δίνει την ελευθερία του pick 'n' mix. Δε χρειάζεται να κάνεις μια τελική επιλογή, μέχρι να χρειαστεί να την κάνεις. Και τότε, είσαι ευέλικτος αρκετά για να το κάνεις εύκολα.

Επίσης, σκεφτόμουν την περίπτωση στην οποία ακόμη δημιουργείς το code generation μέρος σου.

• Για όσο δοκιμάζεις τη λειτουργικότητα, το μέρος δηλαδή στο οποίο κάνεις generate τη σελίδα, aspx, code-behind, compile κτλ, το κάνεις χρησιμοποιώντας τον normal "files in folder" provider.
• Όταν αυτό οριμάσει αρκετά και δεν κάνεις πλέον debug πάνω του, το μετατρέπεις σε ένα provider κι αυτό. Οπότε τώρα, παράγεις τις σελίδες σου at runtime.

Και αυτό με φέρνει στη "διόρθωση" του τελευταίου μου post.

Άν έχεις ένα τρόπο να κάνεις generate μια σελίδα απο metadata και παραμέτρους,  τι σε εμποδίζει να χρησιμοποιήσεις αυτη τη λειτουργικότητα για να παράγεις ολόκληρο το site offline, και να το κάνεις package σε ένα assembly; Τίποτα. Χρειάζεσαι απλώς μια λίστα με όλες τις σελίδες στο site που θες να φτιάξεις - ένα site map.

Αυτό ήταν το νόημα. νομίζω. Όταν δεν μπορείς να διαλέξεις μόνο ένα τρόπο να κάνεις κάτι, το "κρύβεις" πίσω απο ένα interface και το κάνεις configurable για να υποστηρίζεις όσες μεθόδους θές τώρα, και στο μέλλον.

---

Angel
O:]

tsavos:

Είμαι βέβαιος ότι το έχεις ψάξει αλλά γιατί τα codesmith+nettiers ή κάποιος άλλος έτοιμος code generator δεν σου κάνει ?

Μην είσαι καθόλου βέβαιος!

Το nettiers δεν το είχα υπόψη μου και, φυσικά, το κατέβασα και το είδα. Δεν κατάφερα να δημιουργήσω κάτι που να "παίζει" (έτρωγα διάφορα errors στο build του generated πράγματος σε διάφορες βάσεις). Αν δουλέψει, μπορεί να είναι μια καλή αρχή για να εξετάσω κάποια πράγματα, θα δημοσιεύσω εδώ ο,τι δω από αυτό.

Ο λόγος που δεν το έψαξα είναι γιατί η εφαρμογή αυτή είχε ήδη παραχθεί ως ένα βαθμό από άλλο προγραμματιστή. Εξετάζω λοιπόν τρόπους να την κάνω καλύτερη βασιζόμενος στην ήδη υπάρχουσα υλοποίηση (ακόμα και αν αυτή λειτουργεί ως prototype). Ομως, αν *κάτι* σαν το nettiers ή άλλο code generator μου δώσει ευκολότερους τρόπους υλοποίησης, φυσικά και θα το λάβω σοβαρά υπόψη μου!

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

anjelinio:

Αυτό ήταν το νόημα. νομίζω. Όταν δεν μπορείς να διαλέξεις μόνο ένα τρόπο να κάνεις κάτι, το "κρύβεις" πίσω απο ένα interface και το κάνεις configurable για να υποστηρίζεις όσες μεθόδους θές τώρα, και στο μέλλον.

Αρχίζω και καταλαβαίνω. Περιττό να σου πώ βέβαια οτι εντοπίζω μια διαφορά "φάσης" στο τι προσπαθείς να μου πεις και στο τι καταλαβαίνω (σαφώς κατανοώ λιγότερα από όσα προσπαθείς να μου πεις - και για αυτό ευθύνεται - υποψιάζομαι - το σαφώς μικρότερο εύρος γνώσης μου, οπότε ζητώ προκαταβολικά να με συγχωρέσεις αν δεν το "πιάνω" στο 100% του).

Πήγαμε όμως ένα βήμα πιό πέρα. Να υλοποιήσουμε μια τεχνική που θα καλύπτει όλες τις πιθανές μεθόδους υλοποίησης; Χμ! Ελκυστικό ναι μεν, overengineering όμως μου μυρίζει. Εχουμε να λύσουμε - πριν από αυτό - τα specifics της κάθε μιας υλοποίησης. Προφανώς άλλα είναι αυτά στο code generation, άλλα στο runtime page construction και άλλα σε άλλες υλοποιήσεις. Τώρα, εκεί εστίασα και την αρχική μου ερώτηση - στα specifics. Δηλαδή, το πόσο μπορεί να επιβιώσει μια υλοποίηση με τον ένα ή με τον άλλο τρόπο. Δεν σκέφτηκα, είναι η αλήθεια, να συνδυάσω όλες τις υλοποιήσεις, κυρίως λόγω του μεγάλου κόστους που αυτό συνεπάγεται.

Κρατώ το μήνυμά σου και θα το περάσω από "κόσκινο" αρκετά σύντομα για να κάνω το comeback μου με περισσότερες ερωτήσεις :)

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

cap:

tsavos:

Είμαι βέβαιος ότι το έχεις ψάξει αλλά γιατί τα codesmith+nettiers ή κάποιος άλλος έτοιμος code generator δεν σου κάνει ?

Μην είσαι καθόλου βέβαιος!

Το nettiers δεν το είχα υπόψη μου και, φυσικά, το κατέβασα και το είδα. Δεν κατάφερα να δημιουργήσω κάτι που να "παίζει" (έτρωγα διάφορα errors στο build του generated πράγματος σε διάφορες βάσεις). Αν δουλέψει, μπορεί να είναι μια καλή αρχή για να εξετάσω κάποια πράγματα, θα δημοσιεύσω εδώ ο,τι δω από αυτό.

Ο πιθανότερος λόγος για τα λάθη είναι ότι το nettiers απαιτεί κάποια tweaks όταν σχεδιάζεις την βάση. Βασικά δηλ. θέλει σε ΚΑΘΕ πίνακα να έχεις ένα autonum ακόμα και αν ήδη έχεις άλλο primary key. Γενικά εμένα δε μου έχει συμβεί και τα θεωρώ αρκετά αξιόπιστα.

---

Harry Tsavdaris

cap:

Περιττό να σου πώ βέβαια οτι εντοπίζω μια διαφορά "φάσης" στο τι προσπαθείς να μου πεις και στο τι καταλαβαίνω (σαφώς κατανοώ λιγότερα από όσα προσπαθείς να μου πεις - και για αυτό ευθύνεται - υποψιάζομαι - το σαφώς μικρότερο εύρος γνώσης μου, οπότε ζητώ προκαταβολικά να με συγχωρέσεις αν δεν το "πιάνω" στο 100% του).

... προς θεού, κανείς δεν είναι ... ubergeek. Μαθαίνεις πράγματα, όταν τα βρείς μπροστά σου.

Όσον αφορά τα "specifics" τώρα ...

Κατα τη γνώμη μου, το runtime page construction ... πονάει. Είναι ίσως πιο εύκολο στην υλοποίηση, αλλά ανάλογα το πως θα το κάνεις πάντα.  Αν π.χ. στο init αρχίζεις και parse-άρεις τα metadata σου και προσθέτεις δυναμικά controls στη σελίδα σου είναι σχετικά εύκολο σαν υλοποίηση. Θα έχεις πιθανώς θέματα με performance, αλλά μόνο σε πολύ μεγάλο αριθμό χρηστών θα γίνει πια major issue. Major benefit ... ευελιξία. Αλλάζεις ένα δύο config settings, άλλαξε και η εφαρμογή σου, χωρίς re-compiles κτλ κτλ

To Code Gen θα είναι λίγο πιο δύσκολο - κι αυτό βέβαια ανάλογα το πως θα το κάνεις. Φαντάζομαι ότι απο τα metadata σου, και ανάλογα τον τύπο κάθε πεδίου θα χρειαστείς κάποια templates τόσο για το aspx, όσο και για το code behind, τα οποία θα "πακετάρεις" παρεούλα για να παράγεις τη σελίδα σου.  Και μετά compile. Εγώ θα στόχευα να μπορείς να το κάνεις είτε  offline, είτε @ runtime αυτό το generation. Για να μπορείς μετά να παράγεις ένα ολόκληρο site μέσα σε ένα assembly DLL. To benefit είναι performance, και "κλειστός" κώδικας - ο πελάτης σου θα γυρίζει σε 'σενα πάντα.

Βασικό θεωρώ το να μπορείς να κάνεις package σε assembly DLL, για τον εξής λόγο. Η Code Gen λύση σου, θα μπορούσε να παράγει τις σελίδες ΚΑΙ @ runtime, ως μέρος ενός assembly στη μνήμη. Έτσι, αν το aasembly σου περιέχει υλοποίηση για μια σελίδα, δε χρειάζεται να την ξανα-κάνεις generate. Συνεπαγεται ότι αν έχεις όλες τις σελίδες στο in-memory-assembly, δε θα χρειαστεί να ξανακάνεις compile τίποτα, και το site θα "πετάει". Αυτό έχει και το ενδιαφέρον side-effect ότι αν έχεις φτιάξει το assembly σου offline, απλώς το κάνεις deploy πάνω στη "μηχανή/framework/runtime" και παίζει.

Και οι δύο περιπτώσεις είναι "παράλληλες" όσον αφορα΄την υλοποίηση. Στη μιά κάνεις assemble controls σε μια σελίδα, στην άλλη κάνεις assemble κομμάτια απο templates τα οποία στο τέλος κάνεις compile. Προτείνω και πάλι το code gen σαν καλύτερη λύση όμως.

---

Angel
O:]

Δεν πρόλαβα ακόμα να διαβάσω την ερώτηση σου ολόκληρη (ούτε και τώρα πρόλαβα να τη διάβασω ) αλλά μου δόθηκε η εντύπωση ότι θέλεις να φτιάξεις UI από έτοιμο σχήμα βάσης. Δες το Ideablade DevForce Express, το οποίο είναι τσάμπα για client/server εφαρμογές. Σε Open Source υπάρχει και το Monorail το οποίο χρησιμοποιεί τεχνικές παρόμοιες με του Ruby on Rails. Το expressApp Framework της DevExpress είναι ακατάλληλο καθώς δεν επιτρέπει να χρησιμοποιήσεις υπάρχον σχήμα - δημιουργεί μόνο του πίνακες από το object model της εφαρμογής σου.

Μην θεωρείς ότι ένα έτοιμο framework είναι too much. Αν κάνει τη δουλειά γρήγορα, δεν χάνεις τίποτε. Η λειτουργικότητα που ζητάς υπάρχει έτοιμη, απλά υπάρχουν και πολλά επιπλέον πράγματα. Αντιθέτως, αν προσπαθήσεις να φτιάξεις τη δική σου λύση με code generators οι οποίοι δεν έχουν ήδη έτοιμο το template που χρειάζεσαι, μπορείς να ξοδέψεις πολύ περισσότερο χρόνο.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos