I am looking for some guidance on a situation we have. We are using silverlight and CSLA 3.8.0. The object model is such that we have an editable root that contains an editable child exposed as a property. The use case calls for allowing the user to select from a list of these child info objects to set the editable root's child property.
My understanding is that best practice is not to expose the child static fetch method. Should we expose a method on the parent LoadChildEntity which takes an instance of the childInfo object? This method would then call the internal static child fetch method which would then in turn execute the dataporta.FetchChild using the local proxy and place the code to 'hydrate' the editable child in the Child_Fetch...am I making sense?
So you basically have something like
Root->Child
And you also have
ChildItems->ChildItemInfo
Root is an editable root, and Child is an editable child.
ChildItems is probably a readonly list and ChildItemInfo is probably a readonly child.
The user selects a ChildItemInfo, and you need to instantiate a Child object that corresponds to it, so you can make that the child of Root.
And, of course, you want to keep the UI code as simple (and dumb) as possible, so the UI developer can't make a mistake.
So I'd put a method on Root called AddChild() or SetChild() - maybe SetChild(), since there's only one, and you aren't really "adding". Then the UI code would be something like this:
var selection = <some ChildItemInfo from the UI>;
_root.SetChild(selection);
The SetChild() method in Root accepts the readonly child - primarily to get its Id property (I assume). Using that information it can get the child object:
public void SetChild(ChildItemInfo info)
{
var dp = new DataPortal<Child>();
dp.FetchCompleted += (o, e) =>
{
this.Child = e.Object;
};
dp.BeginFetch(new SingleCriteria<Child, int>(info.Id));
}
This does mean that your Child class will implement a DataPortal_Fetch() that accepts the SingleCriteria parameter, and loads the child with its data. Also, that DataPortal_Fetch() must call MarkAsChild() for this to work.
You might also put that data portal code in an internal scoped factory method on the Child class - that's really up to you.
Thanks for the prompt response on this, I know you are a busy guy.
That's the basic idea, except that the ChildInfo object has all the data needed to create the EditableChild so we don't need to ge back to the server.
The only difference in my thinking is that we would use Dataportal.FetchChild... So the parent's SetChild method would call the child's static internal factory method which would call dataportal fetch child (so that we don't need to call MarkAsChild().)
I think I muddied the waters by referring to the local proxy... when we use FetchChild there is no local proxy yes? There is no client\server interaction the call is just 'delegated' to the private Child_Fetch method?
public class Parent// in shared .cs file
{
private static PropertyInfo<Child> ChildProperty = RegisterProperty<Child>(c => c.PropChild);
public Child PropChild
{
get
{
return GetProperty(ChildProperty);
}
private set
{
SetProperty(ChildProperty, value);
}
public void SetChild(ChildItemInfo info)
{
this.PropChild = Child.GetChild(info);
}
}
public class Child //in 'shared' .cs file
{
internal static void GetChild(ChildItemInfo info)
{
DataPortal.FetchChild<Child>(info);
}
private void Child_Fetch(ChildItemInfo info)
{
//populate this with info
}
}
The problem is that FetchChild() won’t go across the wire. So in
an n-tier deployment you must call Fetch() or your code will try to run
the data access code on the client and it will fail.
I think that is our desired result. Since the info object has all the data required for the editable child, our intent is to use that as the datasource....
Is this bad design as it couples our info object with our editable object?
This is probably fine, as long as you remember that the Child_Fetch() will run on the machine where it was invoked - client or server. So it should be written to be location neutral - not making assumptions about location-specific context.
Copyright (c) Marimer LLC