Design & Architecture

Απ: Composite Entities

Markos — Mon, 04 Oct 2010 06:41:44 GMT

Τελικά τι γίνεται με αυτό το πρόβλημα; Η λύση περπατάει;

Απ: Composite Entities

infoCENTER — Tue, 31 Aug 2010 17:42:11 GMT

Μόλις γύρισα από τις ολιγοήμερες διακοπές μου και είδα ότι όσο χρόνο έλειπα το Thread δεν πέθανε.

Και οι δύο πιάσατε ακριβώς το πρόβλημα. Και ο Markos έχει δίκιο σε αυτό που γράφει αλλά και ο George επίσης. Είναι το πιο δύσκολο UI που θα έχω φτιάξει μέχρι τώρα και αυτό το κατάλαβα από νωρίς. Να πω μερικά πράγματα σχεδιασμού ακόμα.

Το σενάριο μεταξύ δύο χρηστών όπου ο ένας κάνει μία αλλαγή πότε θα την δει ο άλλος. Εδώ και αρκετό καιρό έχω φτιάξει ένα προγραμματάκι το οποίο στήνεται στον Server και λαμβάνει μηνύματα από τους clients. Επειδή το πρόβλημα των αλλαγών των χρηστών δεν εμφανίζεται μόνο σε αυτό το πρόγραμμα αλλά και σε άλλα είχα αποφασίσει πριν καιρό να φτίάξω αυτό το πρόγραμμα, το οποίο όταν γίνει κάποια αποθήκευση από κάποιον client ενημερώνεται με message από το συγκεκριμένο client και στην συνέχεια ενημερώνει τα υπόλοιπα clients του δικτύου με ένα μήνυμα τύπου Entity-Client, Id-104, Action-Created. Ο κάθε client ανάλογα με το μήνυμα θα κάνει και την ανάλογη ενέργεια για να ενημερώσει το UI του χρήστη. Το πρόγραμμα αυτό με έχει βολέψει πάρα πολύ και πρόσφατα του πρόσθεσα και την δυνατότητα να κρατάει log κινήσεων κτλ. Οπότε σκεφτόμουν να χρησιμοποιήσω την ίδια προσέγγιση για την λύση του προβλήματος των χρηστών και τις αλλαγές μεταξύ τους.

Στο UI τώρα ο Markos το έχει πιάσει ακριβώς. Έτσι το σκέφτομαι και έτσι θα ήθελα να το κάνω. Νόμιζα και νομίζω ότι το Binding θα πρέπει να είναι μία τεχνολογία που πρέπει να χρησιμοποιήσω. Μου λύνει το πρόβλημα των Notification μεταξύ των φορμών και των entity. Αλλάζω κάτι σε ένα entity σε μία φόρμα, αυτόματα η αλλαγή φαίνεται και σε άλλο σημείο του UI. Επίσης μου λύνει το πρόβλημα της εμφάνισης λαθών που υπάρχουν μέσα στα entities μου. To Binding όμως θέλει DataTables ή Classes που να έχουν properties. Τα DataTables τα άφησα στην άκρη και πήγα στις Classes. Έτσι κατέληξα σε αυτό που λέω Composite Entities. Είναι όμως η σωστή προσέγγιση; Δεν ξέρω.

Επίσης μην αναφέρεται WPF. Αν και έχω αρχίσει ήδη να ασχολούμαι με αυτό δεν μπορώ να πω ότι αισθάνομαι άνετα ακόμα για ανάπτυξη εφαρμογής. Το project είναι καθαρά Winforms.

Απ: Composite Entities

Markos — Mon, 30 Aug 2010 04:11:23 GMT

George J. Capnias:

Και πως αυτό το κάνει διαφορετικό, από το ανοίγουν πολλοί χρήστες, την ίδια φόρμα;

Η περίπτωση του "πολλοί χρήστες που επεξεργάζονται το ίδιο entity", είναι μια πιο γενική περίπτωση του "ένας χρήστης επεξεργάζεται το ίδιο entity περισσότερες από μία φορές", ή κάνω λάθος;

George J.

Ένα - ένα τα προβλήματα... Οι αλλαγές που έχει κάνει ένας άλλος χρήστης έχουν ήδη περαστεί στη βάση, είναι committed και ο άλλος χρήστης λαμβάνει γνώση γι' αυτές μέσω κάποιου μηχανισμού (poll ή ένα message από τον server, όπως έγραψες). Πρόκειται για ένα βήμα παραπέρα. Το πρόβλημα του "επεξεργάζομαι το ίδιο entity πολλές φορές, σε διαφορετικές φόρμες, άλλες grid - άλλες detail και όλ' αυτά θέλω να συγχρονίζονται στο UI" είναι κατά τη γνώμη μου άλλης φύσης. Οι αλλαγές μπορεί να γίνουν commit, μπορεί και όχι (αλλά πρέπει να φαίνονται σε όλες τις "εμπλεκόμενες" φόρμες). Ενδέχεται να ανοίξω μια detail φόρμα για fast entry και να κάνω add σε entities, αλλά θέλω τα additions να φαίνονται στο grid που έχω "πίσω μου" και που εμφανίζει όλες τις εγγραφές μαζί. Αλλάζω, όμως γνώμη τελευταία στιγμή και κάνω cancel στις προσθήκες. Άλλo παράδειγμα: Έχω ανοιχτή μια detail φόρμα που επεξεργάζομαι ένα entity, το οποίο υπάρχει σε άλλη φόρμα σε ένα grid. Κάτι συμβαίνει διακόπτω την εργασία μου και όταν γυρίζω, "μπαίνω" στο grid, διαγράφω το entity και κάνω commit τη διαγραφή. Περιμένω, λοιπόν, να κλείσει και η φόρμα του detail χωρίς να κάνω κάποια περαιτέρω ενέργεια. Μιλάμε δηλαδή για ένα UI στο οποίο συμβαίνουν πολύ ωραία πραγματάκια ταυτόχρονα. Νομίζω, λοιπόν, ότι η ερώτηση που έκανε το μέλος είναι για το πως μπορεί να υλοποιηθεί ένας τέτοιος μηχανισμός, ώστε να επιτυγχάνεται μιας τέτοιας μορφής synchonization στο UI. Βεβαίως, ρώτησε και πως να σχεδιάσει τα objects του για να γίνει το εγχείρημα πιο εύκολο. Τώρα, αν σ' αυτό το "χαμό" βάλουμε και τα notifications από τη βάση... Ομολογώ, δεν το έχω ξανακάνει και απλά καταθέτω κάποιες σκέψεις για το πως μπορεί να επιτευχθεί. Κάποιος που το έχει ξανακάνει μπορεί να γίνει πολύ πιο συγκεκριμένος και να μας βάλει στο σωστό δρόμο.

Απ: Composite Entities

George J. Capnias — Mon, 30 Aug 2010 03:14:54 GMT

Markos:
Εγώ γιατί έχω καταλάβει ότι δεν αναφέρεται σ' αυτό; Δε νομίζω ότι ρωτάει πως ο ένας χρήστης θα βλέπει τις αλλαγές που κάνει ο άλλος. Θέλει έναν τρόπο να συγχρονίζει τα δεδομένα στις φόρμες του ίδιου χρήστη. Ο ίδιος χρήστης να μπορεί ν' ανοίγει πολλαπλές φόρμες (άλλες grid, άλλες detail), με τα κοινά δεδομένα, και οι αλλαγές που γίνονται στα properties ενός entity - αν αυτό το entity υπάρχει και στις υπόλοιπες φόρμες - να εμφανίζονται ταυτόχρονα κι εκεί, με όλα όσα αυτό συνεπάγεται στο γενικότερο συγχρονισμό των φορμών (π.χ. validation). Το πλήθος των φορμών δεν είναι γνωστό από την αρχή και η πιο ακραία περίπτωση είναι ένας χρήστης να παίζει με το button του "open form" και ν' ανοίγει πολλαπλές detail φόρμες για το ίδιο entity. Αφού βαρεθεί να παίζει, να μπορεί να στείλει τις αλλαγές στη βάση απ' όποια φόρμα θέλει και όλες οι υπόλοιπες detail φόρμες να ξέρουν ότι το state του entity δεν είναι πια modified, αλλά current. Αν η αποθήκευση δεν πραγματοποιηθεί, όλες οι φόρμες να ενημερωθούν γι' το σφάλμα κ.λπ, κ.λπ.

Και πως αυτό το κάνει διαφορετικό, από το ανοίγουν πολλοί χρήστες, την ίδια φόρμα;

