Over Halloween, I was checking out the Orchard application, currently in Beta, that is currently being written as an open-source ASP.NET MVC application by a team at Microsoft. I was getting increasingly impressed with the overall design decisions taken when I suddenly caught, out of the corner of my eye, the dread word "NHibernate.dll". I twitched in an involuntary spasm of apprehension, as if I’d seen an overly-realistic Halloween mask. I didn't mean to, as my rational mind understands that both nHibernate and Entity Framework can be used in an entirely sensible way, by interfacing with a properly-designed database interface built from views, TVFs, and stored procedures (views work best for nHibernate). The Database Developers can then content themselves with constructing a well-indexed, scalable, and secure database behind the wall, with fewer interdependencies. However, these ORMs, by their very nature, can beguile less experienced developers into believing that there really is a free lunch, especially if the ORM is used to 'cut' the database.
A quick look at the database schema that Orchard auto-generated for SQL Server was enough to convince me that, in its present state, Orchard might be OK for a small club, lone blog, or community, but won’t scale, at least not in its present form. The database schema looked as if it had been auto-generated by the ORM. For the DBA, this is scarier than any Halloween monster. There were no constraints at all, only clustered indexes, all using identity columns, and no other index. There was evidence, too, of EAV practices.
I can see why they’ve gone down this design route: it is so that a whole range of databases could be used, including SQL Server CE. The trouble is that it is a design compromise that cuts Orchard, and many other products like it, from use with high-volume applications that require trouble-free security. A lot of hard work has gone into this project, and there are good ideas too; all the more reason that I’d hate to see its versatility so drastically curtailed by a design decision like this.
Phil Factor
