Είμαι στην αρχή της ανάπτυξης μία εφαρμογής και από αυτά που μου έχουν περιγράψει και το πως θα ήθελαν την εφαρμογή, μετά από σκέψη κατέληξα στο γεγονός πως ίσως, μάλλον, χρειάζομαι να χρησιμοποιήσω composite entities. Μία αναζήτηση όμως στο Google δεν μου έβγαλε κάτι σχετικό. Guidelines, Patterns, προβλήματα που μπορεί να προκύψουν ή οτιδήποτε. Αποφάσισα λοιπόν να γράψω κάτι εδώ, μήπως και κάποιος από εδώ έχει ασχοληθεί σχετικά ή έχει δει κάτι.

Ο όρος Composite Entities δεν ξέρω αν υπάρχει απλά δανείστηκα την λέξη composite από τα διάφορα UI Frameworks που υπάρχουν. Τι εννοώ λοιπόν με τον όρο αυτό. Στην εφαρμογή μου έχω κάποια entities/objects. Αυτά συνήθως από μόνα τους περιγράφουν μία οντότητα. Υπάρχουν λοιπόν περιπτώσεις όπου αν βάλουμε δύο μαζί να περιγράφουν κάτι άλλο. Ένα παράδειγμα θα βοηθήσει να καταλάβετε τι εννοώ και για πιο λόγω το inheritance δεν είναι η λύση του προβλήματος.

Ας υποθέσουμε ότι θέλω να σχεδιάσω μία εφαρμογή η οποία να κρατάει πληροφορίες για τους υπαλλήλους της. Οπότε θα φτιάξουμε μία οντότητα Employee η οποία θα έχει τα στοιχεία του κάθε ατόμου. Τα άτομα αυτά δουλεύουν σε κάποια τμήματα της εταιρείας όπου το κάθε τμήμα έχει τα δικά του χαρακτηριστικά. Παράδειγμα υπάλληλος αποθήκης, υπάλληλος λογιστηρίου, εξωτερικός υπάλληλος, οδηγός κτλ όπου ανάλογα με την θέση στην οποία δουλεύει ο κάθε υπάλληλος θα θέλαμε να κρατάμε και κάποια έξτρα στοιχεία. Αν είναι οδηγός το δίπλωμα, ή διπλώματα, και γενικά ότι χρειάζεται το κάθε τμήμα και η εταιρεία να κρατάει. Οπότε κάποιος στο σημείο αυτό μπορεί να πει ότι π.χ για την περίπτωση του οδηγού θα κάνω Inherit το employee και θα ονομάσω το νέο object σε driver, το αντίστοιχο και για τα υπόλοιπα τμήματα. Δεν διαφωνώ αρχικά με την σκέψη αυτή. Το UI είναι αυτό που το χαλάει.

Λόγω σχεδίασης που αυτό θα έχει, θα πρέπει μία αλλαγή που θα γίνεται σε κάποιο πεδίο ενός object αυτόματα να ενημερώνονται και όλα τα άλλα objects που αναφέρονται στο entity αυτό. Δηλαδή αν έχω μία λίστα σε Grid τους υπαλλήλους και ανοίξω έναν υπάλληλο σε κάποια φόρμα η αλλαγή που θα κάνω στον υπάλληλο να εμφανιστεί και στο Grid. Αυτό με Binding λύνεται πολύ εύκολα. Το πρόβλημα τώρα. Ανοίγω ένα υπάλληλο σε φόρμα και στην συνέχεια μέσα από την εφαρμογή ανοίγω τον ίδιο υπάλληλο σαν οδηγό όμως αυτή την φορά, οπότε έχω δύο φόρμες ανοικτές που αναφέρονται στο ίδιο άτομο. Αν ακολουθήσω την λογική του Inheritance τότε μιλάμε για δύο διαφορετικά Instances το Employee & Driver οπότε μία αλλαγή π.χ στον αριθμό ταυτότητας του Employee δεν θα αλλάξει στην φόρμα του Driver του ίδιου ατόμου. Οπότε στο σημείο αυτό κατάλαβα ότι το inheritance ίσως δεν είναι αυτό που θέλω και έφτασα στην λογική των composite objects. Όπου έχω ένα object employee ένα object DriverDetails και όταν τα βάλω αυτά τα δύο μαζί να έχω ένα DriverEntity. Παρακάτω παρουσιάζω πως το κάνω αυτό.

Public Class Driver
   Private _Employee as Employee
   Private _DriverDetails as DriverDetails

   Public Sub New
      _Employee=New Employee
      _DriverDetails=New DriverDetails
   End Sub

   Property Employee as Employee
      Get
      Set
   End Property

   Property DriverDetails as DriverDetails
      Get
      Set
   End Property
End Class

Οπότε έτσι αν πάω να ανοίξω ένα οδηγό για τον οποίο η οντότητα υπάλληλος έχει ήδη φορτωθεί στην εφαρμογή πέρνω το συγκεκριμένο Instance από μία συγκεκριμένη περιοχή της εφαρμογής και την περνάω στο Property Employee Του Driver. 