Η περίπτωση του "πολλοί χρήστες που επεξεργάζονται το ίδιο entity", είναι μια πιο γενική περίπτωση του "ένας χρήστης επεξεργάζεται το ίδιο entity περισσότερες από μία φορές", ή κάνω λάθος;

George J.

Απ: Composite Entities

Markos — Mon, 30 Aug 2010 00:58:38 GMT

George J. Capnias:

Παράδειγμα: Αν δύο διαφορετικοί χρήστες, βλέπουν την ίδια καρτέλα και ο ένας αλλάξει τα δεδομένα και θέλουμε ο άλλος να δει την αλλαγή, τι πραγματικά συμβαίνει:

Αυτός που βλέπει τα δεδομένα θα δει τις αλλαγές όταν

είτε ο client του κάνει ένα poll και καταλάβει ότι άλλαξαν τα δεδομένα (disconnected enviroment),
είτε λάβει ένα message από το server ότι άλλαξαν τα δεδομένα (always connected enviroment).

Στην πρώτη περίπτωση, ο client σε τακτά χρονικά διαστήματα κάνει poll στον server για να δει αν υπάρχουν αλλαγές. Καταλαβαίνουμε ότι ένα μεγάλο ποσοστό των polls θα είναι άχρηστο, μιας και δεν θα έχουμε τόσες πολλές αλλαγές, και ταυτόχρονα θα επιβαρύνεται ο server κάθε φορά που θα πρέπει να απαντάει σε αυτά τα polls.
Στην δεύτερη περίπτωση, ο client έχει ανοιχτή σύνδεση στον server, και αναμένει ένα message. Σε αυτή την περίπτωση, o client θα περιμένει τον περισσότερο καιρό χωρίς να λαμβάνει τίποτα, απλά καταναλώνοντας resources από τον server.
Και στις δύο περιπτώσεις, σε περιβάλλοντα που υπάρχει μεγάλος φόρτος "πραγματικής εργασίας", ο φόρτος που προσδίδεται είτε από τον client με τα συνεχή polls στον server, είτε τα resources που καταναλώνονται στον server με την συνεχή σύνδεση τους με τον client, συνεισφέρουν αρνητικά στις επιδόσεις του συστήματος.
Δεν υπάρχει "χρυσός κανόνας" για το πως θα πρέπει να υλοποιηθεί η πολιτική - είναι αυτό που είπα παραπάνω ότι όλα εξαρτιούνται από το "πόσο σωστά έχεις κάνει την εκτίμησή σου". Η αλήθεια είναι ότι το σύνηθες είναι η υλοποίηση να είναι μέρος ή/και συνδυασμός σημείων από τις δύο παραπάνω περιπτώσεις.

Εγώ γιατί έχω καταλάβει ότι δεν αναφέρεται σ' αυτό; Δε νομίζω ότι ρωτάει πως ο ένας χρήστης θα βλέπει τις αλλαγές που κάνει ο άλλος. Θέλει έναν τρόπο να συγχρονίζει τα δεδομένα στις φόρμες του ίδιου χρήστη. Ο ίδιος χρήστης να μπορεί ν' ανοίγει πολλαπλές φόρμες (άλλες grid, άλλες detail), με τα κοινά δεδομένα, και οι αλλαγές που γίνονται στα properties ενός entity - αν αυτό το entity υπάρχει και στις υπόλοιπες φόρμες - να εμφανίζονται ταυτόχρονα κι εκεί, με όλα όσα αυτό συνεπάγεται στο γενικότερο συγχρονισμό των φορμών (π.χ. validation). Το πλήθος των φορμών δεν είναι γνωστό από την αρχή και η πιο ακραία περίπτωση είναι ένας χρήστης να παίζει με το button του "open form" και ν' ανοίγει πολλαπλές detail φόρμες για το ίδιο entity. Αφού βαρεθεί να παίζει, να μπορεί να στείλει τις αλλαγές στη βάση απ' όποια φόρμα θέλει και όλες οι υπόλοιπες detail φόρμες να ξέρουν ότι το state του entity δεν είναι πια modified, αλλά current. Αν η αποθήκευση δεν πραγματοποιηθεί, όλες οι φόρμες να ενημερωθούν γι' το σφάλμα κ.λπ, κ.λπ.

Απ: Composite Entities

George J. Capnias — Sun, 29 Aug 2010 23:38:26 GMT

