Вопрос по моделированию Silverlight и шаблону репозитория
Прежде всего извините мой плохой английский! Я вижу во многих учебниках по 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. В этом решении вид и видовые модели не меняются!
Как насчет моего решения? Я иду в правильном направлении? Есть ли хороший пример, учебник, шаблон по этому поводу? Любое ключевое слово будет хорошо!:) Спасибо!
1 ответ
Вообще я думаю, что ваша идея скорее плохая, чем хорошая. Прежде всего, вы говорите, что интерфейс вашего сервиса нестабилен, что если он изменится. Хорошо, если ваше приложение и служба являются частью единого программного процесса, странно, что кто-то захочет изменить имя свойства вашего сервиса, а не исправить приложение, потому что они будут связаны друг с другом.
Ваш подход выглядит как ненужное звено в цепочке, которое необходимо поддерживать, и, как правило, будет прокси для вашей реальной услуги. Цель состоит в том, чтобы предоставить "константу" (что, если вам нужно изменить интерфейс репозитория, я думаю, что вероятность того, что это потребуется, очень близка к вероятности требуемого изменения в вашей службе по умолчанию, и вы ничего не выиграете, потому что приложение должно быть в любом случае переназначить) часть полного интерфейса вашего сервиса. Но я считаю, что если сервисный интерфейс начнет содержать больше функций, чем ваш сервис репозитория, вам придется перемещать их и копировать в него зеркальные функции.
Так что, как правило, вы не получите много пользы, но вам придется часто выполнять работу X2 на стороне сервера.