Archive for the ‘NHibernate.Remote’ Category

Unit tests, FTW!

Wednesday, June 18th, 2008

I’ve been working on an inventory system for my company and have been encountering a serious amount of resistance from both my neurons and the problem at hand.  So I’m giving the old noggin a brief respite and I’m back to working on NHibernate.Remote.  However my forray into inventory land has taught me some valuable lessons.

  1. Dependency injection is fun, and very usefull when used right.  I’m using the Castle Windsor framework and it seems to be working very well.
  2. Unit tests work and are necessary to ensure proper functioning of your software.

Now some of you may be spewing coffee right about now after reading number 2, because unit tests just seem like such a no brainer right now.  However <whisper>I’m the only one in my company who does them</whisper>.  Anyhow, I am convinced of the need for good unit tests if not completely ready to go straight to TDD.

Anyhow the point of this story is that I am taking some time to write unit tests for NHibernate.Remote, and I expect to find lots and lots of bugs.

Development continues

Tuesday, May 20th, 2008

It looks like development on NHibernate.Remote will continue at least on the short term. After doing a significant amount of research I came to the conclusion that while the IdeaBlade Devforce framework is a great product we probably won’t be moving to it anytime soon.  The reason stems mainly from the fact that the upcoming DevForce versions will be based on the Entity Framework, and to do so means dropping some really attractive features from their platform.  I am interested to see if/when they achieve feature parity with their previous versions.

In the meantime work will continue on NHibernate.Remote  with priority on the stability of the connection.   I am looking into seeing if there is merit to going with a fully disconnected model instead of relying on tcp sessions to keep an active connection.  Any suggestions?

Sidetracked on Evaluation street

Friday, May 9th, 2008

Sorry I havn’t been doing many updates the last couple of weeks.  While wrestling with some issues with NHibernate.Remote I ran across a project called DevForce by a company called IdeaBlade.  This is a mature enterprise level software package that accomplishes many of the things that I set out to do with NHibernate.Remote.  It is also very expensive.  Because the company that I work for is severely undermanned in the programming dept, I have been evaluating this option too see if this would work for our systems.  I’m not sure yet how it will turn out but I will keep you all aprised of the situation.  If we decided to purchase this package it would most likely mean the amount of time I have to devote to NHibernate.Remote would be severely limited. 🙁

High hopes, and crushed dreams

Tuesday, April 15th, 2008

I think that there is a fundamental law of the universe at work in programming, and it goes something like this.  “Everything is much harder than it looks at first glance.”

My troubles started when I decided that I needed a custom serializer or at least some serialization extension points in order to better optimize the way that NHibernate.Remote transmits its data.  Currently I am letting the NetDataContractSerializer do all the work and I am using reflection later to walk the object graph and do things such as update the session on lazy items and synchronize objects that are supposed to be reference equal.  All in all it’s a lofty goal.

I began to dig into the serialization mechanism to look for extension points in the NetDataContractSerializer.  To my dismay though, most of the applicable classes were internal, sealed or didn’t contain anything usefull.  I thought I was out of luck until I came upon Serialization surrogates.  In effect this allows you to attach a serializer/deserializer to an object type (or all object types) and push part of the serialization process through your own code.  This was really close to what I wanted as it would allow me to examine individual objects as they were being serialized and deserialized.  This would mean no more walking the object graph and should net a nice little performance gain.  Yes? actuall NO.

After wiring in some loose code to extract object data and such I tested it to see if it would actually work.  It actually did work, amazing.  Then I fired up Ants to see what the performance was, and to my dismay it was 26x slower.  This was for sure not acceptable as I was hoping to see a performance gain.  I did a more detailed analysis using Ants to figure out where my code went wrong and to my amazement it was not in my code but in MS’s NetDataContractSerializer.  The  SurrogateDataContract which is responsible for getting the data to my custom SerializationSurrogate is incredibly slow, and it doesn’t look as if there is anything I can do about it.

Sigh… So I’m back to square one here.  Leave the reflection code in place as it is already working,  write my own serializer from scratch (Bleh), or start emitting IL code to hack the NetDataContractSerializer?

Back at it.

Wednesday, April 9th, 2008

I’m back from Vacation.  It was awesome but I won’t bore you by blogging about it here.  Many thanks to my wife for draging me out of my comfort zone and widening my view of the world.

Ok so there have been several minor updates to the source.  I have changed some things so that the project is now building against alpha 1 of NHibernate 2.0 rather than compiling against the latest NH subversion repository.  Hopefully this will make my dev process a bit more stable.  I will continue to build against the latest NH releases untill 2.0 is released officially.   I have also fixed a couple of bugs including a nasty collections bug in the DeepSynchronizer.

My main goal now is to continue work on the custom serializer to elimitate a lot of reflection and to improve stability.