Είναι τρεις μέρες τώρα που θέλω να απαντήσω σε αυτό το thread και δεν βρήσκω τον χρόνο - μάλλον η full season άρχισε ποιο νωρίς από ότι περίμενα...

Ας αρχίσω από τα πιο εμφανή σημεία:

Η βάση μπορεί να υλοποιηθεί με πίνακες που μεταξύ τους θα έχουν 1-1 σχέση. Ένας πίνακας θα είναι οι εργαζόμενοι που θα είναι reference για τους άλλους πίνακες - έτσι ο πίνακας, με τους οδηγούς, έχει 1-1 σχέση με τον πίνακα εργαζόμενοι, όπως και ο πίνακας με τους μηχανικούς. Παρόμοια μπορεί να αντιμετωπιστεί και ο πίνακας με τα δεδομένα που απαιτούνται για την μισθοδοσία. Ένα παράδειγμα υλοποίησης για ένα παρόμοιο σενάριο - αρκετά πιο πολύπλοκο - είναι η βάση AdventureWorks, που έρχεται με τα samples του Microsoft SQL Server. Δεν νομίζω ότι υπάρχει κάτι περισσότερο να πω επάνω σε αυτό.
Data Access - θα πρέπει να χρησιμοποιήσεις κάποια από τις έτοιμες τεχνολογίες για αυτό - δεν απαιτείται να φτιάξεις κάτι από μόνος σου.

Από αυτά που αναφέρεις, αυτό που καταλαβαίνω είναι ότι αυτό που σε ενδιαφέρει, είναι ότι όταν δύο διαφορετικοί χρήστες βλέπουν τα δεδομένα και ο ένας κάνει αλλαγές, θα πρέπει οι αλλαγές να είναι ορατές και στον άλλο χρήστη. Αυτό είναι το σημείο που μιλάμε για το concurrency των διεργασιών που ενημερώνουν τα δεδομένα. Σε ένα μεγάλο σημείο το η υλοποίηση της πολιτικής του concurrency εξαρτάται από τις τεχνολογίες που χρησιμοποιείς, πως μπορούν να βοηθήσουν σε αυτό, και κατά δεύτερο στο πόσο σωστά έχεις κάνει την εκτίμησή σου για το πως θα γίνει η υλοποίηση της πολιτικής ενημέρωσης των δεδομένων στην εφαρμογή σου.

Παράδειγμα: Αν δύο διαφορετικοί χρήστες, βλέπουν την ίδια καρτέλα και ο ένας αλλάξει τα δεδομένα και θέλουμε ο άλλος να δει την αλλαγή, τι πραγματικά συμβαίνει:

Αυτός που βλέπει τα δεδομένα θα δει τις αλλαγές όταν

είτε ο client του κάνει ένα poll και καταλάβει ότι άλλαξαν τα δεδομένα (disconnected enviroment),
είτε λάβει ένα message από το server ότι άλλαξαν τα δεδομένα (always connected enviroment).

Στην πρώτη περίπτωση, ο client σε τακτά χρονικά διαστήματα κάνει poll στον server για να δει αν υπάρχουν αλλαγές. Καταλαβαίνουμε ότι ένα μεγάλο ποσοστό των polls θα είναι άχρηστο, μιας και δεν θα έχουμε τόσες πολλές αλλαγές, και ταυτόχρονα θα επιβαρύνεται ο server κάθε φορά που θα πρέπει να απαντάει σε αυτά τα polls.
Στην δεύτερη περίπτωση, ο client έχει ανοιχτή σύνδεση στον server, και αναμένει ένα message. Σε αυτή την περίπτωση, o client θα περιμένει τον περισσότερο καιρό χωρίς να λαμβάνει τίποτα, απλά καταναλώνοντας resources από τον server.
Και στις δύο περιπτώσεις, σε περιβάλλοντα που υπάρχει μεγάλος φόρτος "πραγματικής εργασίας", ο φόρτος που προσδίδεται είτε από τον client με τα συνεχή polls στον server, είτε τα resources που καταναλώνονται στον server με την συνεχή σύνδεση τους με τον client, συνεισφέρουν αρνητικά στις επιδόσεις του συστήματος.
Δεν υπάρχει "χρυσός κανόνας" για το πως θα πρέπει να υλοποιηθεί η πολιτική - είναι αυτό που είπα παραπάνω ότι όλα εξαρτιούνται από το "πόσο σωστά έχεις κάνει την εκτίμησή σου". Η αλήθεια είναι ότι το σύνηθες είναι η υλοποίηση να είναι μέρος ή/και συνδυασμός σημείων από τις δύο παραπάνω περιπτώσεις.

