You can use a generic dao that returns iqueryables and write the queries in models or create simple artifacts for the query stuff, by just injectin isessionfactory and calling getcurrentsession. You can read more about this pattern on the book or Fabio's blog, search for EQO enhanced query object.
Isessionfactory.getcurrentsession is usefull when you deal with a context, but if you need just plain data and you dont have to use the unit of work pattern you can call sf.opensession or openstateless session for the query and close that session right in the query. About testing your daos, if your tested code use getcurrentsession you dont need all the cpbt stuff just use thread as current session context and call currentsessioncontext.bind unbind. 2011/1/5, jcomet <[email protected]>: > Frist I'd like to say thanks to everyone who worked on the book - it > has helped me a lot. Thanks also for your blogs and the endless > contributions from the leaders here! You guys rock. > > I have a WinForms project in which I am trying to follow the CpBT / > uNhAddIns patterns from Jason Dentler's NHibernate 3.0 Cookbook. I > have my presenters talking to models which talk to the DAOs, using the > CpBT pattern. This is where the example code ends and my questions > begin. > > 1. Where should queries go? The DAOs are generic and handle the > generic stuff, but what about individual queries? The models > shouldn't touch the NH session directly, and they can't go in the > generic DAOs can they? I've created a queries class which I have > wired to the models as needed via DI, but my sense is that isn't what > you smart people would do. > > 2. What is the right way to test the DAOs? The CpBT stuff is handled > in the models, so it seems we want some other method that just gives > us an ISession to work with for the DAOs. That's ok, but if we do > that, won't it be a pain to combine CpBT model tests in the same test > project as DAO tests, since we'll have to fuss with the NH setup and > config? > > 3. The CpBT pattern assumes that there is a point at which one knows > the conversation is over so end it and let the session flush - but > what if there isn't. What if a model supports queries as well as > updates, i.e. I can fill a grid as well as edit data. Should one > model = one conversation so one model for queries and one for edits > which end with a "Save Changes" method or with each insert/update? > > I apologize if these questions have been answered elsewhere. > > Thanks, > Jim > > > -- > 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. > > -- Enviado desde mi dispositivo móvil -- 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.
