[This is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders.]
This topic provides a high-level overview of the design and development process for domains and models. (It neither describes domains or models, nor does it describe the Microsoft code name “M” in any depth. For more information about Microsoft code name “M”, see "M" Overview.)
Modeled Applications and Runtimes
Modeled applications and runtimes are data-driven applications and runtimes. The phrase “data-driven” implies the use of data as the driving mechanism, and does not emphasize the data design or the ability to share data schemas between applications (although such things are always possible). In contrast to this, a model-driven application emphasizes that the data structures are exposed, consumed, and shared with other data applications as models – properly designed data structures, and interoperable in the sense that any number of applications and tools can share the schemas to improve their productivity and feature sets.
Furthermore, while we often described the use to which data is put with the words “application state” data or “metadata,” in truth data is data. Application and state data (as well as metadata about both that application and its state data) can be equally stored, queried, and often executed by runtimes.
That said, some data is relevant only to a small part of the entire application lifecycle. Models, on the other hand, especially in SQL Server Modeling CTP, are relevant to the entire application lifecycle, and can be shared between applications, enabling reuse. The term “model-driven” in this documentation, then, implies a level of intent and longevity for the data in question, a level of conscious design that bridges the gaps between design, development, deployment, and versioning.
When Are Models Needed?
Models are representations of some idea or thing that is used as a tool to interact with that thing efficiently and quickly. In the SQL Server Modeling CTP, the word model refers to the data structures (also called model schemas) described by a SQL schema in SQL Server 2008. The act of creating new applications creates instances (called model instances) of these SQL Server Modeling Services model schemas. The instance-specific data is stored in the SQL Server Modeling Services as row data in the appropriate tables. (For more information about the SQL Server Modeling Services and its structure, see "Oslo" Repository Design Patterns.)
It is, however, part of all development processes to design and create extents that expose data structures and their relationships and constraints on their values that aid your specific applications and components. Declaring a new extent means using “M” to create a new model schema for values of that type and using the mx.exe tool to add the model schema into SQL Server Modeling Services. (Alternatively, you can do the same work directly using SQL statements against the Modeling Services database. For more information about model development in this fashion, see Modeling Patterns and Guidelines.) Other data types can then reuse that type and it can be seen and used in Microsoft code name “Quadrant”. Finally, you can configure a viewer in “Quadrant” to enable others to see and use the new model schema in an efficient manner.
Developers have always been able to create new data types in the Visual Studio language of their choice; however, in the modeling world you can use the Microsoft code name “M” modeling language and place it directly in the SQL Server Modeling Services. Once there, it can be used by any Visual Studio language (by exporting the repository model schema to XAML), by the “M” modeling language, or by “Quadrant”. In addition, you can configure a “Quadrant” viewer to display that data type visually in a way that enables quick and efficient reuse at design time.
Once model schemas are in the repository, and applications have been created using those model schemas, a model-aware runtime can create and execute those application using model instance data directly from the repository, potentially without the need for any standard compilation work at all.
Finally, many businesses create custom components that are designed to be licensed or sold for reuse in other applications. This is an extension of the previous scenario: the creation of new data types, relationships, and constraints, and packaging them for redistribution so that they can be used by others from one of the visual tools available to them to create model instances in their own applications.