Service Factory Modelling Edition – Part 1

In my last post I mentioned that I’d be writing a bit about the experiences I’ve had recently with some of the Microsoft Patterns and Practices Software Factories. On a recent project, I made the call to introduce the use of the Service Factory Modelling Edition, the Repository Factory (a.k.a. the Data Access Guidance Package), and the Smart Client Software Factory to my team.

To get the ball rolling, I’m going to begin with a bit of a discussion on some of the issues I found with the Service Factory Modelling Edition.

This list is a pretty exhaustive list of the things that tripped us up during the course of the project. I’m not having a moan here, because overall I think it’s a pretty cool tool, and I think that the P+P group did a damn fine job of the designers in particular, considering that this is pretty much the first version of the tool to include them.

1. The model designers don’t support cut-and-paste of sub-elements (such as primitive sub-types on a data contract). So if you have a datacontract type, that is used in two different places, you can’t copy and paste, you have to create the second one from scratch.
   
2. The designers for data contract and service contract do not allow the user to manually enter the type name for types that differ from the default “System.String” – have to use the type selector GUI instead (extreme level of user interface friction). This one caused me some aggravationsince in a lot of cases, I wanted the type of a contract member to be something other than string.
   
3. When using the WCF Extension, the DataContract designer should support auto-increment or auto-assignment of the “Order” property of sub-types rather than defaulting to 0 for every newly added subtype, since it is necessary to have a unique Order value for every member.
   
4. There is no support for nullable types in translators. For whatever reason, the Entity to DataContract type translator codegen and wizard do not like nullable types. I had some other issues with the translators also, chiefly the facts that a) they are NOT generated as partial classes, and b) there is no ability to generate a translator for collections of a given Entity/DataContract type. I’ll cover how I got around this in a later post.
   
5. No support for tidily removing generated artifacts – translators, DC’s, Services, etc. There is no easy way to undo a “generate” – you have to manually delete the generated code if you remove or rename an item using the designers.
   
6. There is no out-of-the-box support for WCF bindings other than wsHttpBinding and basicHttpBinding. You need to implement an extension to provide this support. This was annoying, but was pretty easy to sort out. I’ll outline this in a later post also.
   
7. There is no way to reference types from one data contract model in another data contract model. If you have a data contract type defined in a model, and you want to use that same type in more than one place, then you can only do so within the same model. This leads to some of my models being overly large, with everything on the one model or, if you do persist in splitting things up into separate models (which I think makes perfect sense), then you end up with more than one copy of the type (one on each model), which is a real problem when it comes to code generation, and keeping the two (or more!!) models in synch with each other.
   
8. No support for generation of asynchronous client proxy code. At one point I wanted to be able to generate an asynchronous client proxy, but I found that this was not supported in the Service Factory Modelling Ed.
   
9. The out-of-the-box service host project is implemented as an ASP.Net web site. There is no support within the service factory for self-hosting scenarios, such as hosting services in a windows service (at least, I never found any). I will also cover my solution to this in a later post.

 

Again, as I said, I’m not criticising the Service Factory. I think it really made things easier on this project in particular, as we had a very junior developer join the team mid-project (she was from the customer’s development team in fact) and I think that without this tool, she would probably still be trying to get her head around the concepts involved in service development.

Mark