Why I Don't Use an Object Relational Mapper in mojoPortal

This content is under review. It may be out-of-date. If you have questions, please ask in the forums.

People often ask why I do not use an OR Mapper (Object Relational Mapper) such as NHibernate in mojoPortal.  My reasoning for not using one in mojoPortal content management system is as follows:

  • I like to be able to have the option to take advantage of whatever optimizations are supported by the given database.  
  • I think simple straight forward data access code will be better for corporate developers who may wish to use mojoPortal as a starting point for additional development. They will use the version of the data layer for whatever is their standard database and the code they see in mojoPortal will be familiar to them.  I don't want them to have to learn an OR mapper. 
  • Performance is very good on any of the supported databases because of the use of lightweight optimized data access code. There is overhead to using O/R Mappers.
  • Another problem that developers often don't think about when they suggest using an OR mapper in mojoPortal is data access security. I have worked in many places with high security requirements for data and many of the DBAs (Database Administrators) do not allow applications that do ad hoc queries such as those generated by OR Mappers. In these environments all data access must be made using stored procedures which can be vetted and monitored by the DBAs. While we don't use stored procedures in all the database layers, for our flagship MS SQL data layer we use stored procedures so that it is possible to harden an installation by using a database user that has no direct permissions on any tables but only exec permission on all the stored procedures. Of course during installation and upgrades a more privileged user is required so that tables can be created or altered and stored procedures can be created or altered by the installation and upgrade scripts. After intallation or upgrade a less privileged user can be set on the connection string for maximum security. It is important to me that mojoPortal can meet the needs of this kind of environment, and this need has been validated by actual customers who are using mojoPortal and chose mojoPortal over other solutions because of their data security requirements.
  • NHibernate poses challenges running in Medium Trust hosting
  • Theory != Reality. People often think that just because they use an OR Mapper such as NHibernate that they automatically are able to support whatever databases are supported by NHibernate. Theoretically supporting more databases is not the same as actually supporting them, show me any other project that actually supports all the databases platforms that mojoPortal supports. We have real support for all the database platforms that we list as supported. When you have to really support other databases you find there are challenges with using OR mappers and when you first encounter a bug or problem when using a specific database and the issue does not happen under other databases you become stuck because the OR Mapper is a black box and now you have to try to figure out its internals or report a bug to the OR Mapper maintainers and hope it gets resolved for you. Or you may need to maintain different mappings for one database platform vs another which is also more work. When I encounter an issue in any of the database platforms I support it is easy to fix it quickly.
  • This one is more of a personal aesthetic, but O/R Mappers generally like to own the business objects which means you don't really fully abstract the data access code away from the business object code and in fact you often find the business objects must be decorated with data attributes which to me is not pleasing. Others may not have a problem with that but for me it just doesn't seem right.

I'm not saying OR Mappers are bad, I'm just saying it is not the best solution in all cases and for mojoPortal I do not believe it is the best solution.  There are plenty of projects out there that use OR Mappers, so if that is important to you I recommend you use a different project. Note also that in developing custom features for mojoPortal, nothing stops you from using NHibernate or another O/R Mapper in your own development.

I do use code generation to speed up development and this gives me many of the same benefits as using an OR Mapper.


Last Updated by Joe Audette, June 18, 2012