
Για να χρησιμοποιήσετε πλήρως LinqToSql σε 3,5 εφαρμογής ASP.net, είναι απαραίτητο να δημιουργηθεί [DataContext](http://msdn.microsoft.com/en-us/library/system.data.linq.datacontext.aspx)  [τάξεις](http://dotnetslackers.com/articles/csharp/InsideTheLINQToSQLDataContextClass.aspx) (η οποία γίνεται συνήθως με τη χρήση του σχεδιαστή στο VS 2008). Από την οπτική γωνία UI, το DataContext είναι ένα σχέδιο των τμημάτων της βάσης δεδομένων σας που θα θέλατε να εκθέσει σε μέσα LinqToSql και είναι αναπόσπαστο στη δημιουργία των χαρακτηριστικών ORM της LinqToSql.


Το ερώτημά μου είναι: Είμαι δημιουργία ενός έργου που χρησιμοποιεί μια μεγάλη βάση δεδομένων όπου όλοι οι πίνακες συνδέονται μεταξύ τους με κάποιο τρόπο μέσα από Foreign Keys. πρώτη κλίση μου είναι να κάνω ένα τεράστιο κατηγορία DataContext ότι τα μοντέλα ολόκληρη τη βάση δεδομένων. Με αυτόν τον τρόπο θα μπορούσα θεωρητικά (αν και δεν ξέρω αν αυτό θα χρειαζόταν στην πράξη) χρησιμοποιούν οι ξένες Βασικά συνδέσεις που δημιουργούνται μέσω LinqToSql να πάει εύκολα μεταξύ των σχετικών αντικειμένων στον κώδικα μου, εισάγετε σχετίζονται με αντικείμενα, κ.α.


Ωστόσο, μετά του δίνει κάποια σκέψη, είμαι τώρα σκέφτομαι ότι μπορεί να έχει περισσότερο νόημα να δημιουργήσετε πολλαπλές κατηγορίες DataContext, ο καθένας σχετικά με ένα συγκεκριμένο χώρο ονομάτων ή λογική αλληλένδετα ενότητα στη βάση δεδομένων μου. Κύριο μέλημά μου είναι ότι εμφανίσεων και διάθεσης μια τεράστια κατηγορία DataContext όλη την ώρα για μεμονωμένες πράξεις που αφορούν συγκεκριμένους τομείς της βάσης δεδομένων θα επιβάλουν μια περιττή επιβολή στους πόρους της εφαρμογής. Επιπλέον, είναι πιο εύκολο να δημιουργήσετε και να διαχειριστείτε μικρότερα DataContext αρχεία από ένα μεγάλο. Το πράγμα που θα χάσουν είναι ότι θα υπάρξει κάποια μακρινά τμήματα της βάσης δεδομένων που δεν θα ήταν πλωτός μέσω LinqToSql (ακόμα κι αν μια αλυσίδα των σχέσεων τους συνδέει με την ίδια βάση δεδομένων). Επιπλέον, θα υπάρξουν κάποιες τάξεις πίνακα που θα υπάρχουν σε περισσότερες από μία DataContext.


Οποιεσδήποτε σκέψεις ή εμπειρίες σχετικά με το εάν πολλαπλές DataContexts (που αντιστοιχεί σε DB ονομάτων) είναι κατάλληλα στη θέση του (ή επιπλέον) ένα πολύ μεγάλο κατηγορία DataContext (που αντιστοιχεί στο σύνολο της DB);

 
Οι πολλαπλές κατηγορίες DataContext ποτέ κατάλληλη;
===================================================



Διαφωνώ με την απάντησή του Ιωάννη. Η DataContext (ή Linq σε οντότητες ObjectContext) είναι περισσότερο από μια «μονάδα εργασίας» από μια σύνδεση. Διαχειρίζεται την παρακολούθηση αλλαγών, κλπ Δείτε αυτό το blog post για την περιγραφή:


[Διάρκεια ζωής της LINQ to SQL DataContext](http://blogs.msdn.com/dinesh.kulkarni/archive/2008/04/27/lifetime-of-a-linq-to-sql-datacontext.aspx)


Τα τέσσερα κύρια σημεία του αυτό το blog είναι ότι DataContext:


1. Είναι ιδανικό για μια «μονάδα εργασίας» προσέγγιση
2. Είναι επίσης σχεδιασμένο για «απάτριδες» λειτουργία του διακομιστή
3. Δεν είναι σχεδιασμένη για μεγάλη διάρκεια ζωής χρήσης
4. ```
Should be used very carefully after
any SumbitChanges() operation.

```


Λαμβάνοντας υπόψη ότι, δεν νομίζω ότι χρησιμοποιούν περισσότερες από μία DataContext θα κάνει οποιαδήποτε επιβλαβών συνεπειών στην πραγματικότητα, δημιουργώντας διαφορετικές DataContexts για διαφορετικούς τύπους εργασίας θα βοηθήσει να γίνει LinqToSql impelmentation σας πιο usuable και οργανωμένη. Το μόνο μειονέκτημα είναι ότι δεν θα είναι σε θέση να χρησιμοποιήσει sqlmetal για να δημιουργήσει αυτόματα dmbl σας.

 

Σύμφωνα με την εμπειρία μου με LINQ σε SQL και LINQ να Φορείς ένα DataContext είναι συνώνυμο με μια σύνδεση με τη βάση δεδομένων. Έτσι, εάν επρόκειτο να χρησιμοποιήσετε πολλές αποθήκες δεδομένων θα πρέπει να χρησιμοποιήσετε πολλαπλές DataContexts. ενστικτώδης αντίδραση μου είναι ότι δεν θα παρατηρήσετε σε ένα μεγάλο μέρος μιας επιβράδυνσης με DataContext που περιλαμβάνει ένα μεγάλο αριθμό πινάκων. Αν το έκανε, ωστόσο θα μπορούσατε πάντα να διαιρέσετε τη βάση δεδομένων λογικά σε σημεία όπου μπορείτε να απομονώσουν τους πίνακες που δεν έχουν καμία σχέση με άλλα σύνολα των πινάκων και να δημιουργήσει πολλαπλά περιβάλλοντα.

 

Είχα διένεξη για την ίδια ερώτηση, ενώ ρετρό τοποθέτηση LINQ σε SQL σε μια κληρονομιά DB. Η βάση δεδομένων μας είναι ένα κομμάτι από ένα μέγα ψεύδος (150 πίνακες) και μετά από κάποια σκέψη και τον πειραματισμό μου επέλεξε να χρησιμοποιήσει πολλαπλά DataContexts. Είτε αυτό θεωρείται ένα αντι-σχέδιο μένει να δούμε, αλλά προς το παρόν αυτό κάνει τη ζωή διαχειρίσιμο.

 

Νομίζω ότι ο John είναι σωστή. 


«Κύριο μέλημά μου είναι ότι εμφανίσεων και διάθεσης μια τεράστια κατηγορία DataContext όλη την ώρα για μεμονωμένες πράξεις που αφορούν συγκεκριμένους τομείς της βάσης δεδομένων θα πρέπει να επιβάλει μια περιττή επιβολή στους πόρους εφαρμογή»


Πώς μπορείτε να υποστηρίξει αυτή τη δήλωση; Τι είναι το πείραμα που δείχνει ότι ένα μεγάλο DataContext είναι μια δυσχέρεια απόδοσης; Έχοντας πολλαπλές datacontexts είναι πολλά όπως έχει πολλαπλές βάσεις δεδομένων και νόημα σε παρόμοια σενάρια, δηλαδή, σχεδόν ποτέ. Εάν εργάζεστε με πολλαπλές datacontexts θα πρέπει να κρατήσει τη διαδρομή της οποίας τα αντικείμενα ανήκουν στο οποίο datacontext και δεν μπορεί να αφορά αντικείμενα που δεν είναι στο ίδιο πλαίσιο δεδομένων. Αυτό είναι ένα δαπανηρό σχέδιο μυρωδιά χωρίς πραγματικό όφελος.


@Evan «Η DataContext (ή LINQ σε οντότητες ObjectContext) είναι περισσότερο μια“μονάδα εργασίας”από τη σύνδεση» Αυτός είναι ακριβώς ο λόγος που δεν πρέπει να έχει περισσότερους από έναν datacontext. Γιατί θα θέλατε περισσότερες από μία «μονάδα εργασίας» σε μια στιγμή;

 

Θα πρέπει να διαφωνήσω με την αποδεκτή απάντηση. Στο ερώτημα που τέθηκε, το σύστημα έχει μια ενιαία μεγάλη βάση δεδομένων με ισχυρό ξένο κλειδί σχέσεων μεταξύ σχεδόν κάθε πίνακα (και στην περίπτωση όπου εργάζομαι). Σε αυτό το σενάριο, το σπάσιμο σε μικρότερα DataContexts (DC) έχει δύο άμεσες και σημαντικά μειονεκτήματα (και τα δύο αναφέρονται από την ερώτηση):


1. **Χάνετε τις σχέσεις μεταξύ ορισμένων πινάκων.** Μπορείτε να δοκιμάσετε να επιλέξουν τα όριά σας DC με σύνεση, αλλά θα τρέξει τελικά σε μια κατάσταση όπου θα ήταν πολύ βολικό να χρησιμοποιήσετε μια σχέση από ένα τραπέζι σε ένα DC σε ένα τραπέζι στο άλλο, και δεν θα είναι σε θέση να.
2. **Μερικοί πίνακες μπορεί να εμφανιστεί σε πολλές της DC.** Αυτό σημαίνει ότι αν θέλετε να προσθέσετε πίνακα ειδικές μεθόδους βοηθός, επιχειρηματική λογική, ή άλλο κώδικα σε επιμέρους κατηγορίες, οι τύποι δεν θα είναι συμβατή σε όλη της DC. Μπορείτε να επιλύσετε αυτό το κληρονομεί από κάθε κατηγορία οντότητας από τις δικές του συγκεκριμένες βασική κλάση της, η οποία παίρνει βρώμικο. Επίσης, αλλαγές σχήματος θα πρέπει να επαναληφθεί σε πολλές της DC.


Τώρα αυτά είναι σημαντικά μειονεκτήματα. Υπάρχουν πλεονεκτήματα αρκετά μεγάλη για την αντιμετώπισή τους; Το ερώτημα αναφέρει απόδοση:



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


Στην πραγματικότητα, δεν είναι αλήθεια ότι ένα μεγάλο DC παίρνει πολύ περισσότερο χρόνο για την υπόσταση ή να χρησιμοποιήσετε σε μια τυπική μονάδα εργασίας. Στην πραγματικότητα, [μετά την πρώτη φάση δημιουργείται σε μια διαδικασία λειτουργίας, μετέπειτα αντίγραφα του ίδιου DC μπορούν να δημιουργηθούν σχεδόν ακαριαία](http://blogs.msdn.com/b/gisenberg/archive/2008/05/20/linq-to-sql-optimizing-datacontext-construction-with-the-factory-pattern.aspx#9904456) .


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


Επίσης, η μονάδα της έννοιας της εργασίας δεν είναι πραγματικά σχετικό με την αρχική ερώτηση. Μονάδα έργο αναφέρεται χαρακτηριστικά στο πόσο ένα έργο ενός και μόνο DC ***παράδειγμα*** κάνει, δεν πόση δουλειά ενός DC ***τάξη*** είναι ***ικανή*** να κάνει.

 