Friday, April 25, 2008

NHibernate errors: 101

We seem to be having a bit of trouble with NHibernate of late. Below are some basic check and strategies to get the most out of the ORM. This document is very basic but covers 90% of the issues I have had to fix with NHibernate on this project. For some background i believe I am the only one to have work with NHibernate previously and had come in well after the DAL had taken shape, so some basic mistake have been uncovered as part of our learning process.

Basic checks
Check Mapping files are embedded resources (right click the file in VS and select Properties. Ensure the build action is Embedded Resource)

Check the class is marked as Serializable

public class Customer : DomainEntity<int>, ICustomer

Check the properties are Virtual

public virtual Orders Orders
return this._orders;
this.orders = value;

Lazy loading exceptions

Check the object loaded is occurring in a session correctly and the session is being properly closed & committed
Check the mapping for the object and the children you are trying to load. If the Mappings are set to lazy=true, you will have to explicitly load them or access a property on the object to hydrate the object graph to the next lazy node down the object graph.
Check your session is not closing prematurely, either by code or by an internal error such as DB timeouts. Nested session will all be committed at the committing of the upper most transaction. Be wary of overly nested transaction as this may lead to time out and a possible “number of connection/cursor” exceptions throw from the database or it drivers.

Concurrency Issues
NHibernate is finicky with objects being loaded multiple times and associated in different sessions. This (in my cases) has usually come down to poorly factored code. E.g. Make sure you are not trying to put the same object in to a collection twice from 2 different sessions etc. I don’t have any great advice here as this is usually handled on a case by case basis, but is a good sign you need to rethink your design.

Rules of thumb
Reference data should be cached, immutable and eager loaded. This makes the pretty basic assumption that no relationships exist off to other objects (i.e. no children or other mapped entities)
Complex domain data should generally be lazy loaded, immutable and not cached. You can set up lazy/eager loading strategies on a per property basis. Eager loading simple types is fine, be careful with complex relationships as you should be catering for the most minimal requirements. Excessive use of eager loading will severely affect performance.
Again, be careful with eager loading. If you eager load a child there may be any number levels of eager loading down the object graph. Eager loading should generally be avoided unless there is a business reason to do so. Instead explicitly load each object or object collection explicitly in the business code that deals with the situation, ie

//this occurs with in a session to get all the Orders of the given customer

this.TheOrderDao.Initialize(customer.Orders); //Using NHibernateUtil.Initialize

Preferentially walk the object graph as opposed to using find by id or overly simple HQL. I.e. to get the customer orders use customer.Orders as opposed to a query that looks for order based on a customer ID. NB: This must be done in-session if objects are marked as lazy.
Use ICriterion styled searches to do simple object searches, ie: Find all customers with city location of London
Use HQL queries to get type objects back from queries. These are general object based queries where a collection of a mapped type is returned but may need other joined tables for querying purposes. Ie return all the product categories for all the orders of customer x for the last 365 days. These queries can usually be though of as follow the format select customer.* from customer inner join….
Only use stored procs for set based queries to
aid in speed if walking the object graph would be extraneous or load too much redundant data
to return streamlined DTO/DataSet for non type queries or queries that would otherwise return overly large object graphs when only a small portion of the graph is required. (These are the exception rather than the norm.)



Wednesday, April 23, 2008

TFS: some one needs a kick in the pants

Brilliant TFS... why not just say"Something broke.. fix it yourself" or something equally useless.
*there are no validation errors on any of the inputs and the check in policies have "all been met".
Crap code M$.
Bad M$! Naughty!

Greenfields project

I am setting up a Greenfields ASP.Net service based app for a "friend". It is not completely a self less act. The work I do on a day to day basis bores me to tears so this is an opportunity for me to play with new tools, frameworks ideas etc and stop me hating being a coder.

Also as a contractor I often come in after the initial set up has occurred, which means I suck at setting up solutions. I am using the TreeSurgeon project and Mike Roberts article to guide into best practise here. So have a single batch file to call a single NAnt build script to build and test all my stuff. As there are a bunch of empty projects and empty tests this is pretty bloody fast!!! LOL

So straight off the bat I have in my Development IDE
  • VS2005 (waiting form my copy of 2008)
  • TestDriven.Net
  • Ghost Doc
  • ReSharper (old but still happy with it as i am not 3.5 yet)
.Net aspects I am using
  • WCF
  • Old Skool WebForms. the first Web layer will probably be throw away especially as it uses AP.Net Security which doesn't suit the requirements. I may move to MVC later, but I honestly have never had issues with WebForms mainly because everything I usually kept very simple. Plus i wasn't TDD last time i did a web app, certainly not in the web projects at least.
  • SQL 2005

