 |
|||||||||
|
|||||||||
|
|
There are many different workflows and use cases that describe how a developer might use Oslo and "M", maybe one of the most straightforward and easy to explain is the idea of using the "M" modeling language to define models that will eventually represent tables in a database. This is an extremely common task. Today we often do this by starting out on a whiteboard and then when we're happy with what we see on the whiteboard we might switch to something like Visio or, if we're really a glutton for punishment we'll model right on the DB diagram surface in the SQL Server Management Studio.
What "M" allows us to do is model in text. But this isn't like typing XML (thank God). Instead, what you're typing is a clear representation of your intent. The end result is a clear, concise description of your model. More importantly, this textual description of your model can be reasoned on, passed around for comment, versioned, and stored. When you feel like creating SQL tables out of this model, you can do that. If you need to create new versions of the model that are compatible with old versions of the model then you also have that ability (though that topic is beyond the scope of this blog post).
I'm always a big fan of trying this stuff out myself. The problem with a lot of models is they're too simplistic. So, rather than enter in a model for a customer than their phone numbers or some other contrivance to suit a "Hello World" sample, I decided to model the data structures for a space-based trading/conquest game that I designed a long time ago and just never got around to implementing for various reasons. This game allows the player to create their own super-massive ship and this ship can carry cargo and it can also have a squadron of fighters associated with it. There are more details to the game but I won't bore you with those.
So I started off by creating a type that I called "Ship":
type Ship
{
Id : Integer32 = AutoNumber();
Sector: Integer32;
X : Integer32;
Y : Integer32;
Z : Integer32;
CurrentFuel : Integer32;
Owner : Avatar where Owner in Avatars;
HullType : HullType where HullType in HullTypes;
DriveType: DriveType where DriveType in DriveTypes;
TacticalSystemType : TacticalSystemType where TacticalSystemType in TacticalSystemTypes;
} where identity (Id);
What I like about this model is it is easy to read. You don't have to sift through a bunch of T-SQL crap to figure out that my ship objects (whether they be rows in a table or instances of CLR objects or whatever...) will have some kind of location (sector, X, Y, and Z), the ability to consume fuel, a configurable hull and engine type, as well as a configurable tactical system. All very straightforward, easy to read, easy to share, and easy to comment on and maintain. Also remember that this model can be visualized in Quadrant (we don't yet have a standalone CTP for Quadrant yet) and it can be stored in the repository for querying and safekeeping.
Take a look at the screenshot below. On the left you can see my "M" modeling code and on the right you can see IntelliPad giving me a preview of what the T-SQL is going to look like that generates this model:
When looking at your model, which would you rather see, a statement that indicates that a Fighter has a reference to the Ship entity in the Ships extent (M) or a whole bunch of stuff about foreign key constraints and database columns? When I'm architecting a solution, I want to look at the "M", especially if I don't yet know how I'm actually going to physically represent this model in my applicatoin code yet. There are two avenues: I could reprsent them in SQL and use the models to generate T-SQL or I could host the models in my own runtime and CLR instances from Mgraph instances from a DSL (I'll show that in a subsequent blog post).
For now, let's assume we're modeling for the database. The screenshot only gives you a small glimpse of the benefits you get by using "M". Anything more complex than my really simple game model would consume hundreds of tables and have thousands and thousands of foreign keys and constraints and other things... Other things that would be much easier to grasp when looking at "M" than looking at T-SQL or even the SQL design surface.
In the next blog post I will show how to interact with the Oslo repository using this model that I just created. If you want to see the entire model that I created for this fictitious game, click here .To see the SQL behavior, just click the "M Mode" menu in Intellipad and select the Generic SQL preview.
This looks <em>a lot</em> like ruby-on-rails schema and
migrations -- Or CoreData schema and migrations, though there is no domain
language for those and they can be very difficult to do programmatically.
I imagine, since this is built on top of the various MS stacks, it's
applicable in either web or desktop case and to more kinds of stores. But
it's really only a distinction of degree.
Let's look at the bigger picture here. Sure, the one screenshot that I
showed looks kind of like the Ruby on Rails migration thing, but this is
but a small portion of a much bigger picture. Microsoft is tackling the
modeling problem with an end-to-end solution, not just one piece of the
puzzle like RoR or Core Data. "M" is more than just a language for SQL
mappings, M is a universal modeling language with many applications. Stay
tuned to the blog and I'll show some more applications of "M" and Oslo that
are anything but Ruby-like.
