Αν θέλεις να κάνεις cache objects τα οποία δεν αλλάζουν συχνά, και έχεις έλεγχο της cache την ώρα που αλλάζουν (π.χ. τη στιγμή του deployment), τότε δε σε εμποδίζει τίποτα να τα κρατήσεις in memory έξω από το DataContext που τα δημιούργησε. Δεν έχεις change notifications (πρέπει να υλοποιήσεις κάποιο μηχανισμό μόνος σου) και είναι μεγάλη φασαρία να ενημερώσεις από την cache πίσω τη βάση σου, αλλά π.χ. για τα configuration tables σου θα μπορέσεις να κάνεις caching μια χαρά.

Άλλου είδους caching σε web app θα έλεγα ότι είναι μάλλον μεγαλύτερος κόπος παρά κέρδος.

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

Να προσθέσω ένα σχολιάκι για το LINQ (και αυτό προς συζήτηση): Είναι η τεχνολογία για την οποία είναι δημοσιευμένες το μεγαλύτερο πσοσοστό μπούρδων στο web. Είναι απίστευτο πόσο πολύ πέφτω σε blogs που πραγματικά γράφουν μπούρδες. Ίσως φαίνεται τόσο ελκυστικό που τραβάει ανθρώπους χωρίς εμπειρία να ασχοληθούν... και καλό και κακό...

Δεν μου φαίνεται περίεργο. Αυτοί που έχουν ήδη εμπειρία και ξέρουν να σου απαντήσουν είναι όσοι χρησιμοποιούν ORMs εδώ και καιρό, αν και αυτοί ασχολούνται περισσότερο με το Entity Framework πλέον. Όλοι οι άλλοι είναι καινούριοι οι οποίοι τώρα ανακαλύπτουν τα ORMs και τα παλούκια τους και κατά πάσα πιθανότητα αποφεύγουν να διαβάσουν καν για ORMs. Λογικό είναι μέχρι να μάθουν θα γράφουν άρθρα σχετικά χαμηλότερης ποιότητας.

Φαντάζεσαι ένα προγραμματιστή αποκλειστικά VB6 να γράφει για threads ή generics ?

Νατάσα Μανουσοπούλου:

Αν θέλεις να κάνεις cache objects τα οποία δεν αλλάζουν συχνά, και έχεις έλεγχο της cache την ώρα που αλλάζουν (π.χ. τη στιγμή του deployment), τότε δε σε εμποδίζει τίποτα να τα κρατήσεις in memory έξω από το DataContext που τα δημιούργησε. Δεν έχεις change notifications (πρέπει να υλοποιήσεις κάποιο μηχανισμό μόνος σου) και είναι μεγάλη φασαρία να ενημερώσεις από την cache πίσω τη βάση σου, αλλά π.χ. για τα configuration tables σου θα μπορέσεις να κάνεις caching μια χαρά.

Άλλου είδους caching σε web app θα έλεγα ότι είναι μάλλον μεγαλύτερος κόπος παρά κέρδος.

Αυτό ακριβώς είχα κατά νου όταν έγραφα ότι έχεις τον έλεγχο, ώστε φορτώνοντας το κατάλληλο τμήμα του reference tree με DataLoadOptions έχεις στα χέρια σου τα αντικείμενα που μπορεί να σου χρειαστούν και όχι παραπάνω. Σε περιορισμένα σενάρια χρήσης, και όταν υπάρχουν λίγες συσχετίσεις, ακόμα κι αυτό το απλοϊκό σενάριο μπορεί να φανεί χρήσιμο.

Στην πραγματικότητα, αν θέλεις εύκολο attach-detach, πρέπει να κοιτάξεις προς το EF.

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

Καλημέρα, το θέμα είναι ότι αν βάλω στο cache ένα object πχ product, σε ένα επόμενο request μπορεί κάποιος να χτυπήσει το product.supplier, το οποίο αν δεν είχε φορτωθεί αρχικά θα χτυπήσει, γιατί το context του συγκεκριμένου cachαρισμένου product έχει γίνει πλέον disposed. Keep in mind ότι ο κόσμος κάτω από το caching layer ας το πούμε έτσι, δεν έχει την παραμικρή ιδέα για το από που προήλθε το object, αν κάποιος το διάβασε από τη βάση και του το έδωσε, ή με κάποιο μαγικό τρόπο ήρθε από το cache.

Ιδανικά θα ήθελα ο cache manager μου, μόλις πιάσει το object για να το σερβίρει, να δει ότι το context του είναι πεθαμένο, οπότε να το κάνει attach στο τρέχον, ενεργό context και να το δώσει σε αυτόν που το ζητάει (και να γινόταν attach και όλο το δέντρο του; περίεργο ακούγεται δεν ξέρω πως ακριβώς...). Το attach το λέω με την έννοια της λέξης, όχι με την έννοια του linq (desirialized object).

