Το πράγμα έχει ώς εξείς:

Το project μου έχει γίνει τεράστιο."150"(τρόπος του λέγειν) κλάσεις κάτω από το ίδιο assembly.

Θέλω λοιπόν να σπάσω το project και να το κάνω dlls.Όχι όλες τις κλάσεις αλλά κάποιες οι οποίες περιέχουν βασικές συναρτήσεις καθώς και controls.

Το πρόβλημα είναι το εξής: Η κλάση πχ Foo1 που θέλω να γίνει dll, μέσα στις συναρτήσεις της καλεί συναρτήσεις της Foo2, η οποία επίσης καλεί συναρτήσεις της Foo1(και γενικά είναι ένα μικρό μπέρδεμα).

Το πρόβλημα λοιπόν είναι ότι για να κάνω Compile το Foo1.dll πρέπει να έχω το Foo2.dll το οποίο για να το κάνω compile θέλω το Foo1.dll.......

Καμοιά ιδέα πλήν του να αρχίσω να ξεσκαρτάρω τις συναρτήσεις και τις δομές?

Μήπως να μας δώσεις ένα παράδειγμα του τι κάνει η Foo1 και η Foo2;

---

Χρήστος Γεωργακόπουλος

Λοιπόν.
Η Foo1 έχει public static πεδία και συναρτήσεις που κάνουν τα πάντα.
Η Foo2 έχει public static πεδία και συναρτήσεις καθώς και κλάσεις σχετικά με την βάση δεδομένων και μόνο.

Από ότι καταλαβαίνεις η Foo1 έχει συναρτήσεις που χρησιμοποιούν την Foo2 και η Foo2 έχει μπόλικες κλήσεις από αρκετές καλές συναρτήσεις που υπάρχουν στην Foo1.

Άρα η Foo1 δεν έχει ιδέα από βάση, ή γενικά από που έρχονται τα δεδομένα. Ξεκίνα χωρίζοντας τα "πάντα" της Foo1 σε namespaces, πχ, αν έχεις μεθόδους που κάνουν string handling, βάλε τις σε ένα namespace με όνομα Strings κ.ο.κ. Τα namespaces είναι ένα πρώτο βήμα για να δεις πως τελικά θα τα χωρήσεις.

Για την Foo2, ψάξε αν υπάρχει κώδικας που είναι ανεξάρτητος από τη δική σου βάση και μπορεί να χρησιμοποιηθεί σε οποιαδήποτε βάση. Όλες αυτές τις απολύτως generic ρουτίνες βάλε τις μόνες τους. Αν τα υπόλοιπα είναι αρκετά, χώρισέ τα ανάλογα με το είδος των δεδομένων που χειρίζονται. Εδώ δεν μπορώ να σου προτείνω κάτι, δεν ξέρω με τι είδους δεδομένα (το business meaning εννοώ) έχεις να κάνεις.

Μία πρακτική που ακολουθώ, είναι να χωρίζω αντίστοιχο κώδικα στα 3:

1. Ένα project έχει μόνο τους τύπους των δεδομένων, πχ datasets ή business objects
2. ένα project χειρίζεται το data access, δηλαδή διαβάζει δεδομένα από τη βάση και γεμίζει τα αντικείμενά μου, ή παίρνει δεδομένα από τα αντικείμενα και τα βάζει στη βάση
3. το τρίτο project έχει business logic, δηλαδή παίρνει έτοιμα αντικείμενα, γεμάτα με δεδομένα και τα επεξεργάζεται. Αυτό το project δεν ξέρει τίποτα για τη βάση, τα δεδομένα έρχονται έτοιμα χωρίς να ξέρει από που προήλθαν.

Βέβαια ο χωρισμός εξαρτάται και από το είδος των αντικειμένων που χρησιμοποιείς. Αν χρησιμοποιείς πχ κάποιον O/R mapper που βάζει μέσα στα ίδια τα business objects των κώδικα για να γεμίζουν με data από τη βάση, τότε το 1 και το 2 είναι στην ουσία ένα project.

Δώσε μου περισσότερα στοιχεία αν θέλεις μήπως μου έρθει κάποια άλλη ιδέα...

---

Χρήστος Γεωργακόπουλος

Μιά άλλη πολιτική (δεν υπάρχει "σωστή" επιλογή) είναι να βάζεις αυτά που χρησιμοποιούνται σπάνια σε ξεχωριστό dll, ώστε να μην φορτώνεται τζάμπα. Σηκώνει και σαλαμοποίηση σε περισσότερα του ενός.

Σε περίπτωση που παίζεις με remoting ή classes που φορτώνεις δυναμικά (βάσει configuration), τότε τα interfaces πάνε μόνα τους. Στην πρώτη περίπτωση για να μην έχει ανάγκη ο client το πλήρες implementation του server. Στην δεύτερη, διευκολύνει το "σπάσιμο" της ανάπτυξης.

Άρης

---

Aris

Παιδιά το εγκατέλειψα το εγχείρημα. Ήταν πολλά τα "cross-dependances" και δεν έχω τον χρόνο να ασχοληθώ ήθελε πολύ ξεσκαρτάρισμα. Άσε που ακόμα και να το κατάφερνα θα έπρεπε να περάσουν μέρες test για να δώ αν εξακολουθεί να δουλεύει σωστά.
Η κάνεις κάτι σωστά από την αρχή ή ....
Ευχαριστώ πάντως για τις απαντήσεις.