WCF & Silverlight: How to go about without interfaces?

Question

Let me try to explain my challenge. I'm building a Silverlight app which will be using a WCF service.

The WCF service returns a list of users and roles (and lots more but trying to keep it simple).

In the SL app I need to fill several comboboxes with lists of users and roles. Usually I would use an interface to specify the key and value pair and could simply bind these to the combobox

But alas WCF doesn't provide interfaces just dataclasses. What would be a nice solution to get what I want.

I started out with a GetList method but its missing some magic. Or maybe use a 'generic' class with key/value and write a OperionContract which returns these...

Do I make any sense and what would you do?

public class Users
{
    public string Name { get; set; }
    public int Id { get; set; }
    //Etc lastname, password
}

public class Roles
{
    public string Name { get; set; }
    public int Id { get; set; }
    //Etc icon, superuser, whatnot
}

public class Pager
{
    public static List<KeyValuePair<string, int>> GetList(List<object> itemlist)
    {
        var result = new List<KeyValuePair<string, int>>();
        //Do some magic

        return result;
    }

EDIT Using an abstract class helps a bit. Until I need more 'interfaces'..

Answer 1

When you receive something "over the wire" via WCF, you are getting a concrete implementation. It makes sense that interfaces aren't provided because those are abstract, and you are getting concrete types.

However, there are two ways you can preserve the interface over the wire.

The first, as Bryan Watts indicated, is to implement the interface on your client. I rarely use the proxied items that are passed directly from the WCF service; instead, I typically move them into other objects on the client that can have their own interfaces, base classes, etc. I use the WCF as a data pump and then hydrate the data into concrete classes defined at the client.

While some people will point out this looks like extra work, I disagree. I rarely build an application "service first." If I have a widget to deal with, I'll define the model for my widget, even build tests and can bind to views, etc. The service is just an interface to return widgets so I'm abstracted from the service and can test without it. When the service becomes available, I can simply map what proxy type from the server and move it into my defined widget.

The second way is to use a technology that projects the data, such as WCF RIA. WCF RIA will use generated code to create a map of the code defined on the server on the client. What this means is the behaviors and annotations are projected via code to the client. Personally I still end up abstracting away and not binding directly to WCF RIA models, so I tend to use the first option most often.

Answer 2

It sounds like you want to standardize the Id and Name properties across a set of entities. To do that, you would start with an interface:

public interface INamedEntity
{
    int Id { get; }

    string Name { get; }
}

Then, you would implement that interface in the partial class of each entity:

public partial class User : INamedEntity
{
    // ...
}

public partial class Role : INamedEntity
{
    // ...
}

Because those types already contain Id and Name , the interface is automatically satisfied.

Is that what you intended with your question?