Интерфейс сериализации Silverlight / Web Service для использования на стороне клиента

Question

У меня есть решение Silverlight, которое ссылается на сторонний веб-сервис. Этот веб-сервис генерирует XML, который затем обрабатывается в объекты для использования в привязке Silverlight. В какой-то момент мы обрабатывали XML для объектов на стороне клиента, но столкнулись с проблемами производительности и решили перенести эту обработку на прокси в веб-проекте хостинга для повышения производительности (что и было). Это явно чрезмерное упрощение, но оно должно сработать. Моя основная структура проекта выглядит следующим образом.

• Решение
• Solution.Web - содержит веб-страницу который принимает Silverlight, а также прокси, которые получают доступ к веб-сервисам и процессы, как требуется и, очевидно, ссылки на эти сети услуги).
• Solution.Infrastructure - удерживает ссылки на прокси веб-сервисы в проекте .Web весь genned код из сериализованных объектов из тех прокси и код вокруг этих объектов это должно быть на стороне клиента.
• Solution.Book - Особенности проект, который использует объекты в вопрос после обработки в Инфраструктура.

Я определил следующий интерфейс и класс в веб-проекте. Они представляют тип объектов, в которые преобразуется XML из оригинального стороннего производителя, и, поскольку это единственный проект в приложении Silverlight, который фактически является серверным, он был местом для их определения и использования.

//Doesn't get much simpler than this.
public interface INavigable
{
    string Description { get; set; }
}


//Very simple class too
public class IndexEntry : INavigable
{
    public List<IndexCM> CMItems { get; set; }
    public string CPTCode { get; set; }
    public string DefinitionOfAbbreviations { get; set; }
    public string Description { get; set; }
    public string EtiologyCode { get; set; }
    public bool HighScore { get; set; }
    public IndexToTabularCommandArguments IndexToTabularCommandArgument { get; set; }
    public bool IsExpanded { get; set; }
    public string ManifestationCode { get; set; }
    public string MorphologyCode { get; set; }
    public List<TextItem> NonEssentialModifiersAndQualifyingText { get; set; }
    public string OtherItalics { get; set; }
    public IndexEntry Parent { get; set; }
    public int Score { get; set; }
    public string SeeAlsoReference { get; set; }
    public string SeeReference { get; set; }
    public List<IndexEntry> SubEntries { get; set; }
    public int Words { get; set; }
}

Опять; оба эти элемента определены в веб-проекте. Обратите внимание, что IndexEntry влияет на INavigable. Когда код для IndexEntry автоматически генерируется в проекте инфраструктуры, определение класса не включает в себя реализацию INavigable. Обнаружив это, я подумал: «Нет проблем, я создам еще один частичный файл класса, повторяющий имплментацию». К сожалению (я полагаю, потому что он не сериализуется), этот интерфейс не распознается в проекте инфраструктуры, поэтому я не могу просто сделать это. Вот где это становится действительно странным. Проект BOOK МОЖЕТ увидеть интерфейс INavigable. Фактически, я использую его в Book, хотя Book не имеет ссылки на веб-сервис в веб-проекте, где это определяется, хотя инфраструктура это делает. В качестве теста я связался с исходным файлом INavigable из проекта «Инфраструктура». Это позволило мне сослаться на него в этом проекте и скомпилировать, но это привело к хаосу в проекте Book, потому что теперь существует противоречие между определением в инфраструктуре и определением в веб-службе веб-проекта. Такое поведение я бы ожидал.

Итак, чтобы попытаться подвести итог. Веб-проект имеет веб-сервис, который обрабатывает данные стороннего сервиса, и в нем определены класс и интерфейс. Класс реализует интерфейс. Проект инфраструктуры ссылается на веб-сервис в веб-проекте, а проект Book ссылается на проект инфраструктуры. Внедрение интерфейса в класс НЕ сериализуется, поэтому автоматически генерируемый код в INfrastructure не показывает эту взаимосвязь, что приводит к дальнейшему разрушению кода. Проект Book, который является дальнейшим нисходящим потоком, МОЖЕТ увидеть интерфейс, как определено в веб-проекте, хотя его единственная ссылка - через проект инфраструктуры; который не может видеть это.

Я просто упускаю что-то простое здесь? Могу ли я применить атрибут к определению интерфейса или к его имплементации в классе, чтобы обеспечить его видимость вниз по течению? Что-нибудь еще, что я могу сделать здесь?

Я знаю, что это немного запутанно, и кто-нибудь еще со мной здесь, спасибо за ваше терпение и любые советы, которые вы могли бы дать.

Приветствия

Steve