Silverlight может использовать службы WCF, Web Services, REST, службы .NET RIA, но, похоже, наиболее предпочтительны службы Silverlight и .NET RIA.
Я хочу знать, есть ли какие-то общие проблемы [которые могут быть показом проб, если идти вперед с этим комбо], что вы видели в практической реализации SL с .NET RIA Services.
Спасибо, Рахул
Работа с метаданными (и написание ее самостоятельно) - это действительно боль в заднице. Особенно, когда вам нужно обновить свою модель. Учебные приложения RIA выглядят достаточно хорошо в небольшой базе данных, но, работая с моделью, состоящей из десятков пользователей, вы будете тратить больше времени на обновление метаданных, чем на программирование самого приложения. Это также связано с определением валидации и всеми сообщениями проверки и описания свойств из ресурсов. Но мы создали несколько T4-шаблонов, поэтому все они генерируются автоматически.
С другой стороны, мы используем RIA в двух проектах, и я должен сказать, что это лучшее, что мы можем получить. У нас были некоторые проблемы с проверкой, но она может быть решена (проверка перед проверкой того, изменилось ли значение свойства). И как только вы осознаете управление памятью с помощью RIA (вы не хотите загружать всю базу данных в память на клиенте и т.д.), Ее можно использовать в реальной жизни.
К сожалению, нет серебряной пули, поэтому, если вы, например, планируете другие клиенты, чем ваше приложение SL, подключаться к серверу, вы, вероятно, должны смотреть где-то еще (WCP Data Services, может быть?). Или, если вы не хотите обновлять данные от своего клиента, я вижу, что RIA является излишним.
СЛЕДУЮЩИЙ МОЙ ПРЕДЫДУЩИЙ ОТВЕТ ЗДЕСЬ НЕДОСТАТКИ УСЛУГ RIA: С другой стороны, недостатком услуг ria является отсутствие гибкости. В основном это похоже на трубку, которая соединяет класс на стороне сервера со своим представителем на стороне клиента таким образом, что вы работаете с классом на стороне клиента, как будто вы работали непосредственно в классе на стороне сервера. Если способ использования этой "трубки" подходит для вашего приложения, вы получаете множество бесплатных услуг (без написания кода...). Однако есть ограничения, которые нельзя удалить отдельно:
1) У вас нет той же свободы в определении поведения, атрибута и т.д., чтобы изменить поведение веб-службы. Например, вы не можете определить распределенную транзакцию, включающую более одного веб-сервиса. Трудно добавить новые конечные точки.... Вы должны написать код.... не просто изменять конфигурационный файл.
2) Вы можете определить только один метод Insert/one update/one get для каждого класса. Если вы применяете фильтрацию к клиентскому запросу через LINQ, она применяется только на клиенте, то есть все данные загружаются с сервера, а затем фильтруются на клиенте. Напротив, если вы используете службы данных WCF на основе OData и вы определяете запрос на стороне клиента. ЭТОТ ВОПРОС ПЕРЕВОДА В ВОССТАНОВЛЕНИЕ ЗАПРОСА (запрос, закодированный в URL-адресе запроса) ПОЭТОМУ ТОЛЬКО ДАННЫЕ, ТРЕБУЮЩИЕ ВАШЕГО ФИЛЬТРА, НАСТОЯТЕЛЬНО ЗАГРУЖАЮТСЯ ОТ СЕРВЕРА. Для получения дополнительной информации о службе данных WCF см. здесь.
3). В отличие от служб данных WCF у вас нет службы валидации, предлагаемой как в службе RIA. Однако вы можете продолжить использование аннотаций данных с помощью моего инструмента Validation Toolkit для WPF и Silverlight, который доступен бесплатно здесь
Я использую RIA-Services в течение нескольких месяцев и несколько разных приложений и обнаружил, что могу заставить его делать почти все, что мне нужно. Это экономит вам много времени, используя умное генерирование кода, чтобы заботиться о большом количестве сантехники.
Это лучше всего использовать, если вы создаете прямое приложение CRUD с использованием EF, если это так, тогда вы должны быть в порядке.
Если вы делаете что-то немного по-другому, это требует немного больше работы, но по-прежнему это (на мой взгляд) лучший вариант для получения данных для вашего клиента silverlight. Есть некоторые небольшие неприятности, но нет показательных пробок, которые я нашел.
Например, я использовал его с SQL Credentials (пользовательские журналы в приложении Silverlight, используя их логин SQL, и я динамически создаю строку подключения, используя имя пользователя + пароль). Это заняло немного больше работы, но оно отлично работает.
Я также использовал его для возврата данных клиенту из хранимых процедур, а не из сущностей, снова это требует немного больше работы, но оно отлично работает.
Услуги Ria создаются только для использования с Silverlight. Они по существу являются стандартным "пакетом", готовым к использованию Silverlight. Преимущество состоит в том, что у вас есть много услуг без необходимости писать код i.e.:
Все, что делает Ria, может быть выполнено с помощью WCF и с другим доступным программным обеспечением и, в частности, с услугами передачи данных Wcf. Например, для аннотаций данных я нашел эту библиотеку, которые выполняют лучшую работу, чем службы Ria, поддержка членства требует активации уже существующей конечной точки доступа WCF, и, наконец, проблема с исключениями легко разрешается путем написания поведения WCF. Код доступен здесь: http://www.silverlightshow.net/Storage/10Tips.zip. Дело в том, что с Ria Service у вас есть все это щелчком мыши!. С другой стороны, Ria Services действительно сложно настроить... так что если вам не нравится стандартное решение, которое они предлагают, вы просто не можете их использовать.
Услуги службы Ria и услуги по отдыху предлагают совершенно аналогичный доступ к классам на стороне сервера, которые часто являются классами фреймворка сущностей (но не обязательно... поскольку, по-видимому, кажется, что некоторые программисты верят). Основным преимуществом RIA Services является то, что они обрабатывают проверку с использованием аннотаций данных на серверных классах и делают это разумным способом: они автоматически генерируют клиентские классы с теми же аннотациями данных и проверяют их, автоматически реализуя INotifyDataError на клиентский класс. Если вы используете пользовательские атрибуты и поместите расширение the.shared.cs(или .vb), эти определения атрибутов будут скопированы в клиенте silverlight и использованы при проверке на стороне клиента, в противном случае они будут использоваться только для проверки на стороне сервера...... для получения дополнительной информации см. мое сообщение в блоге
Я использую SL4 + EF для разработки нашего предприятия, и я нашел его, его сложно разрабатывать с помощью EF, если вы идете с моделью разработки по умолчанию. Я имею в виду, что на любом экране, который вы разрабатываете, для данных, которые вы используете EF, с таблицей/представлением, а затем очень быстро, ваша модель заглатывается. После добавления 20 новых страниц с 6 по 10 таблиц/представлений теперь очень сложно добавить объекты в edmx. Мне лично не нравится блоттинг. Если вы видите некоторые из вопросов, которые я задал, и на основе ответов, которые, как представляется, для развития уровня предприятия, не используйте прямо из EF-функций вместо этого, создайте модель домена, используя POCO с PI, а затем используйте это для разработки вашего приложения. Я еще не завершил один, но у меня нет личного результата. Еще одна вещь, я заметил, что это не связано с EF per se, а сама SL. Потратьте некоторое время и поймите либо PRISM/MEF/Caliburn, и используйте это приложение. Одна из проблем, которые мне не нравятся в SL, - это тестируемость, даже несмотря на то, что тестирование SL-модулей там, само по себе не является хорошим модулем тестирования модулей. Также тестирование EF также не является легким. С помощью PRISM/MEF/Caliburn не просто тестирование легко, и ваше развитие будет действительно модульным. Поэтому перед тем, как вы начнете разработку, моя рекомендация - взглянуть на одну из фреймворков и вместо использования EF outof box использовать POCO для создания вашей модели домена, а затем использовать POCO для ее использования в SL. Надеюсь, это поможет.
Я действительно разочарован MS. Как видно из обсуждения этой темы, я не единственный, кто иногда путается всеми "инструментами", которые мы предоставляем MS. Проблема в том, что на самом деле не хватает управления и координации со стороны MS.
В результате есть очень похожие продукты с аналогичной функциональностью, где одна делает одну вещь лучше, а другую другую. И никто не может сказать, какой из них лучше использовать или даже тот, который будет поддерживаться в следующей версии.
У меня есть два примера.
Entity Framework vs Linq to SQL в .net 3.5 Они были очень похожи, оба делали то же самое. L2S должен был быть лучше для небольших проектов, EF для корпоративных. У L2S был намного лучший дизайнер и лучшая реализация LINQ. Предполагалось, что EF сможет сопоставлять больше таблиц базы данных с одним объектом, но это никогда не срабатывало. И, кстати, даже EF4 не имеет очень полезной функции L2S, которая Функция AssociateWith < > . И внезапно L2S больше не поддерживается, и каждый должен использовать EF. Должен быть кто-то, кто в самом начале сказал: "Остановитесь, у нас есть две аналогичные технологии. Давайте объединим две команды и сделаем один продукт лучшим из них".
Услуги RIA и службы передачи данных WCF Опять же, та же проблема. Две разные команды работают над двумя аналогичными продуктами. И с некоторыми лучшими функциями, и с другими. Но определенно, может быть один продукт с особенностями того и другого.
Как мы должны решить, какой из них использовать (помимо того, что потратили много времени на освоение обоих)? Какой из них будет устаревшим?
... это, вероятно, для сообщения в блоге, а не ответа здесь. Извините, мне просто нужно было написать это где-то, и, поскольку было много разговоров об этих проблемах, это казалось подходящим местом. Я обязательно попробую блог об этом позже.
Я написал сообщение в своем блоге о службах передачи данных Ria WCF и службе отдыха WCF, используя также некоторые выводы, сделанные здесь здесь.