The latest installment of the Summer of NHibernate screencast series is now available for immediate download from the main site.
In this screencast we explore how to detach persistent objects from an NHibernate session instance, work with them, and then reattach them to another session so that they can be subsequently persisted by the new session. We take a look at understanding NHIbernate’s dirty-tracking capabilities, its power, its limits, and how this relates to detached objects. This all lays the groundwork for an upcoming session in which we explore managing session lifecycle in stateless web applications.
We also dig into NHIbernate’s support for detached criteria, look at how this can radically increase the flexibility of the code in our data-access-layer, and begin to explore ways to develop reusable NHibernate-enabled data-access-code that enables us to travel down a path of refactoring our general data-access-class into object-specific repositories using a much more extensible and maintainable model.
As always, questions, comments, and feedback are encouraged~!
very good tutorial…
Hi Steve,
superb screen cast THANK YOU!!!
I’m little bit confused as to why would you use detachedcriteria? in a real world app scenario π would you please shed some light?
Thanks
Nisar
@Nisar:
As demonstrated in the screencast, DetachedCriteria provides two significant capabiltiies:
1) allows you to construct Criteria instances that can be assembled in one part of your application and exectuted by another
2) allows you to abstract your queries to a higher level (e.g., the lightweight specification pattern I mentioned)
The advantage of #1 is that it allows one part of your app to construct the Criteria instance (often dynamically based on response to some user input) and pass it into the data-access-methods without the Criteria-creating code needing to know/care about the semantics of which session instance to use (e.g., is this all happening in an existing session, a new session, a long-running transaction, etc.?). This enables better separation-of-concerns across your application.
The benefit of #2 is that I can pre-constuct reusable and composable ‘bits’ of Criteriae in advance of their use in the application. Assume I often want to interact with customers that are Domestic customers and also with customers that are Foreign customers to my business.
I can repeat logic 1000 times in my datalayer that says “….where Customer.Address.Country = ‘United States'” or “….where Customer.Address.Country <> ‘United States'” as appropriate, but this hard to maintain and completely blows the DRY principle.
By predefining DomesticCustomerCriteria and ForeignCustomerCriteria instances, I have encapsulated the logic for determining foreign/domestic customers into a higher-level abstraction (e.g, the ‘specification’) that can be easily reused in other places I need it as part of my query composition in other data-access-methods.
Does all that help clarify this for you…?
Hi Steve,
In this session, you modified the code for ResetSessionForProvider method so that it closes the session prior to resetting it. Now all the methods that use ResetSessionForProvider work perfectly except one method which is CanThrowExceptionOnConcurrencyViolation which throws an exception says “Session already closed” and this is only when using NHibernate 2.0. I did examine it using NHibernate 1.2 and it did not throw that exception. so when using NHibernate 2.0 (which we all are going to do sooner or later) I had to reset the session with out closing in this method only.
Any idea why is this happening? is it a bug in NHibernate. or was it a bug and it’s been fixed!!
thanks in advance
O.K.
I guess I found the problem and it seems because we are using
“using (_session)” block, the _session gets disposed post this block and when we resetting the session it gets closed even before it is reset. If I comment out the “using (_session)” block it works just fine.
The question is why NHibernate considers _session closed even after resetting it?
Hi Steve:
I am trying to implement an abstract class that will be the base for a family of concrete business objects that I want to persist to the database. The reason that I am doing this is so that properties such as ID, LastSavedDateTime, Version, etc. could be abstracted to this base class level. I can then leverage a series of generic data handling methods that will operate on objects derived from this base class and wouldn’t have to create data handling methods specific to each business object class. My question is: I have tried to use the abstract attribute in my mapping of this base class, but nHibernate still wants to see an ID defined for this class and an underlying table. How can I code the mapping in nHibernate to implement this base abstract class. Or could you suggest an alternative strategy?
Thanks. I am really enjoying this series a lot!!
Ooops. I had formulated my previous question after having viewed Session 11 but before I saw Session 12. I like your elegant solution in Session 12 for the use of Generics. Thanks.
Hi Steve
Thanks again for these superb screen casts !
I noticed that you are a project member of the Fluent NHibernate project. Any chance you’re going to show us a bit about this in the upcoming shows ?
One
btw,
Would you mind sharing with us how many times the videos have been downloaded ? Just being curious π
I was also wondering how many people have decided to start using NHibernate after watching these videos. I know I am !
(Did someone say ‘poll’ ? π )
One
@One:
Although I did sign up to join the Fluent-NHib project, its turned out that I am entirely too swamped with other committments to contribute much to the project beyond participating in some design discussions around it.
I’m not presently planning to produce any related screencast content, but that could change if the project matures more quickly than is currently planned; right now it looks very much as if the final Summer of NHibernate Screencast installment will draw to a close long before the Fluent NHib effort gets ready for ‘general consumption’ by anyone other than bleeding-edge adopters.
There are always ups and downs whenever you have a new release. Just hang in there !!! Thanks for the great read
δΌ ε₯η§ζ