OpenNETCF ORM Implementation Update

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:

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.

2 thoughts on “OpenNETCF ORM Implementation Update”

  1. Dear Chris,

    I am just starting to look at your ORM infrastructure, because I worked on clumsy database setup procedures (connect, executequery, read, close…) for years, and I guess whether there is a different way to work. The opennetcf ORM seems simple and clean, but I have a question.
    I usually work with DataGrid taking as source data DataTables filled by queries: which approach would suggest for filling DataGrids through opennetcf ORM?



  2. @Filippo: The ORM returns arrays (or IEnumerables) of your entity classes. Just use those as the DataSource in the binding. Personally I’d use a Presenter/ViewModel in between the data and the UI and probably provide a directly bindable property that gives access to the data.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s