Peter's Gekko

Nhibernate and medium trust

pvanooijen — Fri, 09 May 2008 13:35:14 GMT

Being sick of all the hassles it took to keep my own server up and running I've moved it to a public hoster. Which does offer asp.net hosting but like many others code is only given medium trust. My site was using nHibernate. That does have serious problems under this trust level. I've been investigating and experimenting to get it up and running. Alas without success. Nevertheless a summary of what I've done. As most web references on this subject are either vague or not specific enough this can help get a better overview. Or perhaps somebody can point me to something I have overlooked.

Medium trust restricts the permissions given to your code. When googling a lot of the links mention the error message That assembly does not allow partially trusted callers. You can get it when you sign the assemblies of your site. It depends on your hoster. You used to get that when hibernate tries to load a signed assembly with your domain objects. This can be fixed by setting the AllowPartiallyTrustedCallersAttribute on the loading assembly. This has been fixed on the recent production build of nHibernate; a lot of the posts still around deal with a previous version of nHibernate and are a dead end.

The main problem with medium trust is that it inhibits reflection. nHibernate depends heavily on reflection. For lazy load to work nHibernate generates proxies to the domain objects. These proxies are built by reflecting on the domain objects. You can configure nHibernate to work without lazy loading. I gave this path a full try and tried everything I could find on the web and could think of myself.

This is what I did to the configuration

Apply the requirepermission="false" in the web.config section of nHibernate
Set the hibernate.use_reflection_optimizer in the web.config to false
Set the hibernate.bytecode.provider in the web.config to null.

This is what I did in the mapping files

Set the lazy attribute of all classes to "false"
Set the lazy attribute of all collections to "false"
Remove the proxy attribute of all classes

In the domain classes I even made all public members non-virtual. In a normal scenario nHibernate will now completely trip over this, complaining it cannot create a proxy.

On my local machine the site still worked. But on the medium trust host it immediately crashed again on a security exception. The stack trace pointed to the initialization of the reflection optimizer. Huh ? This is where I gave up.

There is an approach on the web which promises a working lazy load even in medium trust. It is supposed to work by replacing the proxyfactory by one which provides pre generated proxies instead of generating them on the fly via reflection. Alas providing you own proxyfactory takes nHibernate 2.0. Which is still in alpha phase. From a maintainability point of view beyond consideration.

Googling around getting nHibernate to work under medium trust is considered important but still takes a lot of effort, also in 2.0. I really hope it is going to work but for me it's back to basics for this project. Not all work has to be done again, the domain model is clear, all I have to do is rewrite the implementation of the repositories. To the UI it's not important how I gets the data as long as it gets them.

The main reason for needing persistence on my site is an index on a selection of my publications. Reading through the results it sometimes does make my toes curl. A lot of the work is pretty old by now and my techniques have really grown over the years. Time for a good update of the contents of the underlying db.

Domain-Driven Design: Reading toward deeper insight

pvanooijen — Mon, 05 May 2008 12:48:33 GMT

On almost every family holiday I take a good book. Not being distracted by the continuous flow of the Internet and with enough time to let stuff sink in, holiday time makes a good time to see things in perspective again and come home with a fresh mind full off ideas. Last time this worked very well to give myself a real boost on building enterprise applications domain-driven style. Jimmy Nilsson's Applying Domain-Driven Design and Patterns was a quite pragmatic coding based approach which really accelerated my way of building applications. So this time I considered it time to finally do a thorough read of Eric Evans's bible of DDD

There are plenty of reviews on the web, on Amazon alone you will find loads and loads of information on it's content and value. Besides that it has a website. Fragments of it's content is found in so many posts on Codebetter that it almost seems implicit knowledge over here. But as I enjoyed it that much I would like to draw some more attention to this modern classic itself.

Inside you will not find a lot of code. Besides that all code is Java code; the .net platform is not even mentioned once. The book is about the essentials of code. All revolves around one central object oriented domain model. A model which serves the developer to write the implementation but it is also a model which speaks the language of the domain expert who understands the required functionality of the software. The model is described in an ubiquitous language whose meaning is understood in the same way by all team members and so serves good communication. By refactoring the developer as well as the domain expert work in cooperation on the same model. This may sound somewhat vague but chapter by chapter all aspects, from database persistence to a vision statement come by including very clear examples. Reading gave me many points of recognition as well as some aha-moments. A very pleasant moment was the conclusion of part 3, Crisis as an opportunity, where Eric mentions "punctuated equilibria", the (r)evolutionary model of a recent rant of mine. How a domain model can evolve over time also fits perfectly in that story.

At first I only felt sorry I had waited that long to start reading (or going on a holiday :)). The book is written very clear, does give a great overview of the subject and is very systematic in making its point. It is absolutely a classic that every developer, architect (is there a real difference ?) or anyone else who is involved in building software should read. Not everybody does agree on this, between all the five star reviews on Amazon you will find some less enthusiastic ones. So, on second thought, I would not always recommend this book as a starting point for DDD. In case you have troubles reading it start Jimmy Nilsson's Applying DDD and patterns and make sure you really start doing some hands-on DDD stuff yourself. And sooner or later you will really appreciate this book as it will structure all you've read and done back into one clear and flexible model. And that's what DDD is about.

And now you should start reading it yourself.

Jimmy Nilsson is coming to the Netherlands

pvanooijen — Mon, 07 Apr 2008 11:32:31 GMT

Coming april 24th Jimmy Nilsson will be speaking for Dutch user group dotNed. Jimmy is well known for his book Applying Domain-Driven Design and Patterns. A very good aspect of this book is it's style: very easy going and a pleasure to read; but in the meantime you're learning a lot. My first read was on a holiday; on a quite camping place in France. The bad thing about the coming presentation is that it's during another holiday. While Jimmy is talking me and my family will be somewhere half way between home and a sunny Greek island. Mixed emotions.