Η ανάπτυξη του interface είναι το επόμενο θέμα:

Αν υποθέσουμε ότι θέλουμε να δημιουργήσουμε το interface με τους design-time wizards που έρχονται με το Visual Studio, ενώ η ανάπτυξη των απαραίτητων business objects, είτε για χρήση με ASP.NET WebForms είτε για ASP.NET MVC, έχουν πολύ πιο εύκολη/straitforward ανάπτυξη, δεν είναι αντίστοιχα εύκολη η ανάπτυξη για τα WinForms/WPF.
Για το web είναι αρκετό τα business objects να έχουν decoration DataObject και οι μέθοδοι που θα χρησιμοποιηθούν από το wizard να είναι decorated με DataObjectMethod.
Τα πράγματα είναι πολύ διαφορετικά για τα WinForms και WPF Apps, πρέπει τα business objects να υλοποιούν τουλάχιστον το IBindableList interface για να μπορούν να χρησιμοποιηθούν από τους wizards. Αν θα πρέπει να υπάρξει validation στο UI, και Sorting, τότε ο κώδικας που πρέπει να γραφτεί παραπάνω είναι αρκετός.
Τα WPF Apps εκτός από το objects που προέρχονται από το IBindableList, μπορούν να χρησιμοποιήσουν και Collections που προέρχονται από το ObservableCollection<T>.
Ο σύνηθες δρόμος εδώ, είναι να μην φτιάχνονται τόσο πολύπλοκα business object. Η απουσία αυτής της υλοποίησης, αντιπαρέρχεται από υλοποίηση UI που περιέχουν κώδικα, τουλάχιστον για το data binding, αλλά πολλές φορές και για το validation.
Από τα Frameworks που θα σε βοηθήσουν να φτιάξεις δικά σου business classes για να μπορούν να κάνουν bind σε WinForm/WPF controls είναι το CSLA.NET. Δεν απαιτείται να κάνεις όλη την υλοποίηση που προτείνει το CSLA.NET για την εφαρμογή σου, αρκεί να πάρεις τις υλοποιήσεις των abstract business classes που έχει και υλοποιούν σε ένα μεγάλο βαθμό τα αναγκαία interfaces για databinding, και να τα χρησιμοποιήσεις στις business classes των εφαρμογών σου.

George J.

Απ: Composite Entities

Markos — Fri, 27 Aug 2010 07:53:47 GMT

Χμ... Ζόρικα τα πράγματα. Δεν έχω κάτσει να σκεφτώ μια τέτοια υλοποίηση μέχρι τώρα και πιστεύω πως πρόκειται για μία περίπτωση που πρέπει να απασχολήσει σοβαρά το τμήμα R&D μιας εταιρίας προτού περάσει σε production code. Αν κάποιος(-οι) το έχουν ήδη κάνει, μάλλον δεν πρόκειται να αναφέρουν το πως το πέτυχαν, μιας και πρόκειται για ένα χαρακτηριστικό που τους δίνει σοβαρό ανταγωνιστικό πλεονέκτημα στην αγορά (τρομερά ευέλικτο UI). Παρόλ' αυτά, νομίζω ότι μπορεί να υλοποιηθεί και θα προσπαθήσω να περιγράψω σε γενικές γραμμές την προσέγγιση που θεωρώ ότι είναι η σωστή.

