CSLA 6 how to create a child in a BusinessBindingListBase?

[michaelcsikos]

What is the CSLA 6 equivalent to:

 protected override object AddNewCore()
 {
     var item = Child.NewChild();

     Add(item);

     return item;
 }

I was expecting GetDataPortal<Child.Factory>() to be available.

Are we meant to [Inject] IDataPortal<Child.Factory> to the Create and Fetch methods and keep a reference in the list class?

IDataPortal<Child.Factory> ChildFactory { get; set; }

protected override object AddNewCore()
{
    var item = Child.NewChild(ChildFactory);

    Add(item);

    return item;
}

[CreateChild]
private void Create([Inject] IDataPortal<Child.Factory> childFactory)
{
    ChildFactory = childFactory;
}

[FetchChild]
private void Fetch(Guid                            parentId,
          [Inject] IChildDal                       dal,
          [Inject] IChildDataPortal<Child>         childDataPortal,
          [Inject] IDataPortal     <Child.Factory> childFactory)
{
    using (LoadListMode)
    {
        var list = dal.FetchList(parentId);

        foreach (var dto in list)
        {
            var item = Child.GetChild(childDataPortal, dto);

            Add(item);
        }
    }

    ChildFactory = childFactory;
}

[rockfordlhotka]

The AddNewCore method is location neutral, which means it can (and often does) run on the client.

The child data portal is not location neutral and must be running on the logical server within the context of the server-side data portal.

None of this is new, but in CSLA 6 it is more clear that you really shouldn't be using the child data portal independently on the client.

The solution is to create a child getter/creator/factory/whatever class to create/get the child. Somewhat like:

[Serializable]
public class ChildFactory : ReadOnlyBase<ChildFactory>
{
    public static readonly PropertyInfo<ChildType> ChildProperty = RegisterProperty<string>(nameof(Child));
    public string Child
    {
      get { return GetProperty(ChildProperty); }
      private set { LoadProperty(ChildProperty, value); }
    }

    [Create]
    private async Task Create([Inject]IChildDataPortal<ChildType> childPortal)
    {
      Child = await childPortal.CreateAsync();
    }

    [Fetch]
    private async Task Fetch(int id, [Inject]IChildDataPortal<ChildType> childPortal)
    {
      Child = await childPortal.FetchAsync(id);
    }
}

Then in your AddNewCore use this factory type with a root data portal to create/fetch the factory, which will contain the child in its Child property.

Of course you can use the RunLocal attribute on the create/fetch operations in this factory root if you are ok with the child being created on the logical client.

[michaelcsikos]

So the child collection must request an IDataPortal<Child.Factory> from the root as needed?

[rockfordlhotka]

I think the child collection has access to ApplicationContext, so:

var portal = ApplicationContext.GetRequiredService<IDataPortal<Child.Factory>>();

I'm actually considering removing the GetPortal method from BusinessBase, because you can always just get the required service from ApplicationContext, and I think it is confusing to have duplicate ways to do the same thing.

[rockfordlhotka]

As I was waking up this lazy Saturday morning I had a thought. So take it for what it is worth, but I think I'm right.

Why can't you just put a fetch operation on the child class? It gets set to be a child as it is added to the collection, not during the data portal operation. Then you can use the normal root FetchAsync method on the client-side data portal to retrieve the object, which is then added to the parent and becomes a child.

[crazyfox55]

So I spent a bit of time looking into this and I believe default parameters are not properly handled by the data portal matching algorithm. You are welcome to look through the code as well, please do if you have time, I wish default parameters could be used.
https://github.com/MarimerLLC/csla/blob/main/Source/Csla/Reflection/ServiceProviderMethodCaller.cs#L68

This is the sort of property I was looking for:
https://docs.microsoft.com/en-us/dotnet/api/system.reflection.parameterinfo.rawdefaultvalue?view=net-6.0

The work around is to overload the Create function which is basically what happens anyway. Aka have a Create() that calls The Create(bool) with "false".

I prefer that child objects be separate from their root version. For example imagine you have a Project with Tasks. I would breakdown editing into ProjectEdit, ProjectTaskEdit, and TaskEdit. On the Project editing view, ProjectEdit has a child list BusinessListBase of ProjectTaskEdit children. On the Task editing view, TaskEdit. It's totally reasonable to merge the ProjectTaskEdit and TaskEdit classes into one (using the Child attributes), however if the concept of People is added then PersonEdit, PersonTaskEdit become classes. Now TaskEdit is trying to manage 3 different use cases (TaskEdit, ProjectTaskEdit, PersonTaskEdit).