Ουσιαστικά η μόνη λύση που θεωρητικά φαίνεται να δουλεύει, είναι να γίνουν serialized τα objects και να μπαίνουν στο cache, οπότε όντως ο cache manager να τα κάνει attach (με την έννοια του linq). Στην πράξη φοβάμαι ότι αυτό θα είναι παλαβό, σε κάθε request να γίνονται desirialized -> serialized όλα τα objects που χρησιμοποιούνται.

Έχεις διαβάσει το "Object States and Change-Tracking (LINQ to SQL)"

George J.

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Τον τελευταίο καιρό χρησιμοποιώ τόσο το EF όσο και την Linq2Sql κατά βούληση: Το πρώτο σε μεγαλύτερα έργα και την δεύτερη σε μικρότερα.

Αυτό που θα σε συμβούλευα είναι το εξής (γιατί είδα κάπου πως είσαι από αυτούς που χρησιμοποιούν business objects αντί για datasets - όπως και εγώ): Τα objects της Linq2Sql μην τα χρησιμοποιείς σαν business objects, είναι καλύτερο να τα μετατρέπεις σε business objects. Ξέρω πως έτσι θα χάσεις το caching σου αλλά στη θέση σου δεν θα ανησυχούσα γιατί αυτό.

Το cache το χάνεις όποτε χάνεις και το context (σε web apps αυτό γίνεται υπερβολικά συχνότερα από όσο ίσως να φαντάζεσαι). Αν η εφαρμογή σου όντως είναι βαριά, το caching solution που σου προσφέρει η Linq σταματάει εξ' όρισμού (ανεξάρτητα από το πόσες πατέντες, σκάντζες, νέες θεωρίες και ώρες χαμένες θα δώσεις) όταν θα περάσεις στο στάδιο web farming (δεν ξέρω κατά πόσο βαρύ είναι αυτό που έχεις αλλά το να μιλάς για caching δεν μου αφήνει περιθώρια να μην φανταστώ για σένα το χειρότερο).

Τα caching που ακριβώς το κάνεις στο app σου; Στο application level; Στο user level; Πόσο ζει ένα LinqDataContext στην εφαρμογή σου; Πόσο παραπάνω βαραίνει την εφαρμογή το caching; Πόσο μεγάλο (σε bytes) φτάνει το xml cache της Linq; Μετά από 10 ώρες uptime η εφαρμογή θα φτάσει στο όριο της αν αρχίσει το λογιστήριο να *cacharei* (κατά λάθος) reports για τα τελευταία 10 χρόνια;

Το caching μπορεί να είναι σωτηρία αλλά και μεγάλο βάσανο. Γνώμη μου είναι πως αν όντως θες cache κάντο έξω από την Linq, με δικό σου τρόπο (το είχα ψάξει στην αρχή και εγώ αλλά δεν βρήκα τίποτα το οποίο να υπάρχει από default και να μου κάνει) και σε πράγματα τα οποία να έχει νόημα να το κάνεις.

Καλή τύχη.

azazeal:

Τα objects της Linq2Sql μην τα χρησιμοποιείς σαν business objects, είναι καλύτερο να τα μετατρέπεις σε business objects.

Η λογική σου είναι εντελώς ΛΑΘΟΣ!!!!

Ποτέ .BO namespace αλλά .Entities namespace.
Ποτέ BLL namespace αλλά .Business namespace.
Ποτέ .DAL αλλά .DataAccessLayer namespace. 

Δεν πάμε καλά σε αυτή τη χώρα...

Στα σοβαρά τώρα: Για κάθε object της Linq φτιάξε ένα extension να σου το μετατρέπει/αντιγράφει/κάνει-ότι-θέλει-και-συμφέρει-όταν-δεν-crashάρει στο αντίστοιχο του .Entities namespace και είσαι OK (π.χ. για το object .DataAccessLayer.Client φτιάξε το extension .ToClientEntity( ) το οποίο θα σου το μετατρέπει σε .Entities.Client). Είναι τεσταρισμένη μέθοδος, έχει δουλέψει, δεν παρουσιάζει προβλήματα με μόνο ένα catch: Οι μετατροπές πρέπει να γίνονται σε "ζωντανό" context, σου παραθέτω τα παρακάτω.

Linq2Sql object (σε παιδικό γράψιμο): Client { string ClientId, string Name, decimal Rate }

Έστω Χ (ψέμματα), έστω function (στο DAL σου) όπου E.Client το object σου στο .BO και C.Client το object σου στο .Dal

        public E.Client GetClientById( string ClientId )
        {
            using ( DbDataContext db = GetDb( ) )
            {
                var query = ( from c in db.Clients
                              orderby c.Name
                              where c.ClientId.ToString( ) == ClientId
                              select c );

                if ( query.Count( ) == 1 )
                    return query.Single( ).ToClientEntity( );     /* Παρατήρησε το using μέσα στο οποίο καλείτε το .ToClientEntity( ) */

                return null;
            }
        }

