Just a quick update on my previous posting following one of the comments made by den Ben

just out of curiosity... why wouldn't you
dispatcher.Add<SaveDocumentRequest>(s =>
{
s.Document = document;
s.UserID = userID;
});

He's absolutely right. Using a Func forced me to (mis)use the params keyword as you are not allowed  to use the above syntax with the old code:

public virtual IDispatcher Add<TRequestType>(params Func<TRequestType, object>[] funcs)
    where TRequestType : Request, new()
{
    TRequestType request = new TRequestType();
    foreach (var func in funcs)
    {
        func.Invoke(request);
    }
    AddRequest(request, false);
    return this;
}

I actually had noticed the code not using the return value by the func but disregarded it as I was a bit too happy with the "elegance" of my inital solution.

But I think (and I think you'll agree) that using an Action is much cleaner here:

public virtual IDispatcher Add<TRequestType>(Action<TRequestType> action)
    where TRequestType : Request, new()
{
    TRequestType request = new TRequestType();
    action(request);
    AddRequest(request, false);
    return this;
}

Thanks den Ben!

One of my colleagues asked me today if I could write a utility function that would make his life more easy.

The objective was to call a stored procedure n-times for every item in a list. Of course some of the properties on every item had to be mapped to parameters in the stored procedure.

The desired syntax would be something like:

builder.SetStoredProcedureNameTo( " some sproc name ")
        .Execute ( customerList ,
            (s,t) => s.AddParameterWIthValue( parameterName, t.PROPERTY_NAME_1) ,
            (s,t) => s.AddParameterWIthValue( parameterName, t.PROPERTY_NAME_2) ,
             (s,t) => s.AddParameterWIthValue( parameterName, t.PROPERTY_NAME_3)
      );

I already have a fluent wrapper class to make our ADO.Net a bit more friendly, the interface looks like:

public interface ICustomSqlCommandBuilder
{
    ICustomSqlCommandBuilder SetStoredProcedureNameTo(string storedProcedureName);
    ICustomSqlCommandBuilder AddParameterWithValue(string parameterNameInDatabase, object value);
    ICustomSqlCommandBuilder AddExlicitOutputIntParameterToTheCommandFor(string parameterName);
    ICustomSqlCommandBuilder AddExlicitOutputDateTimeParameterToTheCommandFor(string parameterName);

    IList<TReturnType> ExecuteReaderFor<TReturnType>()
        where TReturnType : new();
}

Nothing special except for the ExecuteReaderFor<TReturnType>() but that's for another post.

Having the fluent interface on ICustomSqlCommandBuilder combined with the lambda magic explained in this post I came up with the following signature:

ICustomSqlCommandBuilder ExecuteScalarForThisList<T>(
    IList<T> list,
    params Action<ICustomSqlCommandBuilder, T>[] actionList);

(s, t) => s.AddParameterWithValue("parameterName", t.PROPERTY_NAME)

to every property in the object<T> that needs to be mapped against a parameter in the stored procedure. Having the params allows us to map as many properties to parameters in the stored procedure as we like. If we then loop through all the items in the list first and apply all actions in the actionList per item, we can then call ExecuteScalar on the stored procedure.

foreach (var item in list)
{
    foreach (var action in actionList)
    {
        action.Invoke(this, item);
    }
    var result = sqlCommand.ExecuteScalar();
    sqlCommand.Parameters.Clear();
}

Now, another requirement was to wrap it in a transaction and also to have the verification of the result a bit more flexible. All in all not too complicated, just a matter of introducing another Action:

public ICustomSqlCommandBuilder ExecuteScalarForThisList<T>(
    IList<T> list, 
    Action<object> verify, 
    params Action<ICustomSqlCommandBuilder, T>[] actionList)
{
    sqlCommand.Connection.Open();
    SqlTransaction transaction = sqlCommand.Connection.BeginTransaction();
    sqlCommand.Transaction = transaction;

    try
    {
        foreach (var item in list)
        {
            foreach (var action in actionList)
            {
                action.Invoke(this, item);
            }
            var result = sqlCommand.ExecuteScalar();
            verify(result);
            sqlCommand.Parameters.Clear();
        }
        transaction.Commit();
    }
    catch (SqlException)
    {
        transaction.Rollback();
        throw;
    }
    catch (Exception)
    {
        transaction.Rollback();
        throw;
    }
    return this;
}

Including a bit of exceptionally brittle exception handling and calling the stored procedure on a list of Customers now resolves to:

Action<object> resultConstraint = result =>
{
    if (result != null)
    {
        if ((int)result > 1000)
        {
            throw new Exception("result should be less than 1000!");
        }
    }
};

builder
    .SetStoredProcedureNameTo("sens_sp_modifyCustomerIncome")
    .ExecuteScalarForThisList(
        customerList, 
        resultConstraint,
        (s, t) => s.AddParameterWithValue("id", t.ID),
        (s, t) => s.AddParameterWithValue("income", t.Income)
        //etc for the rest of the properties
    );

At my current project we are using a dispatcher class to batch requests to our WCF layer based on the Request/Response Service Layer created by Davy Brion. Once you call the Get<TResponseType>() on the dispatcher the WCF layer starts working on the requests one by one and return them in one roundtrip.

Adding requests to the dispatcher is easy:

var saveDocumentRequest = new SaveDocumentRequest();
var getRemainingDocuments = new GetRemainingDocumentsRequest();
dispatcher.Add(saveDocumentRequest, getRemainingDocuments);

Where the signature of the Add method in Dispatcher is like;

public void Add(params Request[] requests)

Although this syntax is not bad, it feels like so much like code from last month: not very sexy. Wouldn't be more fun if we could spice it up a bit using generics and a bit of Func?

I'd love to get rid of instantiating a variable just for the sake of adding it to my dispatcher. After a bit of fiddling around with my unit tests I came up with the following solution.

What I want is to call the Add method in a generic way and set the parameters on my request object inline, using a Func. This is best illustrated with a test:

[Test]
public void can_assign_value_using_a_func_in_a_generic_method_call()
{
    Guid id = Guid.NewGuid();
    var dispatcher = new Dispatcher();
    
    dispatcher.Add<GetPersonsRequest>(s => s.ID = id);
    
    
    //disregard ugly cast; this is only for test purposes
    var request = (GetPersonsRequest)dispatcher.Requests.First();
    request.ID.ShouldEqual(id);
}

public class GetPersonsRequest:Request
{
    public Guid ID { get; set; }
}

public class Dispatcher
{
    public Dispatcher()
    {
        Requests = new List<Request>();
    }

    public void Add<TRequestType>(params Func<TRequestType, object>[] funcs)
       where TRequestType : Request, new()
    {
        var request = new TRequestType();
        foreach (var func in funcs)
        {
            func(request);
        }
        Requests.Add(request);
    }

    public IList<Request> Requests { get; set; }
}

I can now set only property in my Request type, what if it has more properties that need to be set? Just introduce the infamous params to the method signature like so:

public void Add<TRequestType>(params Func<TRequestType, object>[] funcs) 
   where TRequestType:Request, new()
{
    var request = new TRequestType();
    foreach (var func in funcs)
    {
        func(request);    
    }
    Requests.Add(request);
}

And again the test:

[Test]
public void can_assign_two_values_using_a_func_in_a_generic_method_call()
{
    var dispatcher = new Dispatcher();
    Guid id = Guid.NewGuid();

    dispatcher.Add<GetPersonsRequest>(s => s.ID = id, t=> t.GetAllDetails = true);

    //disregard ugly cast; this is only for test purposes
    var request = (GetPersonsRequest)dispatcher.Requests.First();
    request.ID.ShouldEqual(id);
    request.GetAllDetails.ShouldBeTrue();
}

When we change the return type of the Add method to the dispatcher itself, we can then use a fluent interface to get a very friendly syntax  for making calls:

//input parameters for first request
var document = new object();
var userID = Guid.NewGuid();

//input parameters for second request
var dossierID = Guid.NewGuid();

dispatcher
    .Add<SaveDocumentRequest>(s => s.Document = document, t => t.UserID = userID)
    .Add<GetZaakRequest>(s => s.DossierId = dossierID);

I really like the fact that I don't have to initialize a variable and still have access to all the properties in the request object..