Γεια χαρα σε όλους.

Αντιμετωπίζω ένα πρόβλημα το οποίο είμαι σίγουρος πως λύνεται πολύ εύκολα, αλλά ακόμα δεν έχω βρεί την λύση.

Αναπτύσσω εδώ και αρκετό καιρό μια web εφαρμογή σε ASP.NET 1.1, η οποία με έχει εξυπηρετήσει αρκετά καλά. Ξεκίνησε σαν ένα μικρού μεγέθους solution και σιγά-σιγά γιγαντώθηκε (ως συνήθως). Το θέμα είναι οτι το solution άρχισε μονολιθικά ("one dll to rule them all"), και συνέχισε έτσι εως σήμερα, με αποτέλεσμα να έχει φτάσει το κύριο dll τα 900-950K σε μέγεθος και να γίνει πλέον επιτακτική η διάσπαση της εφαρμογής σε ένα multi-tier (ουσιαστικά multi-project) σχέδιο. Οπότε, δημιουργώ μερικά δευτερεύοντα projects και διανέμω τον κώδικα σε αυτά, ώστε να δημιουργήσω assemblies που θα χρησιμοποιήσω από το κύριο project.

Εδώ βρίσκεται και το πρόβλημα. Καθώς τοποθετώ τα κομμάτια του κώδικα σε ξεχωριστά projects, αρχίζουν (φυσικά) να γκρινιάζουν οτι τους λείπουν διάφορες application & session-scope μεταβλητές τις οποίες εως τώρα έβλεπαν μια χαρά. Το πρώτο που σκέφτηκα ήταν να αλλάξω όλα τα functions στα δευτερεύοντα projects ώστε να παίρνουν σαν παραμέτρους τις μεταβλητές που εως τώρα απλά άρπαζαν από τη μνήμη (π.χ. τα DB connection strings). Αυτό όμως απαιτεί αρκετή δουλειά και δεν μπορώ να πιστέψω ότι δεν υπάρχει πιο απλός τρόπος. Δοκίμασα να κάνω reference to πρωτεύον project από τα δευτερέυοντα μπας και δω τις μεταβλητές ετσι, αλλα το VS γκρίνιαξε για circular reference (σωστά, αφού είχα κάνει ήδη reference τα δευτερεύοντα projects από το πρωτεύον).

Είμαι σίγουρος οτι υπάρχει μια πολύ απλή λύση σε αυτό το πρόβλημα, αλλά δεν την έχω βρεί ακόμα. Ιδέες/προτάσεις από μυαλά πιο έμπειρα στο συγκεκριμένο θέμα ευπρόσδεκτες.

Θέμα λογικής διάρθρωσης είναι...

Δεν λύνεται με καμία συνταγή εκτός (ίσως) από την ακόλουθη:

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

Δηλαδή στην περίπτωσή σου: αν το γενικότερο "φυλάσει" μια παράμετρο σε ένα Session variable, το ειδικότερο δεν πρέπει να το γνωρίζει αυτό και δεν πρέπει (παρά το γεγονός ότι έχει πρόσβαση στα Session variables) να πηγαίνει κατευθείαν στο Session (με Session["something"]) και να πάιρνει την τιμή. Αντίθετα το γενικότερο θα πρέπει να διαθέτει ένα public μηχανισμό (property ή method) τον οποίο θα χρησιμοποιεί το ειδικότερο για να πάρει τα δεδομένα που θέλει.

Η πρακτική να τα διαβάζεις όλα από κάποιου είδους κοινά publicly available resources (μεταβλητές) δεν είναι καλή και ειδικά αν αυτά τα resources είναι τα Application ή τα Session variables...

Σαν βοηθητική τεχνική σου προτείνω να εξαφανίζεις μία μία όλες τις application & session scope μεταβλητές σου μέσα σε classes και να διορθωνεις ένα ένα τα compile time errors. (Ελπίζω να τις έχεις μέσα σε Properties ή Methods και να μην τις χρησιμοποιείες παντού με Appliction["xxx"] ή Session["xxx"] κλήσεις γιατί θα δυσκολευτείς πολύ).

Μην θεωρείς τίποτα δεδομένο εκτός από τα πράγματα που μπορεί να ελέγξει ο compiler.

Π.χ.ο compiler δεν μπορεί να ελέγξει τίποτε για την έφραση Session["blahblah"] και (ειδικά αν υπάρχει αυτούσια 10 φορές σε διάφορα σημεία του κώδικά σου. Αν όμως αντί για Session["blahblah"] έχεις δώσει κάτι σαν MyClass.Blahblah, (όπου MyClass.Blahblah είναι κάποιο property του στύλ: class MyClass { public object Blahblah { get { return Session["blahblah"]; } } }), τότε μόλις αλλάξει assembly το MyClass ο compiler θα σου βρεί όλα τα σημεία που πρέπει να διορθώσεις (τα οποία είναι και τα πιθανά σημεία λάθους που τώρα αναζητάς με trial&error).

good luck
rousso

υ/γ: Προσεκτικά μόνο στα μεγάλα restructures μη γίνει κανένα κακό. Ελπίζω να το το έχεις σε source control.

 

---

rousso

Ευχαριστώ για την απάντηση. Έπρεπε να διευκρινίσω οτι δεν χρησιμοποιώ σχεδόν καθόλου τα Session & Application objects για τον λόγο ακριβώς που επισημαίνεις. Απλά έχω κάποια συγκεκριμένα classes με τις πληροφορίες που χρειάζομαι (profile, app settings etc.) και τα κάvω instantiate στα Application_Start & Session_start events.

Από την έρευνα που έκανα, βρήκα 2 κύριες κατευθύνσεις για την αντιμετώπιση του μονολιθικού προβλήματος:

1) Ένα project, πολλαπλά DLLs:
http://www.chez.com/scribe/en/asp.net/184.htm
http://www.codeproject.com/aspnet/VSMaker.asp

2) Ένα application, πολλαπλά projects:
http://www.kbalertz.com/kb_Q307467.aspx#XSLTH3139121122120121120120
http://www.codeproject.com/aspnet/sepmultweb.asp

Η δεύτερη λύση μάλλον εξυπηρετεί τις ανάγκες μου καλύτερα. Το ιδανικό θα ήταν να μπορέσω να τοποθετήσω τα shared data & functions σε ένα ξεχωριστό "core" class library το οποίο θα γίνει referenced τόσο από τα "satellite" projects όσο και από το κύριο project. Με αυτό τον τρόπο θα λυνόταν και το ζήτημα του circular reference.

Εν πάσει περιπτώσει, ευχαριστώ για την άμεση απάντηση!