Вопрос по моделированию Silverlight и шаблону репозитория

Question

Прежде всего, извините, мой плохой английский!Во многих руководствах по Silverlight я вижу следующее:

У нас есть модели на стороне сервера, например, Product.В веб-сервисе есть метод, например Ilist GetProducts ();На стороне клиента класс Product генерируется, когда мы добавляем сервисную ссылку.Тогда мы будем использовать эту модель продукта в viewmodels и xaml.Но что произойдет, если кто-то внесет изменения на стороне сервера или если изменение Модели продукта, например, свойство «Name», будет «NameProperty» или кто-то попытается изменить веб-сервис на другой.Прокси-класс Product также изменится на стороне клиента, после чего нам придется «обновить» viewmodels, bindings и т. Д., Которые используют класс Product.

А как насчет этого решения?:

НаСторона Silverlight У меня есть интерфейс IProduct, который содержит все свойства, которые будут использовать viewmodels и xaml.Я делаю интерфейс IRepository, который имеет метод IList GetProducts ().Я реализую этот интерфейс, например, WCFRepository, который получает данные из службы wcf.Реализация метода GetProduct отобразит все продукты на реализацию IProduct, просто скопируйте свойства в реализацию IProduct.Поэтому, когда Продукт на стороне сервера изменяется, мне нужно только изменить отображение в WCFRepository.Или, если я меняю службу WCF на другую, мне нужно только написать OtherRepository и записать сопоставление в реализации метода GetProducts.В этом решении представление и модели представления не меняются!

Как насчет моего решения?Я иду в правильном направлении?Есть ли хороший пример, учебник, шаблон по этому поводу?Любое ключевое слово будет хорошо!:) Спасибо!

Answer 1

Обычно я думаю, что ваша идея скорее плохая, чем хорошая.Прежде всего, вы говорите, что интерфейс вашего сервиса нестабилен, что если он изменится.Хорошо, если ваше приложение и служба являются частью одного программного процесса, странно, что кто-то захочет изменить имя свойства вашей службы, а не исправлять приложение, потому что они будут связаны друг с другом.

Ваш подход выглядит как ненужная ссылка вцепочка, которая должна быть сохранена, и, как правило, будет прокси для вашего реального обслуживания.Цель состоит в том, чтобы предоставить «константу» (что, если вам нужно изменить интерфейс репозитория, я думаю, что вероятность того, что это потребуется, очень близка к вероятности требуемого изменения в вашем сервисе по умолчанию, и вы ничего не выиграете, потому что приложение должно бытьв любом случае переназначить) часть полного интерфейса вашего сервиса. Но я считаю, что если сервисный интерфейс начнет содержать больше функций, чем ваш сервис репозитория, вам придется перемещать их и реплицировать в нем зеркальные функции.

В общем, выне принесет много пользы, но часто приходится выполнять работу X2 на стороне сервера.