Κατ' αρχήν, ξεχνάς την "τυπική" μεθοδολογία για το binding. Αυτό που χρειάζεσαι είναι ένα componet που θα "λειτουργεί" κάτω από το presentation (φόρμες). Όλα τα data θα φορτώνονται εκεί και, ανάλογα με τη φόρμα που ζητάει ο χρήστης, θα "φτιάχνει" το κατάλληλο view. Για παράδειγμα, ο χρήστης ζητάει τους οδηγούς. Το component θα φορτώνει τους υπαλλήλους που είναι οδηγοί, θα τους βάζει σε ένα view, θα δημιουργεί το binding και θα το περνάει στη φόρμα που θα υπάρχει το ανάλογο grid. Στη συνέχεια ο χρήστης ζητάει τους μηχανικούς (υπάλληλοι και αυτοί). Το component θα φορτώνει στο ίδιο context τους μηχανικούς, θα δημιουργεί το view και θα το "οδηγεί" στην κατάλληλη φόρμα και το αντίστοιχο grid, όπως και προηγουμένως. Στη συνέχεια, ο χρήστης ζητάει τα details για έναν οδηγό. Μέσω deffered loading το component θα φορτώνει τα details, θα δημιουργεί το κατάλληλο view και θα το "σπρώξει" στην detail φόρμα των οδηγών. Όλο το data manipulation, ο μηχανισμός binding με το datasource, η διαχείριση των events για τα property changes, το validation κ.λπ. θα γίνονται από το component, όπως και το persistence φυσικά. Οι φόρμες σου θα δώσουν στην έκφραση "χαζές" εντελώς νέο νόημα. Πράγμα λογικό, τη στιγμή που ανοίγεις πολλαπλά instances και θέλεις έναν μαέστρο να συγχρονίζει τα πάντα (το component δηλαδή). Βεβαίως και δεν πρέπει να ξεχάσεις να υλοποίησεις ένα μηχανισμό dispose, όταν δεν χρειάζεσαι πια τα δεδομένα.

Το ωραίο στο άφησα για το τέλος. Επειδή θέλεις να δουλέψεις με entities και όχι με datatables και dataviews, νομίζω ότι η υλοποίηση θα είναι πιο εύκολη σε WPF απ' ό,τι σε WinForms. Εκεί έχεις δύο πολύ δυνατά όπλα που λέγονται ObservableCollection(T) και CollectionViewSource. Βέβαια, όποιος έχει κάτι άλλο στο μυαλό του που νομίζει ότι είναι σε πιο σωστό δρόμο, περιμένω να το post-άρει μιας και θεωρώ ότι το θέμα προσφέρεται για πολλή συζήτηση.

Απ: Composite Entities

infoCENTER — Fri, 27 Aug 2010 05:43:35 GMT

Συγνώμη είχα γράψει ότι είχα γράψει προηγουμένως και αναφερόμουν στην προσέγγιση των Profiles που ανέφερε ο George J. Δεν το είχα ξανακούσει και ήθελα μία περιγραφή.

Όσο για το πρόγραμμα, ναι έχεις πιάσει ακριβώς το UI πως το θέλουν να είναι. Αλλά όχι μόνο για προσθήκες αλλά και για μεταβολές. Επίσης επειδή δεν το ανέφερες θα ήθελα να πως μία φορά ακόμα πως υπάρχουν και διαφορετικά πεδία που μπορεί να "κολλήσουν" επάνω στο ίδιο entity ανάλογα το τμήμα στο οποίο εργάζεται. Δεν ξέρω αν θα μπορούσα να το φτιάξω με DataTables, έχω να τα χρησιμοποιήσω χρόνια αλλά από ότι θυμάμαι σε ένα τέτοιο UI ίσως να είναι ακόμα πιο δύσκολη υλοποίηση αν προσθέσουμε και το Business Logic που θα πρέπει να υπάρχει. Από εκεί και πέρα αν έχεις διαφορετική άποψη και μπορείς να μου πεις την σκέψη σου θέλω να σε ακούσω.

Απ: Composite Entities

Markos — Thu, 26 Aug 2010 23:46:34 GMT

Δύο ερωτήσεις:

1) Οι απαιτήσεις είναι, α) να ανοίγεις ταυτόχρονα όσα grids θέλεις, ανάλογα με την κατηγορία των εργαζομένων που εξετάζεις, β) από το κάθε grid να μπορείς ν' ανοίγεις όσες φόρμες θέλεις με τα details για τον κάθε εργαζόμενο, γ) όλα να είναι editable και από παντού να μπορείς να κάνεις update από παντού και δ) να ενημερώνονται όλα (grids, φόρμες κ.λπ.) για τις αλλαγές που συμβαίνουν στο ίδιο entity είτε αφορούν editing είτε validation είτε persistence (μεταβολές στο entity state) κ.λπ., κ.λπ.

2) Συνήθως όταν μιλάμε για fast entry, μιλάμε για προσθήκες και όχι για μεταβολές σε υπάρχουσες εγγραφές. Το fast entry το θέλεις μόνο για additions ή δεν το κατάλαβα σωστά;

