WCF primitive type vs complex type

Question

I'm designing a WCF service that will return a list of objects that are describing a person in the system.

The record count is really big and there I have some properties like person's sex. Is it better to create a new enum (It's a complex-type and consumes more bandwidth) named Sex with two values (Male and Female) or use a primitive type for this like bool IsMale?

Answer 1

The reason to not use an enum is that XML Schema does not have a concept equivalent to an enum. That is, it does not have a concept of named values. The result is that enums don't always translate between platforms.

Use a bool, or a single-character field instead.

Answer 2

I'd suggest you model it in whatever way seems most natural until you run into a specific issue or encounter a requirement for a change.

WCF is designed to abstract the underlying details, and if bandwidth is a concern then i think a bool, int or enum will all probably be 4 bytes. You could optimize by using a bitmask or using a single byte.

Again, the ease of use of the API and maintainability is probably more important, which do you prefer?

if( user[i].Sex == Sexes.Male )

if( user[i].IsMale == true; ) // Could also expose .IsFemale

if( user[i].Sex == 'M' )

etc. Of course you could expose multiple.

Answer 3

Very little point switching to bool; which is bigger:

<gender>male</gender> (or an attribute gender="male")

or

<isMale>true</isMale> (or an attribute isMale="true")

Not much in it ;-p

The record count is really big...

If bandwidth becomes an issue, and you control both ends of the service, then rather than change your entities you could look at some other options:

• pre-compress the data as (for example) gzip, and pass (instead) a byte[] or Stream, noting to enable MTOM on the service
• (or) switch serializer; proobuf-net has WCF hooks, and can achieve significant bandwidth improvements over the default DataContractSerialier (again: enable MTOM). In a test based on Northwind data (here) it reduced 736,574 bytes to 133,010. and reduced the CPU required to process it (win:win). For info, it reduces enums to integers, typically requiring only 1 byte for the enum value and 1 byte to identify the field; contrast to <gender>Male</gender>, which under UTF8 is 21 bytes (more for most other encodings), or gender="male" at 14 bytes.

However, either change will break your service if you have external callers who are expecting regular SOAP...