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..

At my current project we needed a quick sort of throw away app that was going to be used by a small group of people. Without going into much details the app basically is a planning and analysis module for the allocation of employees to divisions.

Since development speed is crucial we decided to work with Linq2sql and winforms. No need for all sorts of layers; just get it done.

We needed to fill a combobox with values. This should be trivial, but was a bit more trouble than expected. I ended up using the excellent description found here. Basically all you need to do is:

          var comboBox = new ComboBox(); var choices
= new Dictionary<string, string>();
choices["A"] = "Arthur";
choices["F"] = "Ford";
choices["T"] = "Trillian";
choices["Z"] = "Zaphod";
comboBox.DataSource = new BindingSource(choices, null);
comboBox.DisplayMember = "Value"; comboBox.ValueMember
= "Key"; 

Notice the clever use of new BindingSource(choices, null);

Nothing complex here, but this is static and I wanted to get the values from the db. Next to that it would be nice if we could have some sort of generic function that could take a type of TEntity (table) and some hints to which properties in TEntity it needed as Key and Value.

I ended up with this:

          public interface 
          IComboBoxHelper { void SetComboBoxContent<TEntity,
TKey, TValue>( Func<TEntity,
TKey> key, Func<TEntity, TValue>
value, ComboBox comboBox) where TEntity
: class; }

Usage becomes pretty straightforward: register the IComboBoxHelper and it's implementation to the Dependency injection container. Add a constructor dependency and use the helper variable:

comboBoxHelper.SetComboBoxContent<Divisie, int, string>(s=>
s.Divisie_PK, s=> s.Divisienaam, comboBox);

The implementation of the IComboBoxHelper takes a datacontext and is responsible for looking up the required entity.

Let's have a look at the actual implementation:

          public class 
          ComboBoxHelper : IComboBoxHelper { readonly HRDataContext dataContext; public ComboBoxHelper(HRDataContext dataContext)
{ this.dataContext = dataContext; } public
void SetComboBoxContent<TEntity, TKey, TValue>( Func<TEntity,
TKey> key, Func<TEntity, TValue>
value, ComboBox comboBox) where TEntity
: class { Dictionary<TKey,
TValue> dictionary = new Dictionary<TKey,
TValue>(); IQueryable<TEntity>
entities = dataContext.GetTable<TEntity>().Select(s => s); entities.ForEach(s
=> dictionary.Add(key(s), value(s))); var source
= new BindingSource(dictionary, null);
comboBox.DataSource = source; comboBox.DisplayMember = "Value";
comboBox.ValueMember = "Key"; } }

Nothing too complicated, but the use of Func's to get to the properties in the required Entity is pretty nice.