@Paulo:

The reason you tend to see so many examples of managing session lifespan in a web app is that this is the context in which its the most challenging/there are the most issues to overcome.

In a winforms app, the management of this is much more straightforward, but how about this: I will promise that in the upcoming session on managing Session lifespan in a web app I will compare and contrast the techniques that I am planning to show for the web with how such a thing would be done in a windows app. That way both are covered.

@Nisar:

You are correct that its indeed ‘a pain’ to have to structure your SPs to match the order that Nhib emits parameters for its own generated parameterized SQL; that’s sort of why the slide in the deck that says “its a myth that NHib’s support for sprocs is completely flexible and without limit” 🙂

As for having to write HQL (or criteria queries) first just to see the order of the params NHib will use, this is not really needed if you just understand the following coventions that NHib *usually* abides by when generating its SQL:

1) the delete SQL always just passes a single param, the ID of the entity to delete (unless as we saw in the video you are using VERSIONing for optimistic concurrency support or as you can guess if you are using TIMESTAMP for concurrency support)

2) the insert SQL always passes the params in the *exact* order of each [property /] tag (square brackets used here since WordPress strips out angle-brackets) in the mapping file with the following exception: the ID param is almost always passed in the LAST param position (no concurrency support needed for an INSERT so no special rules about concurrency in these cases)

3) the update SQL always passes the params in the same order as specified in the [property /] tags in the mapping files except for the id which is passed last UNLESS you are using VERSION for concurrency support in which case ID is second-to-last and ‘oldversion’ is the last param passed

You can sort of deduce/infer these ‘rules’ from watching the screencast so if you want to just develop your SPs based on these ‘conventions’ you can USUALLY end up mostly OK with them and not need to actually write HQL to inspect the generated SQL.

You should note a few things about this approach however:

1) you of course need some unit tests around the calls that use these sprocs to ensure that all the ‘inferring’ (guessing!) you’re doing per the above rules is really completely correct

2) these ‘rules’ are really just reverse-engineering of NHib’s generated SQL ‘conventions’ and they are absolutely NOT documented anywhere and NOT guaranteed to be true in all cases or even from one version of NHib to the next; like all ‘conventions’ that are unwritten and undocumented, they may change without notice as you are really relying on a completely undocumented ‘feature’ of NHib that may change unexpectedly

The bottom line is that while you MAY proceed based on these ‘rules’ (inferences about NHib’s behavior when generating its SQL), you certainly do so at your own risk 🙂

@Mrunal:

Thanks for the feedback; indeed I skipped over using sprocs to retrieve data and return objects. This is actually pretty straightforward compared to INSERT, UPDATE, and DELETE so I skipped over it.

If you’re interested in doing some research on how READS using sprocs work, here is the (high-level) overview:

NHibernate supports the concept in the mapping file(s) of ‘named-queries’. You can define a named query as any valid SQL statement for your target platform (e.g., T-SQL for MSSQL, pl/sql for ORA, etc.) so its perfectly legal for this to be an EXEC… statement that calls a sproc.

You then call that named query from the ISession instance and (usually) use AliasToBeanResultTransformer(…) to convert the resultset into your desired object(s).

AliasToResultBeanTransformer(…) is a function-name hold-over from the Java/Hibernate world where the original intent of the method was to return a fully-hydrated Enterprise Java Bean object ready to be used in your application. It works on the assumption that your query will return a column name that correctly matches perfectly with the name of each property on your object/class and it just sets each property to the value from each column with a matching name (for more details, refer to the NHib docs on this method).

An alternate method if your sproc doesn’t return cols with names that perfectly match the props on your class is to use the HQL-only strategy of doing a SELECT new MyClass(…) kind of statement to dynamically invoke the construction of your desired result object as I showed in either session 02 or 02a when returning my strongly-typed CustomerFirstnameCounter objects.

Hope this helps~!

@Mrunal:

Sorry about sending you on a wild goose chase there re: the SELECT new MyClass(…) idea — that won’t work for calling a sproc; I seem to have conflated two separate issues in my reply.

Glad you got it working otherwise; sorry for the misdirection there; lost my head 🙂