In general, I think we spend way too much time trying to create architectures which are fool proof (in the literal meaning), instead of spending that time...
1. Creating a productive architecture 2. Teaching the beginners about the boundaries of queries etc. 3. Monitoring you own designs, e.g with tools like NHProf etc. /G 2013/1/28 Pete Appleton <[email protected]>: > 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. > > -- 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.
