Να σας πω κι εγώ την εμπειρία μου, καθότι τον τελευταίο καιρό δουλεύω συνέχεια με services. Καταρχήν, αν περάσεις τις παραμέτρους σαν arguments θα πρέπει να κάνεις προσεκτικό parsing για να πιάσεις τυχόν λάθη του χρήστη. Καθώς τα services δεν μπορούν να εμφανίσουν μηνύματα λάθους, τα μηνύματα θα πρέπει να τα γράψεις στο event log για να τα δει και ο χρήστης. Χρησιμοποιώντας το app.config μειώνονται αρκετά οι πιθανότητες να κάνει λάθος ο χρήστης αν και θέλει λίγο παραπάνω φασαρία για να βρει το αρχείο και να το κάνει edit.
Γενικά πάντως, δεν έχει πλάκα να βάζεις settings είτε σαν arguments είτε στο app.config! Λάθη θα γίνουν και στις δύο περιπτώσεις, ενώ ο χρήστης που δεν έχει μεγάλη ιδέα από το service σου και τις παραμέτρους που έχεις ορίσει, θα δυσκολεύεται να κάνει αλλαγές. Το καλύτερο θα είναι κάπου να φτιάξεις ένα UI για να θέτεις τις παραμέτρους, είτε σαν ανεξάρτητο utility, είτε ενσωματώνοντας το στην εφαρμογή σου. Θέλει λίγη δουλειά παραπάνω, αλλά θα γλυτώσεις αρκετή γκρίνια και ψάξιμο του τί συνέβει και δεν δουλεύει το service!
Όσον αφορά το logging τώρα, μπορείς να χρησιμοποιήσεις τους ενσωματωμένους Trace Listeners για να γράψεις ταυτόχρονα στο event log, σε log αρχεία ή αλλού. Γενικά, την χρειάζεσαι αυτή τη δυνατότητα, καθώς στα αρχεία μπορείς να γράψεις πολύ περισσότερα στοιχεία απ' ότι στο event log. Αν γράψεις π.χ. ένα ολόκληρο exception message στο event log, μαζί με το call stack του, ο χρήστης θα τρομάξει. Άσε που περιοδικά μπορεί να σβήνει το event log και να χάσεις έτσι χρήσιμα μηνύματα.
Εδώ είναι που έχω βρει το Enterprise Library σωτήριο, καθώς μου επιτρέπει να ορίζω το που θα αποθηκευθεί ποιό μήνυμα από το app.config αντί για τον κώδικα μου. Γλύτωσα πολύ, μα πάρα πολύ επαναλαμβανόμενο κώδικα με αυτό τον τρόπο, απλά χρησιμοποιώντας τα Exception και Logging Application Blocks του Enterprise Library. Χρησιμοποιώ .NET 2.0 και το αντίστοιχο Enterprise Library το οποίο μου δίνει event log, flat file, database, email και MSMQ listeners, οι οποίοι μου φάνηκαν όλοι χρήσιμοι σε διάφορες φάσεις. Π.χ. ο email listener θα στείλει ένα κρίσιμο μήνυμα στον admin ότι έπεσε π.χ. το service. Επειδή όμως η διαδικασία αποστολής ενός email μπορεί να πάρει πάνω από 10 sec, χρησιμοποιώ τον MSMQ listener για να στείλω το email ασύγχρονα. Και το ωραίο είναι, ότι όλα αυτά στήνονται χωρίς εγώ να γράψω παρά μία εντολή Logger.Write! Όλα τα άλλα τα ορίζω στο app.config!
Ένα πολύ σημαντικό σημείο τέλος έχει να κάνει με τα μηνύματα που γράφεις στα Log. Πρέπει να ξεχωρίσεις μεταξύ των exceptions και των admin μηνυμάτων. Ο χρήστης του service σου δεν θα καταλάβει τί σημαίνει ένα exception message. Θα πρέπει να στείλεις μηνύματα τα οποία καταλαβαίνει αυτός, τα οποία θα έχουν νόημα για τη δουλειά του. Π.χ. "το service ξεκίνησε", "το service σταματάει λόγω λάθους", "εκτελέστηκε η συναλλαγή χψω", ή "Η συναλλαγή χψω απέτυχε λόγω υπέρβασης ορίου". Είναι επίσης σημαντικό να γράφεις μηνύματα για τη δραστηριότητα του service, π.χ. "παρελήφθει νέα συναλλαγή", "η συναλλαγή ολοκληρώθηκε". Ο λόγος είναι ότι αν πάει κάτι στραβά, αυτά τα μηνύματα είναι τα μόνα που θα έχει στη διάθεση του ο χρήστης για να καταλάβει ότι κάτι πήγε λάθος και να το διορθώσει, ή να σε καλέσει να το διορθώσεις.
Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos