Εχω μια Βαση Δεδομένων σε MS-SQLSERVER 2008 R2 με περίπου 80 πίνακες. Σκεφτομαι να χρησιμοποίησω το EF για να παραγω το αντιστοιχο Entity Model της βάσης μου, ώστε όλο αυτό το Data Access Layer να ενταχθεί ακολούθως σε ένα dll.
Το ερώτημά μου είναι εάν θα ήταν προτιμότερο για καλύτερο performance να εχω διαφορα Entities Models που θα περιλαμβάνουν ορισμένους πίνακες από την Βάση (σύμφωνα με τις βασικές εργασίες που θα εκτελώ) και όχι ένα Entity Model με όλους τους 80 πίνακες.
Φαντάζομαι στην δευτερη περίπτωση που θα έχω μονο ενα Model με όλα τα αντιστοιχα objects, οταν θα δηλώνω instances αυτού ίσως δημιουργείται κάποια υποβάθμιση στο performance του application.

Καλύτερα να έχεις πολλαπλά entity models οργανωμένα με κάποια λογική. Πχ αν ένα set από operations έχει να κάνει με πελάτες για παραγγελίες, βάλε τους ανάλογους πίνακες. Αν έχεις ένα μεγάλο entity model τότε θα έχεις διάφορα overheads όπως πχ όταν ανοίγει λόγω του μεγέθους των metadata που θα φορτώνει. Επιπρόσθετα, θα δυσκολεύεσαι να δουλέψεις στον designer γιατί θα είναι γεμάτος entities. Όπως και να έχει, σε ένα dll μπορείς να έχεις πολλαπλά entity models και να χρησιμοποιείς αυτό που χρειάζεσαι ανά περίσταση. Ωστόσο είναι λίγο δύσκολο και χρειάζεται μεγάλη προσοχή αν αποφασίσεις να δουλέψεις *ταυτόχρονα* με δύο ή παραπάνω entity models. Γι αυτό θα πρέπει να κάνεις προσεκτικό σχεδιασμό...

 

---

Vir prudens non contra ventum mingit

θα συμφωνήσω με τον Μάνο.Δεν μπορείς να τα διαχειριστείς 80 entities στον designer...

Αν η βάση σου είναι "χωρισμένη" σε schemas μπορείς να δημιουργήσεις entity data models per schema (Person, Sales). Βέβαια πρέπει να δεις μήπως θέλεις να κάνεις LΙNQ queries (joins) σε undelying tables που είναι σε διαφορετικά Entity Data Models ..Ίσως λοιπόν αντί για per schema - entity data models να κάνεις related tables - entity data models.

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Είναι εντελώς λάθος να συζητά κανείς για "βάση χωρισμένη", ή ακόμα και για βάση, όταν μιλάει για Entity Data Models. Σκοπός των Entity Data Models είναι να κρύψουν αν είναι δυνατόν εντελώς ότι υπάρχει βάση και να αφήσουν τον προγραμματιστή και την εφαρμογή να δουλέψει με αντικείμενα. Ένα Entity Model πρέπει να μπορεί να εξυπηρετήσει ένα ή περισσότερα use cases χωρίς να περιλαμβάνει "περιττές" κλάσεις. Πέρα από το "θόρυβο", οι περιττές κλάσεις δημιουργούν και overhead όταν χρησιμοποιείς ένα μοντέλο για πρώτη φορά. Επιπλέον, είναι πολύ πιθανότερο να κάνεις λάθη και να φορτώσεις περιττά αντικείμενα αν το μοντέλο είναι μεγάλο.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Σε περίπτωση που δημιουργήσω στο ιδιο DLL πολλαπλά Entity Models με βάση τα κύρια Operations  που θέλω να υλοποιησω, τοτε εάν σε δυο Entities έχω χρησιμοποιήσει τον ίδιο πίνακα (και άρα παράγεται η ίδια class) στο compile  βγάζει σφάλμα.
Στην περίπτωση αυτή χρειάστηκε να βάλω τα Entities Models σε διαφορετικούς φακέλους μέσα στο dll ώστε να μην εξάγει error η εφαρμογή στο compilation. Υπάρχει κάποια άλλη πιο βέλτιστη πολιτική για την αντιμετώπιση του προβλήματος αυτού, από το να δημιουργώ όλα αυτά τα folders μέσα στο Project?

Απ' όσο ξέρω, δεν υπάρχει ικανοποιητική απάντηση στο ερώτημά σου. Βεβαίως και στο compilation θα σου βγάλει σφάλμα, μιας και έχεις δύο κλάσεις με το ίδιο όνομα, στο ίδιο namespace. Με τα διαφορετικά folders επιχειρείς να δώσεις μία λύση σε ένα πρόβλημα που (πάντα κατά τη γνώμη μου) δεν είναι εύκολο να αντιμετωπιστεί.

Ουσιαστικά, έχεις να κάνεις με τρία mappings. Αντιγράφω από το documentation:

• Storage Model Content (edmx:StorageModels): This section describes the target database schema and is written in storage schema definition language (SSDL). For more information, see SSDL Specification and EntityContainer Element (SSDL).

• Conceptual Model Content (edmx:ConceptualModels): This section defines the entity types, complex types, associations, entity containers, entity sets, and association sets in the application domain. This section is written in conceptual storage definition language (CSDL). For more information, see CSDL Specification and EntityContainer Element (CSDL).

• Mapping Content (edmx:Mappings): This section describes the mapping between the conceptual model and the target database, and is written in mapping specification language (MSL). For more information, see MSL Specification.

Δύο άρθρα που αγγίζουν το πρόβλημα είναι τα:

1. Working With Large Models In Entity Framework – Part 1, και η συνέχειά του...
2. Working With Large Models In Entity Framework – Part 2

Το "ζουμί" βρίσκεται στο δεύτερο άρθρο, όπου οι προτεινόμενες λύσεις είναι δύο:

• Multiple CSDL files( Models) while sharing MSL and SSDL
• Divide application schemas into different sets of CSDL, MSL and SSDL files

Το "πως" γίνεται το implementation στις δύο αυτές προσεγγίσεις περιγράφεται στο άρθρο. Η πρώτη, αν και δελεαστική και ίσως η πιο "προφανής", δε σου λύνει το πρόβλημα του performance. Επίσης, δεν έχεις intellisense και δεν αποφεύγεις το πρόβλημα με το namespace. Για μένα, όντας τεμπελάκος, και οι δύο προσεγγίσεις είναι "μπελαλίδικες". Τα ORMs πρέπει να είναι πιο απλά.

Με βάση αυτά που διαβάζω, το πρόβλημα παραμένει και στην επόμενη έκδοση του framework και του Visual Studio. Μπορείς να έχεις multiple diagrams, αλλά αυτό εξυπηρετεί την καλύτερη οπτική οργάνωση των entities, χωρίς ουσιαστικά να λύνει το πρόβλημά σου. Πάντως, υπάρχει η δυνατότητα να διαχωρίσεις το diagram information από το edmx file.

---

Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!

Τελικά με τις κατάλληλες αλλαγές (στο κάθε EM και διαφορετικό) στο Namespace & στο assembly: EdmRelationshipAttribute καταφερα να έχω περισσότερα από ένα Entity Models στο ίδιο DLL που χρησιμοποιούν κοινούς πίνακες από την βάση χωρίς να χτυπάει το application κατα την φάση του compilation.

Και με τα navigation properties τι έκανες;

---

Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!

Markos:

Και με τα navigation properties τι έκανες;

Μάλλον αυτά βρίσκονται στο assembly: EdmRelationshipAttribute όπου και εκεί εκανα αλλαγή στο namespace.
Προς το παρόν χρησιμοποιώ ήδη 3 Entities Models στο ίδιο dll που έχουν κοινούς πίνακες από την βάση και ευτυχως δεν έχει προκύψει κάποιο πρόβλημα στην υλοποίηση.

Ένα πιθανό θέμα που μπορεί να προκύψει με αυτή την υλοποίηση είναι αν για κάποιο λόγο προσπαθήσεις να χρησιμοποιήσεις τον ίδιο πίνακα από δυο διαφορετικά Entity Models. Σίγουρα θα προκύψει ένα θέμα απόδοσης και ανάλογα με το πως γίνονται τα κλειδώματα στους πίνακες δεν ξέρω αν υπάρχει περίπτωση να περιμένει η μια διαδικασία να τελειώσει η άλλη και το ανάποδο.
Βέβαια αν δεν υπάρχει περίπτωση για ταυτόχρονη πρόσβαση στην εφαρμογή από πολλούς χρήστες να μην χρειάζεται να λάβεις υπόψιν σου τα παραπάνω.

---

My dream is to fly over the rainbow so high!!!!