Silverlight, асинхронная, ленивая загрузка, что лучше?

Question

Я начал использовать silverlight / flex и сразу столкнулся с асинхронным вызовом службы. Я привык решать проблемы доступа к данным OO-способом с одним механизмом выборки сервера или другим.

У меня есть следующий пример тривиального кода:

public double ComputeOrderTotal(Order order) 
{ 
   double total = 0;
   // OrderLines are lazy loaded
   foreach (Orderline line in order.Orderlines) 
   { 
       // Article,customer are lazy loaded 
       total = total + line.Article.Price - order.Customer.discount;
   }
   return total;
}

Если я правильно понимаю, этот код невозможен во Flex / Silverlight. Ленивая загрузка заставляет вас работать с обратными вызовами. ИМО простой пример выше будет большим беспорядком.

Может кто-нибудь дать мне структурированный способ реализации вышеизложенного?

Edit:

• Проблема та же для Flex / Silverlight, псевдокод будет делать хорошо
• Это на самом деле не связано с ORM, но большинство форм используют ленивую загрузку, поэтому я удалю этот тег
• Проблема ленивой загрузки в модели
• Приведенный выше пример был бы очень выполнимым из всех данных в памяти, но мы предполагаем, что некоторые должны быть получены из сервер
• Closueres не помогают, так как иногда данные уже загружены и асинхронная выборка не требуется

Answer 1

Flex имеет однопоточную модель. Если вы сделаете синхронный вызов веб-серверу, вы заблокируете весь графический интерфейс приложения. У пользователя будет замороженное приложение до завершения вызова (или истечения времени ожидания в случае ошибки сети и т. Д.).

Конечно, настоящие программы RIA написаны не так. Их GUI остается доступным и отзывчивым для пользователя с помощью асинхронных вызовов. Это также позволяет иметь реальные индикаторы прогресса, которые предлагают кнопки отмены и тому подобное, если природа взаимодействия требует такого.

Старые, плохие пользовательские приложения Web 1.0 демонстрировали синхронное поведение при взаимодействии с веб-уровнем.

Как указывает моя связанная статья, асинхронная однопоточная модель в сочетании с замыканиями ActionScript3 - это хорошо, потому что это гораздо более простая модель программирования, чем альтернатива - написание многопоточных приложений. Многопоточность была подходом к написанию клиент-серверных приложений на Java Swing или C # .NET WinForm для обеспечения одинаково гибкого и гибкого пользовательского интерфейса в графическом интерфейсе.

Вот еще одна статья, которая углубляется в эту тему асинхронной, распределенной / управляемой событиями архитектуры распределенных приложений:

Создание эффективных распределенных программных систем предприятия коммуникация на основе данных по сравнению с коммуникацией на основе поведения

Answer 2

В моем непосредственном опыте с Flex я думаю, что это обсуждение становится слишком сложным.

Ваш концептуальный вид ОО не отличается между синхронизацией и асинхронностью. Единственное отличие состоит в том, что вы используете обработчики событий для обработки диалога с хостом в DAL, а не что-то возвращаемое из вызова метода. И это часто происходит полностью на стороне хоста и не имеет ничего общего с Flex или Silverlight. (Если вы используете AIR для приложения рабочей станции, то это может быть в клиентском коде, но то же самое применимо. Также, если вы используете длительный AJAX. Silverlight, конечно, не имеет эквивалента AIR.)

Мне удалось спроектировать все, что мне нужно, без каких-либо других изменений, необходимых для обеспечения асинхронности.

Answer 3

Я не могу общаться с Silverlight, но Flex - это клиентская технология веб-браузера, и в нее не встроен драйвер базы данных во время выполнения Flash. Вместо этого вы можете взаимодействовать по протоколу HTTP с веб-сервером. Он находится на веб-сервере среднего уровня, где вы будете выполнять любые ORM в отношении соединения с базой данных, такие как Java JDBC. Hibernate ORM и iBATIS - два популярных варианта в пространстве среднего уровня Java.

Также из-за этого:

Ошибки распределенных вычислений

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

Вместо этого вы делаете асинхронные вызовы для извлечения данных, загружаете данные в объект (ы) модели вашего клиентского приложения и приступаете к выполнению операций с моделью. С Flex и BlazeDS вы также можете передавать данные промежуточного уровня клиенту и асинхронно обновлять объекты модели клиента. (Привязка данных - это один из способов реагирования на обновления данных в зависимости от событий.)

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

В этой статье я расскажу об этом более подробно и с точки зрения Flex:

Асинхронный ввод / вывод Flex против Java и C # Явный поток

Answer 4

Да, я должен согласиться с тем, что O / R-сопоставление обычно выполняется на стороне сервера вашего приложения. В SilverLight асинхронный способ выполнения является желательным шаблоном для использования при работе со службами. Почему услуги? Потому что, как я уже говорил, в настоящее время нет инструмента отображения O / R, который можно было бы использовать на стороне клиента (SilverLight). Наилучший подход заключается в том, чтобы отображать данные O / R в службе, которая может использоваться приложением SilverLight. На данный момент наилучшим способом является использование Ado.Net DataServices для передачи данных, а на стороне клиента - для управления данными с помощью LINQ to Services. Что действительно интересно в ADS (бывший проект Astoria), так это то, что он разработан для использования с Entity Framework, но хорошие люди также реализовали поддержку IQueriable, так что в основном вы можете подключить любого поставщика данных, который поддерживает LINQ. Чтобы назвать несколько, вы можете рассмотреть Linq To Sql, Telerik OpenAccess , LLBLGen и т. Д. Чтобы отправить обновления обратно на сервер, источник данных необходим для поддержки ADS IUpdateable.

Вы можете точно посмотреть, как это можно сделать, в серии постов, которые я подготовил здесь: Начало работы с ADO.NET Data Services и Telerik Open Access

Answer 5

C # 5 Конструкция async / await будет почти такой же, как я хочу ..

презентация часов Андерса Хейлсберга

Answer 6

Говоря о Silverlight, обязательно стоит проверить RIA services .

Проще говоря, он переносит DataContext с сервера на клиент, откуда вы можете асинхронно запрашивать его (нет необходимости писать службы WCF вручную, все это делается RIA).

Answer 7

Silverlight - это клиентская технология, и объектно-реляционное отображение происходит полностью на сервере. Таким образом, вы должны забыть об ORM в Silverlight.

Следуя вашему примеру, вы должны создать веб-сервис (SOAP, REST ...), который может предоставить вашему клиенту silverlight полный объект "Order". Если у вас есть объект, вы можете работать с ним, не общаясь с сервером в обычном режиме - синхронно.