Απ: Composite Entities

infoCENTER — Thu, 26 Aug 2010 22:56:12 GMT

Ομολογώ πως δεν καταλαίνω τι θέλεις να μου πεις. Το έχασα... Οπότε αν δε σου κάνει κόπο και έχεις τον χρόνο γράψε μου σχετικά. Θα ήθελα όμως να σε πληροφορήσω πως αυτό που έχεις κατά νου θέλω να είναι Bindable και να έχει properties. Δηλαδή αν είναι κάποιο custom Hashtable (propName, Value) που χτίζεται στο Runtime δεν θα μπορώ να το κάνω Bind στο Grid για μαζική καταχώρηση.

Αν θέλεις να φέρεις το παράδειγμα στα μέτρα μου να σου περιγράψω λίγο το πρόβλημα. Μία εταιρεία έχει δύο τμήματα ή πόστα. Οδηγοί και μηχανικοί ας πούμε. Ένας υπάλληλος μπορεί να είναι και οδηγός αλλά και μηχανικός. Δηλαδή μπορεί να δουλεύει και στα δύο τμήματα ή μόνο στο ένα. Η εφαρμογή ανοίγει και ο χρήστης επιλέγει να ανοίξει το τμήμα οδηγοί οπότε εκεί εμφανίζεται ένα grid με όλους τους υπαλλήλους. Κανείς όμως δεν εμποδίζει τον χρήστη να ανοίξει και το άλλο τμήμα των μηχανικών. Οπότε αν έχουμε υπαλλήλους που να δουλέυουν και στα δύο τμήματα τότε αυτοί θα εμφανιστούν και στα δύο grid. Τώρα το κάθε τμήμα για να βγει η μισθοδοσία έχει εκτός από τα στοιχεία του υπαλλήλου τα οποία είναι κοινά σε όποιο τμήμα και να ανήκει π.χ οικογενειακή κατάσταση, αριθμός ανήλικων παιδιών κτλ υπάρχουν και κάποια άλλα πεδία τα οποία είναι συγκεκριμένα για το τμήμα στο οποίο ανήκει. Συνήθως αυτά θα ενημερώνει πιο πολύ στην μαζική καταχώρηση.

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

Μπορεί η αλλαγή αυτή να σου φαίνεται λίγο παρατραβηγμένη αλλά σε μία εταιρεία με γύρω στα 1000 προσωπικό πάντα σχεδόν κάθε μήνα κάτι θα γίνει είτε για κάποιο επίδομα ασθένειας είτε για αλλαγή τραπεζικού λογαριασμού μισθοδοσίας είτε για ότι άλλο. Δυστυχώς είναι συχνό φαινόμενο...

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

Απ: Composite Entities

Markos — Thu, 26 Aug 2010 03:34:30 GMT

Καλό το BindingList<T>, αλλά είναι τόσο λίγο!! Πρέπει να κάνεις implement τόσα interfaces για να του δώσεις λειτουργικότητα που τα datatables έχουν out of the box!! (sorting, searching, editing όταν sorted=true κλ.π.). Επίσης, μέσω των datarelations μπορείς να "επιβάλεις" referencial integrity και να χρησιμοποιήσεις keys για uniqueness. Ο Παράδεισος του UI!! Αλλά, ποιος είπε ότι πρέπει ντε και καλά να τα χρησιμοποιήσεις για να επικοινωνήσεις με τη βάση; Εγώ αναφέρθηκα σε απλό FAST data entry. Αν θέλουμε δε χρησιμοποιούμε ούτε dataadapters, ούτε tableadapters. Τα υπόλοιπα, ας τα αναλάβει το context.

Απ: Composite Entities

George J. Capnias — Thu, 26 Aug 2010 03:15:30 GMT

Markos:

Όποτε θέλω να έχω fast entry forms σε related data με μορφή πίνακα, χρησιμοποιώ datasets. Μπορεί να μην σου ακούγεται ελκυστικό, αλλά έχε το κάπου στο πίσω μέρος του μυαλού σου, αν τα πράγματα σκουρύνουν πολύ.

...

