That was why it didn't work in the past!

Well I remembered why my application didn't work the first time I tried WPF and just nHibernate. They hate each other! It was the whole reason I had needed to go out and find the wrapper classes. So actually, using the WCF service got me further along, just not far enough along. I can see 2 solutions to this problem:
 - We work around this at work, by creating 2 sets of objects. One used on the server side which are the actual objects nHibernate plugs into and a set of DTO objects that are passed through the service layer. Through the incorporation of some flags the server controls which collections are loaded into the DTO objects.
 - The other solution is to remove the database level or at least the mapping level relationships between the objects and create methods to simulate lazy loading. GetParent() and GetChildren() methods.

The DTO approach we use at work I think is too much overhead in all respects. More code, more classes, more work, more time to per action. At work we have some code generation tools to do the dirty work for us and with the size of the projects the overhead slowly becomes negligible. This project is smaller, so I suppose the solution is to re-engineer using methods to populate the child objects. Which also means that for the sake of simplicity I need kill most or all cascading. One of these days, I would love to create an application that actually makes full use of what nHibernate offers *sigh*.

This may end more as a demo project than a replacement for Veronica's old software.

Comments

Popular Posts