Όπως είπα έψαξα στο Google για κάτι ανάλογο αλλά δεν βρήκα κάποια guidelines ή κάτι σχετικό που να με βάλει σε έναν δρόμο και να μου πει τι προβλήματα μπορεί να συναντήσω στην πορεία. Έχει κανείς να μου προτείνει να διαβάσω κάτι σχετικό ή να μου πει;

Ευχαριστώ.

Υστ: Ουφφφ τελείωσα.   

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

Το πρόβλημα το μεγάλο είναι στο κομμάτι της μισθοδοσίας και για αυτό το θέλουν έτσι. Από τα πακέτα που έχω δει έξω στην αγορά αν θέλεις να βγάλεις μισθοδοσία ανοίγεις την εταιρεία, πας στους υπαλλήλους και ανοίγεις ένα ένα κάθε υπάλληλο και περνάς τα μεροκάματα τα επιδόματα κτλ. Η εταιρεία όμως αυτή έχει γύρω στους 1000 υπαλλήλους και με τίποτα δεν ήθελαν ένα τέτοιο UI. Αυτό που θέλουν να κάνουν είναι να επιλέγουν τμήμα, η εφαρμογή να τους βγάζει τους υπαλλήλους του τμήματος σε grid και επάνω στο grid να ενημερώνουν τα μεροκάματα τα επιδόματα και ότι άλλο θέλουν. Είναι πιο γρήγορη η ενημέρωση έτσι. Οπότε όπως καταλαβαίνεις υπάρχει περίπτωση δύο υπάλληλοι να δουλεύουν σε διαφορετικό τμήμα, και τα τμήματα αυτά να μοιράζονται μερικούς υπαλλήλους. Από εκεί και πέρα μπορεί ένας χρήστης να θέλει να ανοίξει ένα υπάλληλο στην δική του ξεχωριστεί φόρμα για να δει κάποιες παραπάνω πληροφορίες ή να ενημερώσει κάτι. Όσοι έχουν ασχοληθεί με εφαρμογές μισθοδοσίας ή γνωρίζουν σχετικά νομίζω είναι σε θέση να καταλάβουν πιο εύκολα τι θέλουν να κάνουν οι άνθρωποι.

Η επιλογή του τμήματος στην μισθοδοσία είναι μεγάλο θέμα, γιατί κάθε τμήμα της εταιρείας μπορεί να αντιπροσωπεύει διαφορετική σύμβαση, επιδόματα, κτλ οπότε και τα πεδία που θα πρέπει να συμπληρώνονται είναι διαφορετικά για κάθε τμήμα. Οπότε λέω να συνδέσω και ένα Composite με κάθε τμήμα αφού το κάθε τμήμα έχει διαφορετικά πεδία από ένα άλλο σε κάποιο ποσοστό και να γεμίζω το grid με τα composite. Ευτυχώς τα τμήματα είναι συγκεκριμένα και δεν έχουν αλλάξει εδώ και 20 χρόνια από ότι μου έχουν πει. Αλλά και αν προστεθεί ένα δέχονται να μου πουν τα χαρακτηριστικά του και τι πεδία χρειάζεται να ενημέρωνουν ώστε να τους φτιάξω νέα έκδοση.

Έψαξα λοιπόν στο Google για να δω αν έχει ασχοληθεί και κάποιος άλλος με την λογική των composit entities και δεν βρήκα κάτι. Δεν ξέρω και αν η ορολογία είναι σωστή για να ψάξω.

Έχω την εντύπωση ότι το UI γίνεται πολύπλοκο γιατί κάνεις πολύπλοκα τα entities - όχι πολυπλοκότητα σε επίπεδο business, αλλά πολυπλοκότητα σε θέμα υλοποίησης.

Δική μου άποψη θα ήταν να έχεις απλά employees, που θα έχουν/ή δεν θα έχουν profiles για κάθε κομμάτι της εφαρμογής. Κάθε profile, για ένα συγκεκριμένο κομμάτι της εφαρμογής, μπορεί να είναι κοινό για όλους τους χρήστες ή και ξεχωριστό για τον καθένα - εδώ το IoC μπορεί να σου λύσει πολλά προβλήματα και να σε κάνει να "καλπάσεις"...

George J.

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Όποτε θέλω να έχω 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...

infoCENTER:

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

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

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

George J.

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

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.

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

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

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

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

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

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

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

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

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

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

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

Χμ... Ζόρικα τα πράγματα. Δεν έχω κάτσει να σκεφτώ μια τέτοια υλοποίηση μέχρι τώρα και πιστεύω πως πρόκειται για μία περίπτωση που πρέπει να απασχολήσει σοβαρά το τμήμα 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-άρει μιας και θεωρώ ότι το θέμα προσφέρεται για πολλή συζήτηση.

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, συνεισφέρουν αρνητικά στις επιδόσεις του συστήματος.
• Δεν υπάρχει "χρυσός κανόνας" για το πως θα πρέπει να υλοποιηθεί η πολιτική - είναι αυτό που είπα παραπάνω ότι όλα εξαρτιούνται από το "πόσο σωστά έχεις κάνει την εκτίμησή σου". Η αλήθεια είναι ότι το σύνηθες είναι η υλοποίηση να είναι μέρος ή/και συνδυασμός σημείων από τις δύο παραπάνω περιπτώσεις.