Είναι μεγάλη αλήθεια ότι τα Dataset είναι πάρα πολύ ελκυστικά για την γρήγορη δημιουργία presentation layer, λόγω των ευκολιών που παρέχουν design-time, ιδίως όταν μιλάμε για WinForms. Προσωπικά, δεν έχω κάνει υλοποίηση εφαρμογής, από την αρχή ως στο τέλος, σε WinForms, από όταν έχω ξεκινήσει να ασχολούμαι με .NET.

Παρόλα αυτά, μπορείς να φτιάξεις στο δικό σου Business Layer classes που να κάνουν την ίδια δουλειά, υλοποιώντας το BindableList<T>. Υπάρχουν άρθρα που περιγράφουν μια τέτοια διαδικασία, όπως αυτό του Paul Balard - σίγουρα θα βρεις σχετικά άρθρα του Rockford Lhotka, που το όνομά του είναι "κόκκινο πανί" για ορισμένος μέσα στο forum.

George J.

Απ: Composite Entities

George J. Capnias — Thu, 26 Aug 2010 02:56:43 GMT

infoCENTER:
Θα ήθελα να μου δώσεις παραπάνω πληροφορίες για τα profiles σε παρακαλώ. Αν μπορείς επίσης θα ήθελα να μου υποδείξεις και κάποιο site που να περιγράφει την προσέγγιση που περιγράφεις.

Tα profiles δεν είναι κάποιο αρχιτεκτονικό pattern, ή το profile του membership που περιέχει το .NET Framework - τον όρο profile τον χρησιμοποίησα για να καταλάβεις ότι κάθε κομμάτι έχει ξεχωριστά δεδομένα, σε σχέση με το βασικό σου entity, employee. Ουσιαστικά είναι de-normalization ενός πίνακα που θα είχε τα δεδομένα του employee σε συνδιασμό με τα δεδομένα που απαιτούνται για κάθε κομμάτι της εφαρμογής. Τουτέστιν να σπάσεις ένα πίνακα με πολλές στήλες σε πολλούς, που έχουν σχέση 1-1 με τον αρχικό (employee).

Δεν ξέρω αν καταλαβαίνεις τι ακριβώς περιγράφω. Πες μου αν δεν είναι κατανοητό σε εσένα...

George J.

Απ: Composite Entities

Markos — Thu, 26 Aug 2010 02:11:16 GMT

Όποτε θέλω να έχω fast entry forms σε related data με μορφή πίνακα, χρησιμοποιώ datasets. Μπορεί να μην σου ακούγεται ελκυστικό, αλλά έχε το κάπου στο πίσω μέρος του μυαλού σου, αν τα πράγματα σκουρύνουν πολύ.

Όσον αφορά τα composite entities, αφού θέλεις να μετατρέψεις μία σχέση "is a" σε "has a", έχε μόνο ένα Employee entity, στο οποίο θα κρατάς τα κοινά στοιχεία όλων των υπαλλήλων, και δημούργησε Activities. Π.χ. ο οδηγός είναι Employee με Activity "Driver". Όλα τα Activities θα πρέπει να κληρονομούν από ένα BaseActivity για να μπορείς να τα διαχειριστείς σε ένα collection μέσα στο κάθε Employee object. Βεβαίως, πρέπει να προνοήσεις ώστε να υπάρχουν μέθοδοι για το loading, adding, deleting κ.λπ. των activities ενός Employee, για να ελέγχεις τα relationships. Τέλος, για να μπορέσεις να ανοίγεις πολλαπλές φόρμες με το ίδιο entity, θα πρέπει να δημιουργήσεις κάποιο "ενδιάμεσο presenter entity" που θα περικλείει το entity, ένα bindingsource για τα properties του Employee και από ένα bindingsource για κάθε activity. Δηλαδή, δεν θα κάνεις το binding του object απ' ευθείας σε control ή σε φόρμα, αλλά όλα τα instances των controls ή των φορμών που θα αφορούν στο ίδιο object, θα κάνουν binding με τα bindingsources του κοινού presenter entity. Δεν το έχω δοκιμάσει, just a thought...

Απ: Composite Entities

infoCENTER — Thu, 26 Aug 2010 01:50:28 GMT

Θα ήθελα να μου δώσεις παραπάνω πληροφορίες για τα profiles σε παρακαλώ. Αν μπορείς επίσης θα ήθελα να μου υποδείξεις και κάποιο site που να περιγράφει την προσέγγιση που περιγράφεις.