У меня есть приложение WPF, которое до сих пор было только клиентским, но теперь я работаю над его разделением на клиентскую и серверную части. В этой работе я представляю WCF для взаимодействия клиент-сервер. В моем приложении несколько проектов, и требуются ссылки на службы более чем в одном из них.
Первоначальное усилие при разделении состоит в том, чтобы делать все «прямо вперед». Все проекты, которым необходимо взаимодействовать со службой, получают ссылку на службу, как и основной проект приложения WPF - чтобы получить там app.config. Я считаю, что это довольно быстро превращается в беспорядок, и я не могу представить, что это типичная архитектура, которую используют люди? Я также видел проблемы с тем фактом, что каждая из ссылок на сервисы генерирует новую реализацию классов DataContract - следовательно, нет общего понимания классов DataContract в перекрестных проектах. У меня есть несколько классов ViewModel в одном проекте, а в другом проекте создается экземпляр ViewModel. Я хотел бы передать объект, полученный от службы, но не могу, поскольку сгенерированное клиентское представление полученного объекта отличается в каждом проекте.
Итак, есть ли рекомендуемый способ структурирования такого разделения клиент / сервер с использованием WCF? Или принципы, которым нужно следовать? Я думаю об одном общем проекте Proxy, используемом на стороне клиента, который осуществляет связь со службами, обертывает полученные данные и возвращает данные в форме, хорошо известной клиентским библиотекам. Должна быть указана только одна ссылка на службу, и я думаю, мне нужен только App.config в проекте wpfApp? Имеет ли это смысл?
