ESharp Validation Rule Breakthrough

7/17/2008

 After a late night of hacking I have finally got an end to end transformation of E# validation rules into CSLA code that compiles. I am using the NVelocity code generator I created to do this, here is the example entity I have defined:

using NBusiness.Frameworks.Csla.Templates;

using Csla.Validation.CommonRules;

 

family Test

{

      entity A as EditableRoot

      {

            field auto id int aid;

            field nullable string data;

            field nullable double value;

           

            validate data StringMaxLength { MaxLength : 10 };

      }

}

 

After running this through the compiler here is the code that it generated:

using System;

using Csla;

using Csla.Validation;

using System.Collections.Generic;

 

namespace Test

{

      [Serializable]

      public partial class A : BusinessBase<A>

      {

            #region Properties

            private static PropertyInfo<int> aidProperty = RegisterProperty<int>(

                  typeof(A),

                  new PropertyInfo<int>("aid"));

            /// <summary>

            /// aid property

            /// </summary>

            public int aid

            {

                  get { return GetProperty<int>(aidProperty); }

            }

            private static PropertyInfo<string> dataProperty = RegisterProperty<string>(

                  typeof(A),

                  new PropertyInfo<string>("data"));

            /// <summary>

            /// data property

            /// </summary>

            public string data

            {

                  get { return GetProperty<string>(dataProperty); }

                  set { SetProperty<string>(dataProperty, value); }

            }

            private static PropertyInfo<System.Nullable<double>> valueProperty = RegisterProperty<System.Nullable<double>>(

                  typeof(A),

                  new PropertyInfo<System.Nullable<double>>("value"));

            /// <summary>

            /// value property

            /// </summary>

            public System.Nullable<double> value

            {

                  get { return GetProperty<System.Nullable<double>>(valueProperty); }

                  set { SetProperty<System.Nullable<double>>(valueProperty, value); }

            }

            #endregion

 

            #region Relationships

            #endregion

           

            #region Validation

            protected override void AddBusinessRules()

            {

                  Dictionary<string, object> dataArgs = new Dictionary<string, object>();

                  dataArgs.Add("MaxLength", 10);

                  ValidationRules.AddRule(

                        Csla.Validation.CommonRules.StringMaxLength,

                        new DecoratedRuleArgs(dataProperty, dataArgs));

            }

            #endregion

      }

}

(You can see the power of a DSL simply by looking at how many more lines of code it takes to represent the same thing in a lower level language!)

It has taken me a loooong time to get to this point and I think it’s all downhill from here. Trying to find out how to discover validation / access / authorization rules from arbitrary business object frameworks turns out to be a terribly difficult thing to do. There is lots of room for improvement but I think I have the basics down for now. This should allow me to generate code for CSLA and NBusiness frameworks at least and perhaps a couple of others without too much work.

Next up is largely a process of cleaning up code (I have been hacking on things a lot recently), fixing up unit tests and fleshing out CSLA templates for each major stereotype (I love that word in a software context!). What a relief!

Unit Testing Asynchronous Code in Silverlight

7/16/2008

My current job is a very enjoyable one. I have the pleasure of working for Rocky Lhotka on CSLA 3.6 and CSLA Light, more specifically CSLA Light but the two definitely bleed together.

CSLA Light is a project where we are trying to create a version of CSLA that will run on Silverlight. If you’re interested in hearing more details about this you should check out Rocky’s blog since it is the most up to date authority on CSLA development progress.

One of the problems we ran into right away was the ability to unit test our Silverlight code. Unit testing on Silverlight presents a number of limitations that are not present in a standard .net application. We initially tried using the unit test framework provided by Microsoft but found it impossible to test anything with a WCF service call in it due to threading.

To help illustrate the problem consider the following test:

[TestClass]

public class TestExample

{

    [TestMethod]

    public void Example()

    {

        ManualResetEvent mre = new ManualResetEvent(false);

        BackgroundWorker worker = new BackgroundWorker();

        worker.DoWork += (o, e) =>

        {

            // Do some processing...

        };

        worker.RunWorkerCompleted += (o, e) =>

        {

            mre.Set();

        };

        worker.RunWorkerAsync();

 

        mre.WaitOne();

    }

}

This test simulates a unit of work that is performed asynchronously. If you run this test in Silverlight what will happen? Also, suppose in your DoWork method there is bug and an Exception is thrown, what will happen? I’ll get back to this in a moment.

One of the features of CSLA is something called the “Data Portal” which is a concept that has been preserved in CSLA Light with only some slight differences, primarily all network calls in Silverlight must be done asynchronously. The Data Portal is the mechanism your CSLA business objects must use to transfer data across network separated application tiers. In CSLA 3.6 an asynchronous Data Portal has been created to provide parity with Silverlight, not to mention the fact that it’s just plain cool.

One interesting thing to know about Silverlight is that whenever you use WCF to make a network call it will dispatch that call onto the UI thread. I believe this is actually a limition of the browser rather than Silverlight itself, it must be piggy backing on top of the browser XmlHttpRequest functionality and therefore suffers from the same limitations.

This is a major problem for the Silverlight MSTest framework! Since your test is running on the UI thread if your test tries to make a WCF call it will need to be dispatched to the UI to work and you will end up with a deadlock. The above test will not work in Silverlight because we have used a ManualResetEvent to hold the UI thread since it too will dispatch to the UI thread.

So to respond to this we came up with a light weight unit testing framework that will allow you to easily test asynchronous code in Silverlight and to accompany NUni