Και το κερασάκι (extension):

        public static E.Client ToClientEntity( this C.Client Client )
        {
            if( Client == null ) return ( E.Client )null;

            E.Client ret = new E.Client( );

            ret.ClientId = Client.ClientId.ToString( );
            ret.Name = Client.Name;
            ret.Rate = Client.Rate;

            return ret;
        }

Υ.Γ: Θα ήταν υπερβολικά πολύ να ζητήσω ένα db.SyntaxHighlighter ή υπάρχει ήδη υλοποιημένο και μόλις έγινα ρόμπα;

azazeal:

Η λογική σου είναι εντελώς ΛΑΘΟΣ!!!!

Ποτέ .BO namespace αλλά .Entities namespace.
Ποτέ BLL namespace αλλά .Business namespace.
Ποτέ .DAL αλλά .DataAccessLayer namespace. 

Δεν πάμε καλά σε αυτή τη χώρα...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 

[Table(κτλ.)]
public partial class Client
{
    private string _ClientId;
    private string _Name;
    private string _Rate;
    partial void OnCreated();
    public Client() { OnCreated(); }
    [Column(κτλ.)]
    public string ClientId
    {
             //κτλ.
    }
    [Column(κτλ.)]
    public string Name
    {
             //κτλ.
    }
    [Column(κτλ.)]
    public string Rate
    {
             //κτλ.
    }
}

1
2
3
4
5
 

public interface IClient {
    string ClientId { get; set; }
    string Name { get; set; }
    string Rate { get; set; }
}

1
 

public partial class Client : IClient { }

• Εκτός του DataContext, ένα detached αντικείμενο μπορεί να αποθηκευθεί σε ένα οποιοδήποτε cache. Αυτό μπορεί να γίνει ανεξάρτητα από το ORM και έχει θέματα όπως το τί θα κάνεις cache, μόνο το αντικείμενο, το αντικείμενο και τα child αντικείμενα, κάτι άλλο?
  
• Εντός του DataContext μπορούν να αποθηκευθούν τα χύμα δεδομένα από τα οποία θα δημιουργηθεί ένα object όταν ζητηθεί. Αυτό ΔΕΝ γίνεται με το LINQ ενώ υποστηρίζεται από το EF και το NHibernate.
  

DeClen:

- Ορίζουμε το interface IClient

1 2 3 4 5

public interface IClient { string ClientId { get; set; } string Name { get; set; } string Rate { get; set; } }

- To business object μας

1	public partial class Client : IClient { }

Η αλήθεια είναι πως δεν το έχω δοκιμάσει για να δω αν δουλεύει σωστα.

Ελπίζω το team του EF να μας βοηθήσει λίγο περισσότερο σε κάποια μελλοντική έκδοση...

Αυτό πως σου λύνει το πρόβλημα με τα exceptions όταν το DataContext είναι disposed (σε περίπτωση που τα properties δεν είναι primitive data types δηλαδή;); Έχω την εντύπωση πως δεν στο λύνει...

Όσα έγραψε ο Καναβός από πάνω είναι πολύ ωραία, αρκεί να τα γράψεις μία φορά και παίζουν universally (αρκεί να βρεις το χρόνο). Πολλοί έχουν αφιερώσει το χρόνο τους στο να φτιάξουν δικές τους λύσεις ή να ακολουθήσουν το δρόμο που άνοιξαν οι άλλοι και επαναλαμβάνω πως όσα είπε ο Παναγιώτης είναι όντως πολύ σωστά αλλά υπάρχει ένας δρόμος στο να καταλάβει κάποιος πως δουλεύει ένα ORM και ο δρόμος αυτός είναι μακρύς και σε καμμία περίπτωση εύκολος.

Εγώ προσωπικά ξεκίνησα το δικό μου ORM πριν να δω τι παρέχουν τα προϋπάρχοντα και όχι γιατί βαριούμουνα να ψάξω αλλά γιατί ήθελα να ανακαλύψω τον τροχό από την αρχή. Ήθελα να μάθω από τα λάθη μου και ήθελα να απογοητευτώ με τη σύγκριση της πρώτης μου επίσημης έκδοσης με την τρέχουσα (εκείνης της εποχής) του NHibernate και πιστέψτε με, άξιζε κάθε *χαμένη* στιγμή.

Ο καθένας μας δίνει λύσεις κομμένες και ραμένες στα μέτρα του. Κάθε dev έχει το δικό του αγαπημένο ORM και αυτό δύσκολα αλλάζει. Βρείτε το δικό σας, φτιάξτε το δικό σας, κλέψτε κάποιου άλλου αλλά εν πάσει περιπτώσει χρησιμοποιήστε ένα ORM: Ο χρόνος που κερδίζει ένα ORM είναι ανεκτίμητος.