Add Silverlight support for the Command Object.

[GoogleCodeExporter]

Add Silverlight support for the Command Object.

Original issue reported on code.google.com by bniemyjski on 23 Jul 2010 at 1:04

[GoogleCodeExporter]

Hi Blake,

I just started looking at this issue as well.  Looking at the code, I have the 
following question:  why do we call the Exists command before loading any 
children?  Is it purely for DB performance reasons?

The reason I ask is that I believe (still need to verify) that this will 
actually degrade the performance of Silverlight apps.  For example, if you have 
a parent with 5 children, you will need to make 10 async "over the wire" calls 
to your server.  An exists command and a retrieve for each child.  Each async 
call requires serialization/deserialization, compression/decompression (if 
implemented...and should be implemented), network round trip, etc.  I believe 
that just making the 1 call, even if it returns an empty child would have less 
overall performance implications in the SL world.

That being said, I may be missing some other reason for the Exists call.

Thoughts? 

Original comment by RoyMunso...@gmail.com on 28 Jul 2010 at 3:57

[GoogleCodeExporter]

Hello,

This was implemented this way to do a quick call to the database to see if the 
record already exists, so you don't get a RecordNotFoundException and you then 
know if you should create a new object etc...

I was thinking about this a while back about making the exists command generic 
and so you specify the type and it makes one trip to the server and caches the 
returned entity by a cache key. However, this will take some memory usage as 
well as you have to worry about business object changes (update, delete, etc..).

What do you think? I agree, less round trips and overhead is awesome. Just 
don't know of a solid generic way to implement this.

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 28 Jul 2010 at 7:08

[GoogleCodeExporter]

Having the Exists cache would be fantastic, but as you have pointed out, it's 
not a trivial problem to solve...

Just thinking out loud here, but is it necessary to throw an exception in the 
case that no data is found?  If the client needs to handle that case anyways, 
couldn't they just check for a null or empty object and handle it accordingly?

Original comment by RoyMunso...@gmail.com on 28 Jul 2010 at 7:41

[GoogleCodeExporter]

Hello,

I suppose this could be done, however for child objects rocky recommends 
throwing an exception.

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 29 Jul 2010 at 12:31

[GoogleCodeExporter]

I see...I guess he would know  :)

I guess the other thing that we could do would be to just call the retrieve, 
and just handle the exception if it does occur.  In the async world, we have to 
manually check that error anyways.

Original comment by RoyMunso...@gmail.com on 29 Jul 2010 at 2:46

[GoogleCodeExporter]

Either way, we still need to fix the Exists to work in SL.  Are you looking 
into this, or would you like me to?

Original comment by RoyMunso...@gmail.com on 29 Jul 2010 at 5:49

[GoogleCodeExporter]

Hello,

Could you please look into this, it would be a big help (esp since you are 
efficient in Silverlight).

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 29 Jul 2010 at 8:03

[GoogleCodeExporter]

Ok, so the good news is that I was able to make the Exists command work in SL.

The bad news is that I don't think that these calls to Exists are going to work 
as implemented.  I see that there was a System.Threading.ManualResetEvent setup 
to wait for the exists command to finish.  I don't think that this will work in 
SL.  This call blocks the UI thread (locks it right up), and it just times out 
every time, no matter how fast the result comes back.  From what I can see, 
other methods of "waiting" will produce the same results in SL.

I did some research, and it looks like others have tried to simulate 
synchronous calls in SL, without much luck.

I'm wondering if perhaps we should be looking for a more asynchronous solution 
to this issue?  Perhaps we need Rocky's assistance on this one?

Original comment by RoyMunso...@gmail.com on 3 Aug 2010 at 5:28

[GoogleCodeExporter]

Hello,

That sounds like a good idea. Do you have a post on rockys site for this?

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 22 Aug 2010 at 6:46

[GoogleCodeExporter]

No, I haven't posted anything.  Sorry, I've been really busy lately.

Original comment by RoyMunso...@gmail.com on 23 Aug 2010 at 4:50

[GoogleCodeExporter]

Ok, I had some time to look at this.  I have a working solution, but I still 
need to get it into the templates.  Basically, I had to change the way Exists 
work in SL.  As mentioned you can't "wait" (using a ManualResetEvent or 
similar) in SL.  In order to work around that, I basically changed the exists 
command to work more like the async factories...it now uses a callback instead 
of returning a value.  I can hopefully post a patch in the next day or so.

Original comment by RoyMunso...@gmail.com on 9 Sep 2010 at 6:36

[GoogleCodeExporter]

Ok, here is a patch which should have a working SL exists command.  I also 
included fixes for 2 other issues I found:

ReadOnlyChild.Generated.cst - There was VB code in the C# factory method
EditableChild.Generated.cst - The async functions were passing in an event 
handler of the child's type, not the type itself.

Original comment by RoyMunso...@gmail.com on 9 Sep 2010 at 8:45

Attachments:

• SLExistsPatchSept9.patch

[GoogleCodeExporter]

Hello,

Thanks for these changes, I have a few questions before I feel comfortable 
committing :). 

I see that you created this patch against the latest version yet somethings are 
still changed specifically. Like The changes in the partial methods, 
EditableChild and EditableChild list seem to be changed. What's wrong with the 
current implementation?

As far as MarkBusy/MarkIdle goes, I'm curious as to why these are also 
commented out if everything is Async? What issues exist with this?

The Exists command stuff looks great, until we get to the properties. I've 
found you simply can't go off of IsNew because the record might be part of a 
unique constraint and then you get an exception while trying to save. We need 
to find a way around this. The Exists needs to be in the if block above, thats 
why I initially had the ManualResetEvent. What are your thoughts on this?

Also the ReadOnlyProperties are never updated but I'm fine with updating these.

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 10 Sep 2010 at 12:48

• Changed state: AwaitingInfo

[GoogleCodeExporter]

EditableChild.Generated.cst - The async functions were passing in an event 
handler of the child's type, not the type itself.

I can see this reasons behind this change :).

Original comment by bniemyjski on 10 Sep 2010 at 2:28

[GoogleCodeExporter]

I have updated Properties as per our discussion.

Original comment by RoyMunso...@gmail.com on 13 Sep 2010 at 3:06

Attachments:

• PropertiesNoIsNewCheck.patch

[GoogleCodeExporter]

This issue was updated by revision r1943.

Fixed Issue 458: Add Silverlight support for the Command Object.

Original comment by bniemyjski on 15 Sep 2010 at 2:44

[GoogleCodeExporter]

Hello,

I'm going to be pushing CSLA 3.0.1 in the morning. Please let me know if you 
find anything :).

Thanks
-Blake Niemyjski

Original comment by bniemyjski on 15 Sep 2010 at 2:45

• Changed state: Fixed
• Added labels: Version-3.0.1

[GoogleCodeExporter]

I grabbed the latest build and did a quick test...seems ok to me.

Original comment by RoyMunso...@gmail.com on 15 Sep 2010 at 8:46