In my last post, I went over a number of issues that my project team and I had with the Service Factory Modelling Edition.
One of the issues was with respect to the generated Entity-to-DataContract translator classes, specifically the fact that the generated class contains no “collection” translation method.
Now, it may seem obvious to some that there is a straightforward way to leverage the generated methods to achieve translation of an entire collection of entities to data collection types, or vice-versa, but not everyone finds it so obvious (at least, some on my project team didn’t find it obvious!! 
)
Ok, lets imagine we have generated a translator class for an Address entity and an AddressDC data contract type. You get the following two static methods (code removed for clarity):
public static BusinessEntities.Address TranslateAddressDCToAddress(DataContracts.AddressDC from)
{
...
}
public static DataContracts.AddressDC TranslateAddressToAddressDC(BusinessEntities.Address from)
{
...
}
Now, we also have a collection of address entities (stored as a List<Address>), that we want to translate into a collection in our data contract. The data contract has been designed using the modelling tools in the Service Factory, and our AddressDC collection has been modelled as a collection of type List also.
Basically, you loop through the collection you’re translating from and for each record, you call the appropriate translator method, like so:
List<Address> output = new List<Address>();
foreach (AddressDC addressDCItem in AddressDCColl)
{
output.Add(TranslateBetweenAddressAndAddressDC.TranslateAddressToAddressDC(addressItem));
}
Ok, so the other part of this equation is making sure that we factor this well, and don’t write this code over again everywhere we want to use it. The most logical place to put this is to write it as a new method on the existing translator class.
Of course the thing to remember with this, and this is the issue I really had with the translator generation in the Service Factory, is that the translator is not a partial class, so we have to add code to the existing code file, and because of that, we need to realise that this code will be “removed” again if the translator ever needs to be re-generated.
Obviously we’re likely to want collection translators that go both ways, so there will be two new hand-coded methods. Therefore our final translator would look something like this (again, some of the code has been removed for clarity):
public static BusinessEntities.Address TranslateAddressDCToAddress(DataContracts.AddressDC from)
{
...
}
public static DataContracts.AddressDC TranslateAddressToAddressDC(BusinessEntities.Address from)
{
...
}
Public List<Address> TranslateAddressList(DataContracts.AddressDCColl from)
{
List<Address> output = new List<Address>();
foreach (AddressDC addressDCItem in from)
{
output.Add(TranslateBetweenAddressAndAddressDC.TranslateAddressDCToAddress(addressItem));
}
return output; }
Public DataContracts.AddressDCColl TranslateAddressList(List<Address> from)
{
DataContracts.AddressDCColl output = new DataContracts.AddressDCColl();
foreach (Address addressItem in from)
{
output.Add(TranslateBetweenAddressAndAddressDC.TranslateAddressToAddressDC(addressItem));
}
return output; }
Please note that this code has been coded off the cuff, and has not been tested, nor even compiled. It’s there just to give you a general idea of what to do.
Mark
, and goodbye to using Orcas/VS 2008 at work – just as the 
