CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Peter's Gekko

public Blog MyNotepad : Imho { }
  • Nhibernate and medium trust

    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.

    Posted May 09 2008, 03:35 PM by pvanooijen with 1 comment(s)
    Filed under:
  • Domain-Driven Design: Reading toward deeper insight

    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

    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.
  • Wrapping up nHibernate in repositories

    In my last post I discussed wrapping up the two core objects of nHibernate, the sessionmanagerfactory and the session, in a helper class. At the end of the story I briefly mentioned how to use helper objects in a repository. In this post I am further exploring the actual database actions of the helper and how this helper can be used in real repositories in a "regular" DDD style. Again, don't take this as the way to do things. The web is covered with a lot of ways to get that done and there are several tools available. This is just a minimalistic way which works well for me and does demonstrate some programming ideas. Feel free to comment.

    The previous post discussed a way to manage nHibernate sessions. All data operations are performed on such a session. The major operations are described in this interface

    public interface INhibernateHelper : IDisposable

    {

        IQuery Query(string query);

        T UniqueResult<T>(IQuery query);

        IList<T> ListResult<T>(IQuery query);

        IEnumerable<T> EnumerateResult<T>(IQuery query);

        void BeginTransAction();

        void Commit();

        void Save(object dObject);

        void Delete(object o);

    }

    The main reason for describing the functionality as an interface lies in testing; an interface is relatively easy to mock.

    The members which return data are defined as generic methods; this gives me the luxury of strongly typed data. At first sight it might be tempting to make the interface itself generic, that is:

    public interface INhibernateHelper<T> : IDisposable

    {

        T UniqueResult<T>(IQuery query);

    }

    But that will backfire when implementing the interface. To manage a shared sessionfactory I am using a static constructor. As every specific type instance of a generic class fires its own specific static constructor the sessionfactory can no longer be shared over different classes. Having only the methods themselves generic will do.

    When it comes to writing to the database it is important to realize the way nHibernate works. Invoking Save or Delete will not immediately persist that data. It takes the session's Flush method to trigger that. When flushing the data your objects will not always be persisted in the same order as the Save and Delete invocations. Things are further complicated because nHibernate will sometimes perform an implicit flush when querying to prevent returning stale data.

    On a session you can start a transaction but you can only start one transaction on every session. In my implementation of transactions I'm very forgiving. BeginTransaction can be invoked again and again; the first invocation will start the nHibernate transaction. A Commit is always honored; in case no transaction was started the helper will just flush the data.

    The main things when implementing all members is to take care of exceptions. A session cannot recover from an exception. In case you hit one the only solution is to close the session.

    internal class NhibernateHelper : INhibernateHelper

    {

        private static readonly ISessionFactory sessionFactory;

      

        static NhibernateHelper()

        {

            Configuration cfg = new Configuration();

            IDictionary props = new Hashtable();

            props.Add("hibernate.dialect", "NHibernate.Dialect.MsSql2000Dialect");

            props.Add("hibernate.connection.provider", "NHibernate.Connection.DriverConnectionProvider");

            props.Add("hibernate.connection.connection_string", nHibernateConnectionHelper.connectionString);

            cfg.SetProperties(props);

            cfg.AddAssembly(nHibernateConnectionHelper.domainAssembly);

            sessionFactory = cfg.BuildSessionFactory();

        }

      

        private static string connectionString

        {

            get

            {

                Type typeOfConnectionProvider = typeof (NHibernate.Connection.DriverConnectionProvider);

                PropertyInfo ConnectionStringPropertyInfo = typeOfConnectionProvider.GetProperty("ConnectionString",

                                                                                                BindingFlags.Instance | BindingFlags.NonPublic);

                return (string) ConnectionStringPropertyInfo.GetValue(sessionFactory.ConnectionProvider, null);

            }

        }

      

        private readonly ISession currentSession;

      

        internal NhibernateHelper()

        {

            if (string.IsNullOrEmpty(nHibernateConnectionHelper.connectionString))

                throw new Exception("Sessionfactory needs a connectionstring");

            if (nHibernateConnectionHelper.connectionString != connectionString)

                throw new Exception(string.Format("Sessionfactory connection allready initialized as {0}",connectionString));

            currentSession = sessionFactory.OpenSession();

        }

      

        private ITransaction tx = null;

      

        public void BeginTransAction()

        {

            if (tx == null)

                try

                {

                    tx = currentSession.BeginTransaction();

                }

                catch (Exception)

                {

                    currentSession.Close();

                    throw;

                }

        }

      

        public void Commit()

        {

            if (tx == null)

            {

                try

                {

                    currentSession.Flush();

                }

                catch(Exception)

                {

                    currentSession.Close();

                    throw;

                }

      

            }

            else

            {

                try

                {

                    tx.Commit();

                }

                catch (Exception)

                {

                    tx.Rollback();

                    currentSession.Close();

                }

                finally

                {

                    tx = null;

                }

            }

        }

      

        public IQuery Query(string query)

        {

            return currentSession.CreateQuery(query);

        }

      

        public void CloseSession()

        {

            currentSession.Close();

        }

      

        public void Save(object dObject)

        {

            try

            {

                currentSession.SaveOrUpdate(dObject);

            }

            catch (Exception)

            {

                currentSession.Close();

                throw;

            }

        }

      

      

        public void Delete(object o)

        {

            try

            {

                currentSession.Delete(o);

            }

            catch (Exception)

            {

                currentSession.Close();

                throw;

            }

        }

      

        public void Dispose()

        {

            currentSession.Dispose();

        }

      

        public T UniqueResult<T>(IQuery query)

        {

            try

            {

                return query.UniqueResult<T>();

            }

            catch (Exception)

            {

                currentSession.Close();

                throw;

            }

        }

      

        public System.Collections.Generic.IList<T> ListResult<T>(IQuery query)

        {

            try

            {

                return query.List<T>();

            }

            catch (Exception)

            {

                currentSession.Close();

                throw;

            }

        }

      

        public System.Collections.Generic.IEnumerable<T> EnumerateResult<T>(IQuery query)

        {

            try

            {

                return query.Enumerable<T>();

            }

            catch (Exception)

            {

                currentSession.Close();

                throw;

            }

        }

      

    }

    When hitting an exception all this helper does is clean up after which it rethrows the exception, it's up to its user to take further action.

    All database interaction through nHibernate is now stuffed in this helper class. It can be used by a generic repository.

    public class Repository<T>

    {

        private readonly INhibernateHelper hibernate;

        private readonly string className;

      

        public Repository(INhibernateHelper hibernate)

        {

            className = typeof(T).Name;

            this.hibernate = hibernate;

        }

      

        public IQuery BuildQuery(string queryString)

        {

            return hibernate.Query(string.Format("from {0} where {1}", className, queryString));

        }

      

        public IList<T> ListAll(string orderBy)

        {

            string queryString = string.Format("from {0} order by {1}", className, orderBy);

            IQuery query = hibernate.Query(queryString);

            return hibernate.ListResult<T>(query);

        }

      

        public IEnumerable<T> EnumerateAll()

        {

            string queryString = string.Format("from {0}", className);

            IQuery query = hibernate.Query(queryString);

            return hibernate.EnumerateResult<T>(query);

        }

      

      

        public IEnumerable<T> EnumerateInPeriod(string propertyName, DateTime from, DateTime till)

        {

            if (from == DateTime.MinValue)

                from = new DateTime(1753, 1, 1);

            if (till == DateTime.MaxValue)

                till = new DateTime(9999, 12, 31);

            string queryString = string.Format("from {0} where {1} >= ? and  {1} < ?", className, propertyName);

            IQuery query = hibernate.Query(queryString);

            query.SetDateTime(0, from);

            query.SetDateTime(1, till);

            return hibernate.EnumerateResult<T>(query);

        }

      

        public T FindUnique(string propertyName, string propertyValue)

        {

            string queryString = string.Format("from {0} where {1}=?", className, propertyName);

            IQuery query = hibernate.Query(queryString);

            query.SetString(0, propertyValue);

            return hibernate.UniqueResult<T>(query);

        }

      

        public T FindUnique(string propertyName, long propertyValue)

        {

            string queryString = string.Format("from {0} where {1}=?", className, propertyName);

            IQuery query = hibernate.Query(queryString);

            query.SetInt64(0, propertyValue);

            return hibernate.UniqueResult<T>(query);

        }

      

        public T FindUnique(IQuery query)

        {

            return hibernate.UniqueResult<T>(query);

        }

      

        public void Save(T domainObject)

        {

            hibernate.Save(domainObject);

        }

      

    }

    The repository receives the helper in its constructor. In a test scenario I can inject mocked persistence here. My repository has methods to retrieve and update data. Quite straightforward ones like ListAll and more fancy ones like EnumerateInPeriod. It's up to you to fulfill your specific needs. To build the hibernate queries the name of the class is needed. In the constructor this name is pulled from the Type parameter.

    Here's an example how to use this repository. Given this domain class:

    public class School : ValidatableDomainObject

    {

        private int id;

        private string omschrijving;

      

        private static string noSchool = "Geen binding";

      

        public virtual int Id

        {

            get { return id; }

            set { id = value; }

        }

      

        public virtual string Omschrijving

        {

            get { return omschrijving; }

            set { omschrijving = value; }

        }

      

        public static string NoSchool

        {

            get { return noSchool; }

            set { noSchool = value; }

        }

      

        protected override void DoValidate(RepositoryManager repositoryManager)

        {

            validateExpression(!string.IsNullOrEmpty(omschrijving), "Naam school ontbreekt");

        }

      

    }

    A simple class with some properties and it does validation. A repository for this class will now look like:

    public class SchoolRepository : Repository<School>

    {

        public SchoolRepository(INhibernateHelper hibernate)

            : base(hibernate)

        {

        }

      

        public School OpAfkorting(string afkorting)

        {

            return FindUnique("omschrijving", afkorting);

        }

      

        public School GeenBinding()

        {

            return OpAfkorting(School.NoSchool);

        }

      

    }

    No big deal; there are two School specific members. The base Repository class does the hard work.

    Now I can create a repository for every domain class in the application. To manage all of these the app needs a RepositoryManager. This class takes care of creating the hibernate helper and creating specific repositories on demand. This example is a part of such a manager; for the sake of demo it only includes two repositories. All others will follow exactly the same pattern.

    public class RepositoryManager : IDisposable

    {

        private static string dbConnection = "";

        public static string DbConnection

        {

            get { return dbConnection; }

            set { dbConnection = value; }

        }

      

        private readonly INhibernateHelper nhHelper;

      

        private PersoneelRepository personeel;

        private SchoolRepository school;

      

        public RepositoryManager()

        {

            string assemblyName = Assembly.GetExecutingAssembly().FullName;

            nhHelper = NhibernateHelperFactory.CreateHelper(dbConnection, assemblyName);

        }

      

        public void BeginTransAction()

        {

            nhHelper.BeginTransAction();

        }

      

        public void Commit()

        {

            nhHelper.Commit();

        }

      

        public PersoneelRepository Personeel

        {

            get

            {

                if (personeel == null)

                    personeel = new PersoneelRepository(nhHelper);

                return personeel;

            }

        }

      

        public SchoolRepository School

        {

            get

            {

                if (school == null)

                    school = new SchoolRepository(nhHelper);

                return school;

            }

        }

      

        #region IDisposable Members

      

        public void Dispose()

        {

            nhHelper.Dispose();

        }

      

        #endregion

    }

    To store the database connection string there is a static member. On application setup it has to be initialized just once. The constructor uses the helperfactory discussed in the previous post. This manager is in the domain assembly which also contains the hibernate mappings themselves; the name of that assembly is needed for the nHibernate configuration and can be read using the GetExcutingAssembly method.

    The repositories all share the same session wrapped up in the helper. Transactions are managed at this level. And so a transaction easily spans objects from several domain classes. The helper has to be disposed to clean up the session. The repository manager implements Idisposable and will clean up the helper in its implementation of Dispose.

    Let's see it in action

    using(RepositoryManager repoManager = new RepositoryManager())

    {

        repoManager.BeginTransAction();

        School mySchool = repoManager.School.OpAfkorting("BADM");

        IEnumerable<Personeel> persList = repoManager.Personeel.EnumerateAll();

        foreach (Personeel personeel in persList)

        {

            if (personeel.IsValid(repoManager) && (personeel.UitDienst))

            {

                personeel.VerbondenAanSchool = mySchool;

                repoManager.Personeel.Save(personeel);                       

            }

        }

        repoManager.Commit();

    }

    In one transaction I update all "personeel" which meets certain criteria. Note that I pass the repository-manager to the validation method. The validation can use it to do things like data look up.

    Well that's about it. I do hope this provided you with some insights on a way to use nHibernate in a DDD project.

  • Wrapping up nHibernate

    In a relative short span of time nHibernate has become a major member of my toolbox. It has become the way to work with a database, not only a small hap-snap apps but it's also making big strides into a constantly evolving system I'm working on. Setting up nHibernate several times has given me the opportunity to do some playing around. Browsing around you can find several ways to do it, some ways just focus on getting it done, some ways focus on performance, and some ways focus on resource management. Here I would like to discuss my way where I tried to take all aspects in account. Don't take it as the way; please do share your thoughts.

    <update>After a very good comment by rui I have corrected some of the code for the repository part. Thanks ! Blogging is just the best public code review you can get :)</update>

    Code will work with two very important nHibernate objects

    • The sessionfactory. This object swallows the configuration, from the mappings to the connectionstring to the database. Instantiating it is quite a job as it has to parse all mappings and check for corresponding domain classes. The good thing is that it will actively check all mappings; when the sessionfactory is successfully instantiated you know you're more than halfway. (Note that the sessionfactory does not check the database, in case there are errors in columns names of the mappings or in the connectionstring your code will not hit an exception until it actually tries to connect to the database). The sessionfactory is thread-safe all your code can work with one and the same sessionfactory. And as it is expensive to create the thing it pays off to create it only once.
    • The session. The sessionfactory provides you with session objects to work with the database. A session wraps up an actual connection to the database, so it holds an expensive unmanged resource. The mantra for "classical" ado.net code was always to open the connection as late as possible and to close immediately after firing your sql. More details on that here. The nHibernate sessionfactory provides session objects containing an open connection to the database. The session object has a method to close the connection, but there are several reasons not to do that. The most obvious one is lazy loading. For example when you load an invoice object from the database nHibernate will not load the data of the associated customer until your code actively touches the customer's properties. In case your code doesn't touch the customer the data will not be loaded. To load the data from the database nHibernate needs an open connection. In case you had already closed the session your code will hit a LazyLoadException. So a session object holds an open connection to the database, which requires extra care.

    I'm going to manage both the sessionfactory and the session in one nHibernateHelper class. The code needs only one sessionfactory, which has to be instantiated once. The sessionfactory is going to be a static (shared) member of the class. I took the idea to instantiate the sessionfactory in a static constructor from an nice article on theserverside. A static constructor fires the moment the class is loaded. That is the moment the class is first touched by running code. In the original code the configuration is loaded from a configuration file. My problem with that is that I want to be independent from that for reasons of testability and custom configuration. Most settings can be hard coded but something like the database connectionstring has to be set from code. A static constructor does not have any parameters and I can not set any members, the moment I touch the class the static constructor fires first and I'm too late. What does work is a small helper class.

    internal class nHibernateConnectionHelper

    {

        internal static string connectionString = "";

    }

      

    internal class NhibernateHelper : INhibernateHelper

    {

        private static readonly ISessionFactory sessionFactory;

      

        static NhibernateHelper()

        {

            Configuration cfg = new Configuration();

            IDictionary props = new Hashtable();

            props.Add("hibernate.dialect", "NHibernate.Dialect.MsSql2005Dialect");

            props.Add("hibernate.connection.provider", "NHibernate.Connection.DriverConnectionProvider");

            props.Add("hibernate.connection.connection_string", nHibernateConnectionHelper.connectionString);

            cfg.SetProperties(props);

            cfg.AddAssembly("dlcr.domain");

            sessionFactory = cfg.BuildSessionFactory();

        }

     

    When the nHibernateConnectionHelperClass is touched first the static constructor of the NhibernateHelper class reads the updated connectionstring. It is used like this:

    public class NhibernateHelperFactory

    {

        public static INhibernateHelper CreateHelper(string dbConnection)

        {

            nHibernateConnectionHelper.connectionString = dbConnection;

            return new NhibernateHelper();

        }

    }

     

    Now the static constructor works as intended. This trick also works when both classes are in the same cs file. How the sessionfactory itself is set up is in a previous post.

    With the sessionfactory ready the nHibernatehelper can start its core business: managing a session. A new session is instantiated and opened in the instance constructor. This constructor performs some checks whether the sessionfactory will provide a session with the expected database. It reads the connectionstring from the sessionfactory property as described in the previous post.

    internal NhibernateHelper()

    {

        if (string.IsNullOrEmpty(nHibernateConnectionHelper.connectionString))

            throw new Exception("Sessionfactory needs a connectionstring");

        if (nHibernateConnectionHelper.connectionString != connectionString)

            throw new Exception(string.Format("Sessionfactory connection allready initialized as {0}",connectionString));

        currentSession = sessionFactory.OpenSession();