There are a couple of things that have come up recently regarding the dependencies Simple.Data has outside of the Base Class Library (BCL).
I got a shout-out from Rob Conery in his post about his ultra-lightweight data access library file (which is very nice, btw). He suggested that Simple.Data “embraced” WebMatrix.Data, which is not actually the case. Simple.Data has its own adapter and provider model, and the supplied ADO adapter and SQL Server and SQL CE providers are built on top of plain old ADO. It also has its own SimpleRecord dynamic type, as opposed to using ExpandoObject. The SimpleRecord type includes a couple of advanced features for lazy-loading joined data, and convention-based implicit casts to static types.
The important thing about Simple.Data’s adapter model is that, as with the Ruby DataMapper library, it’s pretty straightforward to create adapters which expose non-SQL data stores. A guy called Craig Wilson has created a MongoDB adapter, and I’m just consolidating some of the changes he made to the core code to facilitate this before releasing 0.5, so he can release his adapter at the same time. I’m hoping that people will contribute adapters for other NoSQL stores; I’ve already got one in the works for Azure Table Storage.
I was a bit unsure whether I should add the dependency to the Reactive Extensions to the project, but I went for it because it provided a really nice way to do a buffered fetch from the database while still returning the first record to the application code as soon as it was available. Last week, though, the Rx guys pushed a new version of their packages to NuGet, and people installing Simple.Data from there found that it didn’t work. This is because the Rx library is not open-source, and they strongly-name their assemblies, which is entirely incompatible with the idea of a package manager.
So I’ve written my own code for handling the buffered fetching, and I’ll be removing the Rx dependency from Simple.Data in 0.5. This means that using Simple.Data in your project will not require any dependencies outside the BCL.
I’m not ruling out adding other dependencies to the package – I don’t want to waste time reinventing wheels if I can avoid it – but I’m going to restrict it to open-source efforts in future.