Interesting opinions - and also a very interesting last statement from Gunnar "back when I still believed that generic, queryable repositories were a good idea" that matches my own current thinking. We wrote a fairly large system with this design, and at the end of it concluded that the generic repositories were just a layer of unnecessary cruft which served no real purpose. Our conclusion/opinion, obviously, and not intended to offend anyone who thinks otherwise!
To explain my ideas about the separation between 'database' and 'memory' access, my rationale is that they have very different costs and so I'd like to be absolutely certain that my object access code is working at the layer I think it is. It'd be lovely if DB's didn't have IPC latency, but unfortunately that's pretty much a certainty unless you've got an embedded DB - and even then, there's the whole nasty issue of mechanical storage to contend with. With LINQ, there's a danger that something you think is being done at the database is actually happening in-memory with a bunch of REBAR operations behind the scenes (think N+1 select); with QueryOver, I know that I'm formulating an RPC call that cannot be anything else. Then again, I have very mixed feelings about lazy initialisation vs. getting the correct object graph for your operation in one go. Pete -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Gunnar Liljas Sent: 25 January 2013 18:01 To: [email protected] Subject: Re: [nhusers] LINQ vs QueryOver? I think the keyword there is "ideally", as in "in a utopian world" (no disrespect meant). "What if the "Database" happens to be an in-memory implementation????" That doesn't just happen, IMO. "What happens if the "Business" needs to cache data (privately and locally) but the cache happens to be implemented as a DB..." Again, that doesn't just happen, and if for some reason it does, having the cache expose free form queryability seems far fetched. The LINQ provider is very powerful and I use it almost exclusively, but only because it's what's most convenient when introducing new developers, and because I got used to it back when I still believed that generic, queryable repositories were a good idea. /G 2013/1/25 TheCPUWizard <[email protected]>: > Pete, > > Just my perspective.... I would much rather not see ANY distinction in the > code between "database" and "in memory" access. Information Access *is* > Information Access....that being said, I do see a big different between > selection/filtering logic in the DAL vs. the BL. So there needs to be > separation of concerns... > > 1) What if the "Database" happens to be an in-memory implementation???? > 2) What happens if the "Business" needs to cache data (privately and > locally) but the cache happens to be implemented as a DB... > > Ideally (Again from my perspective) either of the two conditions above > should be able to "toggle" and have NO impact on the code that is doing the > work. > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Pete Appleton > Sent: Wednesday, January 23, 2013 6:54 AM > To: [email protected] > Subject: [nhusers] LINQ vs QueryOver? > > Hi folks, > > With all the discussion about LINQ recently, I'm just wondering which API > other people prefer for NHibernate. We've standardised on QueryOver, which > I quite like in general but it seems that other people are moving towards > LINQ - is this the case, and if so then why? Our choice of QueryOver is > motivated by (1) avoiding the 'magic strings' in HQL (or SQL!), and (2) > making a clear-cut distinction between DB access > (QueryOver) vs in-memory operations (LINQ extensions). What do other people > prefer, and why? > > Cheers, > > Pete > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/nhusers?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers?hl=en. For more options, visit https://groups.google.com/groups/opt_out. !DSPAM:1,5102c8551878245412261! -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
