Some developers have reacted with dismay to the recent news that Microsoft’s Oslo project is being integrated into the SQL Server platform and renamed SQL Server Modeling. The overwhelming feeling seems to be that their DSL dream is being snatched away.

In short, Oslo is a modelling language (“M”) that allows developers to create Domain Specific Languages (DSLs) and data models, along with a visual tool (“Quadrant”) for viewing and editing these models, and a SQL Server database (“Repository”) for storing the models and exposing them to the .NET platform and tools.

It is the “M” language, in particular, that has caught the imagination of many developers, as it appears to bring true Domain Driven Design (DDD) a step closer to reality. In DDD, a developer adopts a “silo” approach focussed solely on the business domain that a particular application represents, and tries to implement an entity model that directly reflects the needs of the business. Closely related to DDD is the concept of the DSL; a language dedicated to solving problems in a specific business domain. So, for example, one could have a DSL for building workflow applications, another for billing applications, and so on, each DSL being specifically tailored to solving problems in that domain. You simply express your processes and workflows in your DSL, created using the simple textual syntax of “M”. Likewise, rather than have to write complex SQL, you simply explain what you want from your data using M, and “optimized T-SQL” is produced for you, under the covers.

While Oslo was essentially a .NET project, it seemed to attract warm anticipation from most developers, so it is a little disappointing to see the overwhelmingly negative response to the news that it’s now a SQL Server project. The feeling is, despite protests to the contrary, that their DSL dream will die, and the tool will become just another boring data modeling and querying tool for SQL Server.

However, perhaps the move will be seen in a more positive light by DBAs. After all, from a data modeling perspective, it makes a lot of sense to have “M” in the database and to align the models it produces with those used by Entity Framework and WCF Data Services. More importantly, with a shift in focus towards the database as the “control center”, rather than the application, and a chance for DBAs to impose their will on the data model, maybe we can finally hope to see some lessening of the seemingly-inevitable pain that occurs when a developer’s lovingly wrought object model meets its relational nemesis.

From past experience, however, one could be forgiven for thinking that Oslo will end up being yet another maintenance nightmare for the DBA, who will be faced with a Tsunami of un-optimised SQL engulfing their servers. From a distance, all such solutions look attractive. It is familiarity that breeds disenchantment.

Cheers,

Tony Davis.