Frameworks I am using
  • Castle stack for IOC & AOP
  • NHibernate 2.0 (alpha)
  • MBUnit (because i haven't used it)
  • Rhino Mocks (because i am yet to use it properly), possibly TypeMock too for odd stuff
  • Nlog/Log4net... who cares some sort of logging... actually probably L4N as it is in other assemblies already.
Deployment and source control
  • NAnt 0.86
  • SVN
  • CC.Net or Team City. Not set up yet.
  • for svn and project management
Quality Control Tools
  • FX Cop
  • NDepend
  • NCover
  • Sandcastle
and would like to use Spec# but its too much of a hassle to have it in "real" code.
I think that pretty much covers it.

I am keen to discuss lot of the architectural side of things in weeks to come. I am probably going post a few of the questions on the altdotnet list (yahoo group) too.


Monday, April 21, 2008 Lessons for 'tards

What I learned:
-TDD is not as simple as it seems. There are many approaches, frameworks, & schools of thought. MBUnit, TypeMock, MoQ need a decent looking at by yours truly and delve a bit deeper into RhinoMock and NSpec.
-There are some real smart in this movement. The Distributed Domain Driven Design session with the likes of Udi, Martin, Greg, Drew and Alan(?) etc. was awesome.
-Understanding other languages helps you understand the benefits and limitations of "your" language that much better. I really need to play more with Ruby, Python, F#... just something... anything!
-Spec# should not be know as Spec# it should just be C#. This, IMO is f*&king ridiculous. These guys are working hard to help us improve the the code at design, compile and runtime... why would we all not want this? IF this can be pushed into the C# 3.5 then just make it part of .Net 4.0.....Anders: Make it so!!!!!
-Hansleman is not only a sharp witted & entertaining guy but is smarter than a lot of his podcasts let on. (Are you dumbing this down for us Scott? ;) )
-We need to bottle the water in Israel and Austin TX and combine it and include it in your MSDN subscription... they are hubs for smart dudes.
-Everyone was a lot nicer than I expected.. even Bellware (jokes!)... I hope this continues as it was a big nice warm fuzzy environment :).
-Special note goes to Glenn Block from Patterns and Practices. Kudos for jumping in the firing line and being prepared to take flack... even if the products are well before his time. I hope that very open and receptive attitude continue amongst the PnP team :)

*Oh.. the tard is me

Post Alt.Net

Well I have arrived pretty late in London after delayed flights and nasty Heathrow.. so going to work is off the cards... sorry John...

I just wanted to say a quick thanks to everyone involved in organising the event and a special thank to the people who took the time out to share knowledge with me, debate and talk about the virtues of a diet high in salt sugar fat and volume...
particularly: Ian, Tim, Chris(es), Jarod, Jason, Ray(s), Roy, Scott(s), Udi, Martin, Greg, Dru et al
Thanks for everything hope to see you all in the near(ish) future; keep in touch!

For those that didn't attend, you missed out. The stuff learned was the stuff you needed to learn. the people you meet are the people you need to meet. This is better than Tech-Ed because you are the ... if only we got free stuff... actually we did! Cheers Roy!

Friday, April 18, 2008

Alt.Net day 1

End of day one here in Redmond... only 2 hours of actual time and already I am well impressed by the amount of knowledge. A fish bowl session started with C# and it running improvments and possible moves into dynamic aspects.... moving into general talks about languages, their place in a project, stack and programmer general arsenal.
Its also nice to see all these uber smart guy being respectful enough to each to let every one and any one have their say... hopefully this last the weekend!
So far have jumped into the edge of some conversations with the architects of the moment Mr Fowler and Mr Dahan... very cool.

am shattered so off to bed.

Thursday, April 17, 2008

Redmond... Hey-O!

Well I have arrived in little old Redmond (next to Seattle), the home of M$ ready to see what happens in this weekend.
Redmond itself is pretty small and quaint. Oh and its raining. Apparently this is not uncommon. No worries, I'll be inside most of the time any way.

Friday, April 11, 2008


My ignorance of stuff often astounds me. My complete lack* of understanding of data binding on the UI is hilarious. Our UI guy just schooled me on it and I am very impressed. Just another reason why I think coding in layers is best. We work in verticals so my ui stuff sucks compares to his.. please just leave me in the back end server side stuff. Obviously one could argue that working in verticals means we get exposed to these concepts, but i would rather that be done more formally in weekly code/nerd talks where the UI guy gets up and does a Data binding or Win UI Validation talk , in the same way i do TDD, or WCF or Nhibernate...

OK, not “complete lack”, more “prematurely dismissive” notion ;)

Thursday, April 10, 2008

NMock2 RemotingException

Test method XyzUnitTest.TestSomething threw exception: System.Runtime.Remoting.RemotingException: ByRef value type parameter cannot be null.

It turns out that this is caused by not having a return value in the expectation when returning a primitive:

The line of tested code that was failing:

int id = this.Foo.GetId(arg1, arg2, arg3);

The expectation that was causing the failure in the test code was:

Need to be changed to:

I think this is especially important as a (non nullable) int is being returned so the proxy is treating it as byref, hence it can not be null. This may have been missed if it was returning a object as a null object can be returned in this scenario.