Programming WCF Services
Let us start with the conclusion, I don't like this book.
Allow me to start with an analogy, I thought I was going to read a book about working with SQL Server, instead, I got a book that tells me how TDS* works.
*TDS == Tabular Data Stream - the network protocol for SQL Server.
I am sorry, forget that I said that. Below is my first impression of the book, and I still stand by it, it is not a book you want to learn WCF from. It is a book that you want to at least go through, and keep as a reference if you are working with WCF in any but the most trivial of manners. This change in opinion was caused by needing to do something in WCF that I thought was possible, and finding the answer in a few minutes of searching in the book.
It is a very thorough discussion about WCF implementation, it probably has a lot of valuable information. The problem is that it is nearly impossible to understand this information, because it is presented outside of any context.
"Let me show me how you can turn the knob in all possible ways, but I'll not tell you why you should turn the knob, and what is on the other side."
The book contain a lot of details about WCF, some of which I am sure that will be of use in the future, but I have to say that it feels like it should be the third or fourth book that you read about WCF, after you already understand the way that it works and how you should implement it in your business scenarios.
It may be a great book if you are a framework developer who to better understand WCF, in a mid-level way, but even then, I would rather understand the way WCF works first, and then rely on web/reflector for the rest of it.
Let me give you an example, in many cases, the author chose to use such meaningful names as: "IMyContract1" or "IMyContract2" to demonstrate a technical point. That is nice, and if it was a textbook, requiring rote memorization, it may have been appropriate. The problem is that I expect books about such topics to give a meaning to the choices that they present, not just in the narrow technical terms, but with the broader design implications.
Other problems that I had with the book:
· In one particular instance, the author bothered to show me the definition of System.SerializableAttribute. Thanks, I already know that one…
· Each and every configuration sample is shown with both declarative XML and using C# code. I am not sure if the intent was to supplement MSDN, but I consider this a bad idea. I am capable of making the transition from XML to C# easily, and I can look in MSDN what this element map to, and vice versa.
· Another annoying issue is that the author spend a fair amount of time building a set of helper classes to work with WCF. I am not sure if this is a personal preference issue or not, but I am coming away with the feeling that WCF has very low usability if just about everything need to be wrapped in a helper class. This is valuable in the narrow sense that it shows me how I can do things, but it is not very useful in the long run.
· It keep mentioning static variables to preserve state in per-call services, which drives me crazy, since it is something that I consider a very bad practice (it mentions the complexity, but doesn't warn against it).
It may seems that I harp about the no context issue too much, but take into account what a database book would look like if all the examples were:
SELECT [Column1], [Column2] From [MySchema].[MyTable1]
Sure, it teaches the syntax, but it leave me with the burden of translating the pure technical details into a problem domain.
Who is this book useful to, then?
If you are tasked with building a complex WCF service and you already has a rough idea about what you need, you can use this book to pinpoint the technical details and understand how you can implement those. As a reference, it is going to be very useful, since it goes to a great depth into a lot of the details of WCF. Once you know what you need to do, it would be easier to correlate that to the technical requirements that you need to meet. Apparently it is not supposed to cover WCF in low level detail, which really scare me if this is true, because there are a lot of stuff that are covered in detail.
What I really like was the coverage of transactions, it was very thorough, and presented me with quite a bit to think about. Specifically, the use of Transactional<T> in a service to allow the service members to take part in a transaction is something that made me sit up and stare at the air for a while, thinking about all the possibilities that it can enable. Specifically, combining this support with NHibernate support may give me a fully transactional view of my entities, in both memory and database.