Internals are evil … another example in Sync Services for ADO.NET ?
I've been testing the Sync Services for Ado.Net lately, and I came accross a problem when using an Oracle as back-end database. Well, we all know that Microsoft always offer a good default implementation for SqlServer for all their tools & frameworks, and additionnaly, comes with a Provider model so that “you're welcome to develop your own provider implementation“.
Still, I was puzzled to find out that the SqlSyncAdapterBuilder class that allows you to quickly create SyncAdapter objects (contains information about the server-side tables to be synchronized) was using a DbSyncAdapterBuilder class that is marked as internal. Having a further look at this class shows that all the types used are database-independent (e.g. DbCommand, DbParameter) and that its responsibility, as its name implies it, is to contain the database-independent logic needed to build database-specific SyncAdapter objects.
Obviously, there are 2 reasons for Microsoft to mark such a class as internal:
- Strategic choice: Make it less simple to use Sync Services with other databases than SqlServer, thus pushing the adoption of their own RDBMS. Don't get me wrong, you can still use Sync Services without using a SyncAdapterBuilder, but it requires much more coding.
- Deadline problem: The main implementation of SyncAdapterBuilder is for SqlServer, it was fully tested and is thus fully supported. However, Microsoft cannot guarantee that the DbSyncAdapterBuilder is fully database-independent and that it would allow to build correct implementations for other RDBMS. As a consequence, they prefer to mark it internal. Well, I guess it would not be acceptable for Microsoft to provide such a class with a disclaimer on top of it 'Use at your own risk. Not fully tested'.
Whatever the reason is, now I'm wondering if I should implement an OracleSyncAdapterBuilder or create a small DSL (the LocalDatabaseCache dialog in Visual Studio 2008 is built on top of the DSL Tools by the way) that allow to configure the synchronisation & generate the code for it (without using a SyncAdapterBuilder).
Anyway, let's hope that we'll soon see a shiny 'Sync Services for Entity Framework'.
Update: Turns out I was more or less right about the second option for marking DbSyncAdapterBuilder internal … while SqlSyncAdapterBuilder forwards some property & method calls to a private DbSyncAdapterBuilder object, some of the static methods of the DbSyncAdapterBuilder class are calling back to internal static methods of SqlSyncAdapterBuilder !!! Don't ask me to name this (anti-)pattern … let's just consider the cause was a deadline problem, and the developers had to reduce the initial scope of the framework due to lack of time.
Tip: Forget about implementing an OracleSyncAdapterBuilder class, prefer the code-generation route instead (combined with a DSL for configuration of the synchronized tables for example).
