Rule Archetype Pattern in SQL Modeling Services – Part 1

  • Article

I’ve been playing around with SQL Server Modeling Services and Visual Studio 2010 Beta 2 quite bit over the holiday break. Specifically, I’ve been playing around with bringing an Archetype Pattern to life in Modeling Services, with a specific focus on leveraging the architectural goodness provided by the Repository. This work was inspired by a hypothetical scenario I proposed in an earlier post regarding System.Identity and the Repository.

To put Modeling Services through its paces, I decided to grab one of the Archetype Patterns that would lend itself to semi-realistic development for the Repository. In particular, I was looking for the following characteristics:

  • An Archetype Pattern that would likely benefit from/require Globalization
  • An Archetype Pattern that would likely benefit from/require Access Control
  • An Archetype Pattern that would likely benefit from/require Segmentation and/or Version Control
  • An Archetype Pattern of the proper size for blogging (i.e., not too large)

After thumbing through the patterns, I decided that the Rule Archetype Pattern would fit the bill nicely.

<Author’s Note>This series of posts is intended to be a high-level exercise in using SQL Server Modeling Services only – please don’t use any of this for a BRE or any Production code :-)</Author’s Note>

 

Refactoring the Archetype Pattern

The first step in bringing the Rule Archetype Pattern to life in Modeling Services is refactoring the model. This refactoring is driven by two primary concerns:

  1. Arlow & Neustadt leveraged the OO paradigm in the construction of the Archetype Patterns
  2. The ‘M’ language, especially in terms of modeling for the Repository, adheres to the relational paradigm.

For those readers not familiar with Object-Relational Mapping (O/RM) concerns, MSDN has some excellent coverage of ‘M’ patterns for modeling relationships. Given the excellent coverage available on the topic, I’ve elected to skip a step-by-step description of refactoring the Archetype Pattern. Instead, I’ll offer up a UML class diagram that illustrates the refactored model in terms of ‘M’ structural definitions:

 

Rules Class Model

 

As can be seen from the model above, each of the extents in the model uses (directly or indirectly) the HasFolderAndAutoId type. Using this design the refactored Rules Archetype will support SQL Modeling Services Folder Design Patterns.

 

The RuleElement Type

In accordance with the refactored model depicted above, the following ‘M’ code illustrates the implementation of the RuleElement type:

    1: module RulesModel
    2: {
    3:     import System;
    4:  
    5:     type RuleElement : HasFolderAndAutoId
    6:     {
    7:         Name : Text where value.Count <= 2083;  // Globalization support via Modeling Services
    8:         Type : Text where value.Count <= 2083;  // Globalization support via Modeling Services
    9:         ElementSequence : Integer32 where value > 0;
   10:     }
   11: }

The ‘M’ code above is very straightforward. The only things worthy of note in terms of Modeling Services are the constraints placed upon the “Name” and “Type” Text attributes. As the comments in the code snippet above document, these constraints are put in place in accordance with Modeling Service’s support for Globalization.

What’s cool is that in just 11 lines of ‘M’ code a reusable type can be defined that lays the foundation for great features such as Access Control, Versioning, and Globalization.

 

Next Time

For the next installment, I’ll cover the more of the extents in the model and talk about using Modeling Services Security Views.