The idea of serializing a factory object (SessionFactory) grates with me. Instinctively it doesn't seem right, but also it will require a public, no-arg constructor and making its public properties read/ writeable.
Another idea for you to consider: If the compiled mapping data could be represented by a serializable object it could be passed to the Configuration object and used to start the factory: CompiledMaps mappings = <<get from database/filesystem/wherever>> var config = new Configuration(); config.AddPrecompiledMaps(mappings); var factory = config.BuildSessionFactory(); In other words, the SessionFactory can be started with uncompiled mapping files (in which case the factory needs to compile them and the performance penalty is incurred), or with precompiled mapping data. To obtain the compiled mappings: CompiledMaps mappings = factory.CompiledMaps; It may not make sense to represent the compiled mapping data as an object if it has no actual behaviours...in which case, the compiled maps could just be exposed as XML. On Feb 6, 10:32 pm, Fabio Maulo <[email protected]> wrote: > 2009/2/6 Tuna Toksoz <[email protected]> > > > My proposal would be to have a STATIC SessionFactory per application, which > > is initialized like the following > > * > > 1. Check if there is a SessionFactory Serialization Binary > > 2. If yes, then check .config file and related assembly Last Modified Date, > > if those are newer than the Serialized factory, then go to step 4. If not > > step 3 > > **3. **Now we have a valid session factory, we can safely deserialize it. > > 4. Means that we either don't have a session factory, or it is pretty old. > > Create the session factory once more, serialize it to the disk.* > > Too many responsibilities for NH. > Considering that, after BuildSessionFactory, you can discard the > Configuration instance what we must do is only ensure that the > SessionFactoryImpl class is serializable and let the user to choose how, > where, when y can save-restore the serialized SessionFactory instance. > > After that, if you want, we can provide a "default" mode implemented in some > Helper class in NH-Core or in NH-Contrib. > -- > Fabio Maulo
