SL approach?

SL approach?

Old forum URL: forums.lhotka.net/forums/t/7835.aspx


greengumby posted on Wednesday, October 21, 2009

Hi,

Just wondering what ppl's opinions are here.

Scenario is a Person with a non-required address field and 2way binding on the address textbox in a Silverlight application.

1st Option
Server Side on DataPortal_Create() create the address instance and send down to client so UI can directly edit.

Downside I see with this approach. If they don't fill in the address field it will put a blank in the database because of IsDirty and IsNew.

Maybe on the non-required child objects MarkClean() after the DataPortal_Create?


2nd Option
Don't send the Address class to the client and have the Silverlight add a new child should it be required.

One plus is that less data over the wire but I am unsure about 2way binding of controls when there is nothing to bind to.

Maybe I have missed option 3 :)

Any Suggestions appreciated
Many Thanks
Jeremy

RockfordLhotka replied on Wednesday, October 21, 2009

Some things to consider.

First, you can have the DataPortal_Create() run on the client - CSLA .NET for Silverlight has an equivalent to the RunLocal attribute. So if you don't need to load default values for the new object from the database, it is probably better to use this option (a parameter on DataPortal.BeginCreate()) to run that code on the client.

Second, your address object is a child object, so normally you wouldn't use DataPortal_Create() in any case, but instead would use Child_Create(). This means the parent object will call DataPortal.CreateChild(), not DataPortal.Create() - and the result of doing this is that the object would be created on the client, not the server.

Third, you can use lazy loading to create the address object on demand. The only real trick to this is that you must design your UI to not attempt to bind to the parent object's Address property unless the user does something to explicitly edit that data. Otherwise data binding will trigger the lazy loading when it binds to the property.

Fourth, you are right, XAML binding requires an object to bind against. So if the UI elements try to bind, you need an object against which they can bind.

ajj3085 replied on Wednesday, October 21, 2009

I've done something similar and I call MarkClean in the Child_Create method.

greengumby replied on Wednesday, October 21, 2009

Thanks Guys, I suppose the reason why I bring this up is that we now have a Silverlight Developer who has never seen a CSLA object and Im trying to shield him as much as I can. As far as I can see by MarkingClean on CreateChild() its a good solution to those properties that are required for binding but not required for data. Rocky thanks for the [RunLocal] attribute that makes complete sense :) Cheers Jeremy

Copyright (c) Marimer LLC