#2782

Adding a new validation rule to the Service Factory

Even if you’re not in the factory authoring game you might want to add additional validation to the Service Factory so that you can ensure that additional business rules are followed. For example all your services are using the correct namespace for your organization.

We’ve made this sufficiently simple that anyone can add new rules without recompiling the factory. Simply follow these three steps. 

1. Write a new EntLib validation rule.
2. Compile the rule assembly and deploy it.
3. Update the factory ruleset.config file to consume the rule.

Let’s examine these in a bit more detail…  

Write a new rule

Service Factory validation rules are simply EntLib validation rules that are executed by the EntLib 3.1 validation application block (VAB). They can interogate the factory model(s) through the In Memory Story (IMS) object model. Here’s the ImplementationTechnologyAndSerializerValidator rule’s DoValidate method.

protected override voidDoValidate(SerializerTypeobjectToValidate, objectcurrentTarget, string key,
    ValidationResultsvalidationResults)
{
    if(!validationResults.IsValid) return;   
    ServiceContractModelserviceContractModel = currentTarget as ServiceContractModel;
    if(serviceContractModel != null)
    {
        if(IsASMX(serviceContractModel.ImplementationTechnology.Name))
       {
            if(objectToValidate.Equals(SerializerType.DataContractSerializer))
            {
                this.LogValidationResult(validationResults,
                    string.Format(CultureInfo.CurrentCulture, this.MessageTemplate), currentTarget, key);
            }
        }
    }
}

As you can see this rule accesses various model elements and makes sure that if the service contract model ImplementationTechnology property is set to ASMX then the object being validated, the serializer property must not be a DataContractSerializer type. There’s many more example rules that ship with the factory.

Deploy your rule

This couldn’t be simpler… Simply shut down Visual Studio and copy your assembly to the \Lib folder under the factory folder. When you reload the factory all the assemblies in the \Lib folder will get loaded and be available to the validation ruleset.

Update the ruleset configuration

Here’s how the rule is attached to the SerializerType property on the ServiceContractModel type.

<type assemblyName=“Microsoft.Practices.ServiceFactory.ServiceContracts.Dsl”
    name=“Microsoft.Practices.ServiceFactory.ServiceContracts.ServiceContractModel“>
    <ruleset name=“Menu“>
        <properties>
            <property name=“SerializerType“>
                <validator type=“Microsoft.Practices.ServiceFactory.Validation.ImplementationTechnologyAndSerializerValidator, Microsoft.Practices.ServiceFactory.Validation”
                messageTemplate=“There is a mismatch between the implementation technology and the serializer type on the ServiceContractModel”
               name=“ServiceContractModel.SerializerType validator” />
            </property>
        </properties>
    </ruleset>
</type> 

Special rules and debugging

When modifying the ruleset you’re obviously free to reuse the rules we shipped with the factory. There are a couple you may want to be aware of:

CrossModelElementValidator -This rule validates that a cross model reference from one DSL to another is valid and causes the referenced model element to also be validated. This example shows the validator that ensures that the ServiceReference.ServiceImplementationType property refers to contract type element that exists and is valid: 

<property name=“ServiceImplementationType“>
    <validator type=“Microsoft.Practices.ServiceFactory.Validation.CrossModelReferenceValidator,
            Microsoft.Practices.ServiceFactory.Validation, Version=1.0.0.0, Culture=neutral,
            PublicKeyToken=31bf3856ad364e35”
        validateReferencedElement=“true”
        name=“ServiceReference.ServiceContractType reference validator” />

ExtenderObjectValidator – This rule causes the validation engine to validate the extender attached to a model element. If you add a new extender type to a model element and you want to add validation rules to your new extender (type) then you need to add one of these validators to the ObjectExtender property on your model element. Here’s an example:

<property name=“ObjectExtender“>
    <validator type=“Microsoft.Practices.ServiceFactory.Validation.ExtenderObjectValidator,
            Microsoft.Practices.ServiceFactory.Validation, Version=1.0.0.0, Culture=neutral,
            PublicKeyToken=31bf3856ad364e35”
        targetRuleset=“Menu”
        messageTemplate=“”
        name=“Message.ObjectExtender validator” />

It turns out that debugging new rules is fairly straightforward. Simply attached the debugger to the DEVENV.EXE instance and set a breakpoint on the constructor or DoValidate method. The biggest pitfall here is that the VAB tends to fail silently if the ruleset refers to a property that doesn’t exist. For example if I misspelled my property name attribute then the rule would just not run – no warnings or errors.