WCF objects, multiple IList implementation and serialization errors

Problem:

WCF contract objects cannot implement 2 types of lists (ie: List and List).

Long-winded explanation:

I'm building a WCF service on top of an existing core system, and I'm trying to work out the best way to implement some of my business objects.

The core system utilizes interfaces for all business objects - Person management functionality, for instance, requires that I pass in an object which implements IPerson. Nothing out of the ordinary here.

The goal is to have a contact object (Person) which can be used on the service side of things, and also implements IPerson so that it can be passed into the core without requiring a conversion layer. This all works just fine for items like Person.

The issue comes in for lists: a method in the core, for instance, might require a IPersonList to be passed in, and as anyone who's dealt with inherited generics will know, List does not inherit fro开发者_开发百科m IList.

In our currently running ASMX service, we implement this with some up/down casting in the web objects. "WebPerson" will inherit from List, and implement IList explicitly so that the IList properties do not show up on the WSDL.

In WCF, however, if you try to use this same object, you will get the following error:

Type 'Cssi.IBroker.Service.Cssi.Contracts.PersonList' with CollectionDataContractAttribute attribute is an invalid collection type since it has multiple definitions of interface 'IList`1'.

Apparently, now that the new WCF serializer knows how to serialize IList, it's no longer able to ignore the second explicit implementation.

If possible, I'd like to avoid creating a PersonList object just for the contracts and then converting to and from an IPersonList object for each call. Changing the core business logic to use concrete objects designed just for the WCF services isn't an option.

Help!

I ended up deciding the best route was a set of dedicated objects used only for the contracts. With them being dedicated to one task, I was able to keep them cleaner without having to compromise my internal design for the sake of the WSDL. For the WSDL objects themselves, I ended up using arrays instead of IList.

The extra step of conversion is a bit cumbersome, but less than trying to keep my core objects WCF friendly would be.