I’m been maintaining and expanding the OpenNETCF ORM code base for quite some time now and it’s becoming pretty robust. We dogfood it heavily and have a variety of application installs using it for all sorts of things, from local apps to M2M solutions. One key tenet I’ve been following is that I opt for portability over expansive features support. Some features that you might think an ORM would have are very difficult to do in a generic way that would support both RDBMS systems and object or cloud databases. It becomes easier for an application to do those relationships, or for you to (gasp) denormalize your data. For example, composite primary keys are a common request, but it’s a pretty complex thing to implement for an RDBMS, and for an object database, it’s a friggin’ nightmare. It’s a lot easier for me to go do a whole new store implementation and just tell users that they should use surrogate keys. We’re not the only ORM that feels that way, and honestly, I think composite keys are generally a bad idea anyway.
Features have largely been need driven, and by “need” I mean what I need at any given time. I’ve also taken some time to experiment with different backing stores, and it’s led me to have a variety of implementations in different states of “doneness.” For example, I have SQL Compact, Oracle and SQLite at a point I’d call complete, but I have a variety of others that aren’t quite so done. Some are in the public source tree on CodePlex, some haven’t found there way there yet, but probably will when they get further along.
Here’s a complete list of implementations I have worked on, and a rough guess on state of completion. If you’d like to se me work on any one in particular, let me know:
- SQL Server Compact – complete
- SQL Server – complete
- SQLite – complete
- Everyware Device Cloud – 100% complete
- MySQL – 90% complete
- Microsoft Azure Table Services – 90% complete
- Oracle – 80% complete
- Etherios Device Cloud Storage – 70% complete
- Dream Factory Cloud Storage – 50% complete
- Amazon Simple DB – 40% complete
A majority of these (I think all but Oracle) work cross-platform, meaning I’ve tested them on big Windows, Windows CE and Mono under Linux.
A key point here, beyond the cross-platform capability (which was no small effort), is the fact that identical data access code in your application can perform the good old standard CRUD operations on *any* of those data stores. The only code changes needed are setup bits (providing credentials, file paths, etc) that are specific to each store type. Show me any other existing ORM that has even close to this kind of coverage.