Let me know if any of this helps.

[TheCakeMonster]

Under the covers, there is no such thing as optional parameters with default values. Optional parameters are actually a compiler trick. At compile time, the default value is placed into the calling code.

I only came across this by accident, years ago. I added an optional parameter with a default value into the signature of an existing method of a class in a shared DLL and expected it not to cause breaking changes - but it did. Our consumers all started throwing MethodNotFound exceptions when we replaced the DLL in the bin folder with the updated version. We had to recompile all of the consumers to resolve the issue, at which point the default value was copied into the calling code.

Csla does runtime method discovery and binding to data access methods, so there is no way for the default value to be embedded into the consumer. As a result, there is no way that optional parameters could ever work as you expect when they form part of the method signature of a data access method.

[crazyfox55]

That is actually insane that they are implemented like that but I guess it removes one function call from the stack. I understood they were a compiler trick but had no idea that they didn't use method overloading. I think the keyword (or function attribute) "inline" from C++ should have been required to choose overloading vs injecting default values. Now I understand why the default values had to be compile time constants. But actually its possible to have public void Foo(bool Bar = false) and public void Foo() in the same class. The Foo() will take priority over the optional parameter overload. I'm sure Microsoft took the time to fully understand the consequences which is why I rarely see them use optional parameters.

Is there anyway to add this to the CSLA analyzers? I've seen CSLA 6 warn me about parameters not being serializable. So I feel like it is possible to add optional parameters as a warning.

[michaelcsikos]

OK, so optional parameters are definitely out for the data portal methods. One of the challenges with CSLA has always been the lack of compiler errors for the DP methods. For this reason I still follow the strongly-typed factory method approach in the same class so it's easier to eyeball the parameters and make sure they match.

[rockfordlhotka]

I agree about the lack of compile-time checking. At least in recent versions we've been able to beef up the runtime exception detail slightly - which became possible with the changes necessary to add parameter injection.

[michaelcsikos]

I'm revisiting this almost 30 months later as I'm restructuring a lot of our base classes. Being able to create a child with a regular IDataPortal without declaring a child factory class is certainly a lot less work. but having to create an overloaded method to call MarkAsChild() is a pain, and the CreateChild attribute essentially does nothing AFAIK.

With an IMarkAsChild interface and a new extension method to do IDataPortal<T>CreateChild(...) this becomes easier and less error-prone. I'm wondering if CreateChild should be added to IDataPortal as a built-in option?

public interface IMarkAsChild
{
    void MarkAsChild();
}

public static class IDataPortalExtensions
{
    public static T CreateChild<T>(this IDataPortal<T> portal, params object[] criteria)
    {
        var child = portal.Create(criteria);

        if (child is IMarkAsChild markAsChild)
            markAsChild.MarkAsChild();

        return child;
    }
}

// Our wrapper for BusinessBase:
[Serializable]
public abstract class BusinessBaseMgd<T>
    : BusinessBase<T>
    , IMarkAsChild
    where T : BusinessBaseMgd<T>
{
    void IMarkAsChild.MarkAsChild() => MarkAsChild();
}

Alternatively, has anyone come up with a better solution in the last couple of years?

[michaelcsikos]

@rockfordlhotka Can you provide some further context to your comment

The child data portal is not location neutral and must be running on the logical server within the context of the server-side data portal.

[michaelcsikos]

If there's no need to create the child on the logical server the following would be by far the simplest solution:

var dataPortal = ApplicationContext.GetRequiredService<IChildDataPortal<Child>>();

var item       = dataPortal.CreateChild();

Adding [RunLocal] to [ChildCreate] produces a warning: Child operations should not have [RunLocal]. But if this is essentially the same as doing a [Create] and then MarkAsChild() what's the problem?

[Chicagoan2016]

@michaelcsikos I have a lot of code similar to your original and without MarkAsChild()

 protected override object AddNewCore()
 {
     var item = Child.NewChild();

     Add(item);

     return item;
 }

Do we have to add MarkAsChild() in the newer Csla versions? It reminds me of Csla 1.XX 😊

[rockfordlhotka]

imo the best solution, if you need to create a new child on the logical server, is to use a command object. Typically created using ReadOnlyBase. Something like this:

public class ChildCreator : ReadOnlyBase<ChildCreator>
{
  // csla property
  public Child Child { get; set; }

  [Fetch]
  private async Task FetchAsync([Inject] IChildDataPortal<Child> childPortal)
  {
    Child = await childPortal.CreateAsync();
  }
}

On the logical client, when you need to create a new child, use the root data portal:

var newChild = await childCreatorPortal.FetchAsync();