views:

2504

answers:

7

Hello, I started to use silverlight/flex and immediately bumped into the asynchronous service calling. I'm used to solving the data access problems in an OO-way with one server fetch mechanism or another.

I have the following trivial code example:

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;
}

If I understand correctly, this code is impossible in Flex/Silverlight. The lazy loading forces you to work with callbacks. IMO the simple expample above will be a BIG mess.

Can anyone give me a structured way to implement the above ?

Edit:

  • The problem is the same for Flex/Silverlight, pseudo code would do fine
  • Its not really ORM related but most orms use lazy loading so i'll remove that tag
  • The problem is lazy loading in the model
  • The above example would be very doable of all data was in memory but we assume some has to be fetched from the server
  • Closueres dont help since sometimes data is already loaded and no asynchronous fetch is needed
A: 

I'm looking for the exact same answer. I find myself struggling a bit in AS3.

dlux
A: 

Silverlight is a client technology and the Object - Relational mapping happens completely in the server. So you have to forgot about the ORM in Silverlight.

Following your example what you have to do is to create a webservice (SOAP, REST...) that can give your silverlight client the complete "Order" object. Once you have the object you can work with it with no communication with the server in a normal - synchronous way.

DaniCE
You are right ORM on server wrong tag.What if for some reason Customer had a property called OrderHistory...When I get the customer it will load the history. Every order in the history will load the customers, which will load the history.End result: The whole database is fetched.
Julian de Wit
+1  A: 

Yes I must agree that O/R mapping is usually done on the server-side of your application. In SilverLight asynchronous way of execution is the desired pattern to use when working with services. Why services? Because as I said before there is no O/R mapping tool at the moment that could be used on the client-side (SilverLight). The best approach is to have your O/R mapped data exposed by a service that can be consumed by a SilverLight application. The best way at the moment is to use Ado.Net DataServices to transport the data, and on the client-side to manage the data using LINQ to Services. What is really interesting about ADS (former Astoria project) is that it is designed to be used with Entity Framework, but the good folks also implemented support for IQueriable so basically you can hook up any data provider that support LINQ. To name few you can consider Linq To Sql, Telerik OpenAccess, LLBLGen, etc. To push the updates back to the server the data source is required to support the ADS IUpdateable.

You can look just exactly how this could be done in a series of blogposts that I have prepared here: Getting Started with ADO.NET Data Services and Telerik Open Access

Sorry wrong tag.. It's not orm.. It's lazy loading that is the problem.
Julian de Wit
+1  A: 

I can't speak to Silverlight but Flex is a web browser client technology and does not have any database driver embedded in the Flash runtime. You can do HTTP protocol interactions to a web server instead. It is there in the middle-tier web server where you will do any ORM with respect to a database connection, such as Java JDBC. Hibernate ORM and iBATIS are two popular choices in the Java middle-tier space.

Also, because of this:

Fallacies of Distributed Computing

You do not do synchronous interactions from a Flex client to its middle-tier services. Synchronous network operations have become verboten these days and are the hallmark signature of a poorly designed application - as due to reasons enumerated at the above link, the app can (and often will) exhibit a very bad user experience.

You instead make async calls to retrieve data, load the data into your client app's model object(s), and proceed to implement operations on the model. With Flex and BlazeDS you can also have the middle-tier push data to the client and update the client's model objects asynchronously. (Data binding is one way to respond to data being updated in an event driven manner.)

All this probably seems very far afield from the nature of inquiry in your posting - but your posting indicates you're off on an entirely incorrect footing as to how to understand client-side technologies that have asynchronous and event-driven programming baked into their fundamental architecture. These RIA client technologies are designed this way completely on purpose. So you will need to learn their mode of thinking if you want to have a good and productive experience using them.

I go into this in more detail, and with a Flex perspective, in this article:

Flex Async I/O vs Java and C# Explicit Threading

RogerV
I Also did flex programming and keeping in synch by datapush seemed Ok. I used a .net implementation that was very blaseDS alike..But still sometimes you dont want all the data in memory.
Julian de Wit
Pretty much any web server-side implementation can implement Comet Pattern (or long polling) as a means to do data push. One advantage of Java-based BlazeDS, tho, is that it can be modified to work on Java NIO, which permits scaling to like 10,000 to 20,000 concurrent connections against the server.
RogerV
+1  A: 

In my direct experience with Flex, I think this discussion is getting too complicated.

Your conceptual OO view is no different between sync and asynch. The only difference is that you use event handlers to deal with the host conversation in the DAL, rather than something returned from a method call. And that often happens entirely on the host side, and has nothing to do with Flex or Silverlight. (If you are using AIR for a workstation app, then it might be in client code, but the same applies. As well if you are using prolonged AJAX. Silverlight, of course, has no AIR equivalent.)

I've been able to design everything I need without any other changes required to accomodate asynch.

le dorfier
+1  A: 

Flex has a single-threaded model. If you make a synchronous call to the web server, you'd block the entire GUI of the application. The user would have a frozen application until the call completes (or times out on a network error condition, etc.).

Of course real RIA programs aren't written that way. Their GUI remains accessible and responsive to the user via use of async calls. It also makes it possible to have real progress indicators that offer cancel buttons and such if the nature of the interaction warrants such.

Old, bad user experience web 1.0 applications exhibited the synchronous behaviour in their interactions with the web tier.

As my linked article points out, the async single-threaded model coupled with ActionScript3 closures is a good thing because it's a much simpler programming model than the alternative - writing multi-thread apps. Multi-threading was the approach of writing client-server Java Swing or C# .NET WinForm applications in order to achieve a similarly responsive, fluid-at-all-times user experience in the GUI.

Here's another article that delves into this whole subject matter of asynchronous, messaging/event-driven distributed app architecture:

Building Effective Enterprise Distributed Software Systems data-driven communication vs behavior-driven communication

RogerV
A: 

Speaking about Silverlight, you should definitely check RIA services.

Simply, it brings the DataContext from the server to the client from where you can asynchronously query it (there is no need to write WCF services by hand, it's all done by RIA).

gius