The introduction of generics into C# 2.0 simplified many programming tasks. It especially helped in the creation of type-safe collections.
During our reworking of the Infovark data access layer, we created several generic methods to return items from our database. This allowed us to eliminate many duplicated methods and eliminate a lot of type casting. For example, before we began using generics, we had methods with signatures like this:
became this after our refactoring:
Wait a minute. All we’re doing here is wrapping all our unique methods up in a generic method! Why bother? Good question. We abandoned that approach in favor of something more sensible later on.
That’s actually not the point of this post. The point is that C# doesn’t have the ability to perform a
switch on types. See all those
if statements in our generic method? That’s how we worked around the lack of type switching. If anyone has a better approach, we’d like to hear it.
Peter Hallam’s WebLog provides more information about why C# doesn’t have the ability to switch on a type. I’m not convinced by the reasons outlined there. As one commenter noted, there’s already a type-switching construct in C#: the
Has anyone found a good pattern for serialization without deserialization?
In my previous post about mixing serialization, I mentioned that we’d implemented the
IXmlSerializable interface in many of our classes. The main reason for doing this was to include elements and attributes that were read-only.
In other words, we wanted additional information to appear in the serialized stream. This additional information is not needed in order to rehydrate the object.
Most serialization frameworks don’t handle this case. After all, if the point of serialization is to transport an object across the wire, cluttering up the stream with extra information is wasteful. Besides, you can’t dictate what someone on the other side might do with the data. Nicholas Allen discusses this point in his post explaining why read-only data members are not supported in WCF.
While I understand his point from an object remoting perspective, the reason for choosing XML as a data format in the first place was to allow for human readability. What if you want to embed metadata in your XML that doesn’t affect the behavior of the object? You’d need to include it in the XML output, but you aren’t interested reading it back in from an XML stream. What’s the best way to achieve this?
For example, in our data layer we have a Version object that brings together information about when the object was created and by whom, when it was modified and by whom, as well as the object’s revision number. It’s useful to have this information in resulting XML string, but we don’t need to read it back in.
So here’s my question: Are we doing this wrong? Does the need for one-way serialization indicate a problem with our object model? Is it a code smell, or is it simply an edge case not considered by existing frameworks?
Who doesn’t like mixing their Raisin Flakes with their Oaty-O’s in the morning? Yum! But it’s not a good idea if you’re talking about serial formats in C# 3.5 instead of breakfast cereals. You’ll get output that might leave a bad taste in your mouth.
Question: You’re writing a web API for an application. To give developers the most flexibility in interacting with your system, you want to expose classes that can be serialized to either XML or JSON. Using WCF and C# 3.5 SP1, what are your options?
Answer: There’s only one option unless you rely on 3rd party serialization libraries. You must mark the class with the
[DataContract] attribute and mark each serializable member with
[DataMember]. This allows you to serialize and deserialize using the DataContractSerializer and DataContractJsonSerializer for XML and JSON respectively.
I mention this because we’d gone to great lengths to customize our XML using the IXmlSerializable interface. This gave us fine control over the properties we wanted to appear in our XML output and how they were formatted. But if you use the
IXmlSerializable interface, you can’t also annotate the class with the
[DataContract] attribute. You’ll get a compiler error. Sowmy Srinivasan explains this serialization restriction.
I know what you’re thinking: If the framework provides an
IXmlSerializable interface, isn’t there also an
IJsonSerializable interface? Sadly, no. There’s no way to fine-tune the JSON output. Sigh.
So, if you’re currently using
IXmlSerializable, you can forget about the
DataContractJsonSerializer. Or you can accept that you’re fighting the framework, forget about your fancy-pants XML format, and accept the default serialization, keeping these data member best practices in mind.
Infovark has too much invested in our XML layout at this point. We’ve built our XSD files, XSL Transforms, and many, many unit tests. So we gave up on the
DataContractJsonSerializer and turned to the excellent JSON.NET, written by James Newton-King. It’s now version 3.0 and fully supports the new LINQ constructs.
It’s a little more work, but we think it’s worth it.
I’m not sure whether it’s the fastest way to convert an enumerable collection of
ints to a comma-delimited list in C#, but it might be the shortest.
If you need a LINQ-free version for backward compatibility, check out Missing Functions on IEnumerable on Steve Cooper’s blog.
With my roots in maintenance programming, I’ve used a wide assortment of programming tools. Maintaining legacy code is not much fun. Anything that makes it easier gets added to my personal collection of productivity applications. I make a point of learning them inside and out.
I carry the tools with me from project to project. I recommend them to coworkers. I’ll use them even if my employer provides alternate tools for free. I’ll complain loudly if the company I work for won’t allow me to use them — for policy reasons, consistency reasons, or security reasons. (Most of my bosses eventually concede the point. After all, they’re interfering with my ability to get things done, which is presumably why they hired me.)
When I heard that version 3 was soon to be released, I was both excited and a bit nervous. What new features would they add? Were they going to break any behavior I relied on?
The website lists the new features, but the best new feature is the polished user interface, which makes it easier to move blocks of text and make inline edits to files.
And no, they didn’t mess up anything in the process.
I played with the beta for several weeks, and recently bought the full version. If you’re not using it already, you should try it.