CSLA 6 and static properties with DataPortal??

[RocketLabsDev]

Hello,
When updating older CSLA to version 6 the access to DataPortal is gone.
Example of old Exists command:

using System;
using Csla;

namespace SalesOrderMgmtLibrary
{
    [Serializable]
    public class SalesOrderExistsCommand : CommandBase<SalesOrderExistsCommand>
    {
        public static readonly PropertyInfo<int> SalesOrderNumberProperty = RegisterProperty<int>(c => c.SalesOrderNumber);

        public int SalesOrderNumber
        {
            get { return ReadProperty(SalesOrderNumberProperty); }
            private set { LoadProperty(SalesOrderNumberProperty, value); }
        }

        public static readonly PropertyInfo<bool> SalesOrderExistsProperty = RegisterProperty<bool>(c => c.SalesOrderExists);

        public static async System.Threading.Tasks.Task<bool> ExistsAsync(int salesOrderNumber)
        {
            var cmd = await DataPortal.CreateAsync<SalesOrderExistsCommand>(salesOrderNumber);
            cmd = await DataPortal.ExecuteAsync(cmd);
            return cmd.SalesOrderExists;
        }
        public bool SalesOrderExists
        {
            get { return ReadProperty(SalesOrderExistsProperty); }
            private set { LoadProperty(SalesOrderExistsProperty, value); }
        }

        [Create]
        [RunLocal]
        private void Create(int salesOrderNumber)
        {
            SalesOrderNumber = salesOrderNumber;
        }

        [Execute]
        private void Execute([Inject] ISalesOrderDal dal)
        {
            SalesOrderExists = dal.Exists(SalesOrderNumber);
        }
    }
}

So the problematic rows here are:
var cmd = await DataPortal.CreateAsync<SalesOrderExistsCommand>(salesOrderNumber);
cmd = await DataPortal.ExecuteAsync(cmd);

Another problem is on business objects we have these:

        #region  Factory Methods 
        public static SalesOrder NewSalesOrder()
        {
            return DataPortal.Create<SalesOrder>();
        }

        public static async Task<SalesOrder> NewSalesOrderAsync()
        {
            return await DataPortal.CreateAsync<SalesOrder>();
        }

How should these be changed?
I have read that this should be handled with dependency injection.
What is the right way to go about this in an WPF application?
Where should the dataportal services be initialized and how?
Where should it be injected?
Are the static functions for creating business objects totally obsolete?

Is there any examples for CSLA 6, business objects, BusinessListBase and WPF?
Preferably with examples of initialization of the services.

[TheCakeMonster]

@RocketLabsDev Yes, you are right. The data portal is now instantiable and retrieved using dependency injection. This is the big change from CSLA 5 and earlier.

There is an up to date WPF sample in the Samples folder of the repo, at https://github.com/MarimerLLC/csla/tree/main/Samples/WpfExample

I haven't played with this sample myself as I don't work with WPF, but it should be fairly self-explanatory.

Beware that the ProjectTracker sample app is one of the only ones in the repo that has not been updated to CSLA 6 yet. ProjectTracker is quite a big sample app and nobody has found time to work all of the way through it yet.

Other people have had the same questions on their upgrade journey, so there are lots of discussions on the subjects you will encounter. I would recommend searching over this list of discussions for lots more help and information as you work through your upgrade.

[RocketLabsDev]

Ok, thank you, I'll have a look at the WPF example.
And i found some variations for the Command I can try out. https://github.com/MarimerLLC/csla/discussions/3098
I'll get back if (when) there are questions.

[RocketLabsDev]

I have a list with the old static GetSalesOrderRows.
Now when i cannot use the DataPortal directly should that function be changed to take in an IDataPortal and should the ViewModel get that dataportal?
Or should I skip the static function and use the dataportal directly in the ViewModel to fetch the list?

Original list object:

    [Serializable()]
    public class SalesOrderRowList : ReadOnlyListBase<SalesOrderRowList, SalesOrderRowInfo>
    {
        public void Remove(int rowRunNumber)
        {
            bool iro = IsReadOnly;
            IsReadOnly = false;
            try
            {
                var item = this.Where(r => r.RowRunNumber == rowRunNumber).FirstOrDefault();
                if (item is not null)
                    Remove(item);
            }
            finally
            {
                IsReadOnly = iro;
            }
        }

        public static SalesOrderRowList GetSalesOrderRows(int salesOrderNumber)
        {
            return DataPortal.Fetch<SalesOrderRowList>(salesOrderNumber);
        }

        [Create, RunLocal]
        private void Create() { }

        [Fetch]
        private void Fetch(int salesOrderNumber, [Inject] ISalesOrderRowDal dal, [Inject]IChildDataPortal<SalesOrderRowInfo> soRowPortal)
        {
            using (LoadListMode)
            {
                var data = dal.Fetch(salesOrderNumber).Select(d => soRowPortal.FetchChild(d));
                AddRange(data);
            }
        }
    }

new static function + Viewmodel example:

        public static SalesOrderRowList GetSalesOrderRows(int salesOrderNumber, IDataPortal<SalesOrderRowList> portal)
        {
            return portal.Fetch(salesOrderNumber);
        }


// ViewModel
            var dpSorList = _provider.GetService<Csla.IDataPortal<SalesOrderRowList>>();
            int orderNumber = 123;
            var theList = SalesOrderRowList.GetSalesOrderRows(orderNumber, dpSorList);

Alternatively without the static method:

            var dpSorList = _provider.GetService<Csla.IDataPortal<SalesOrderRowList>>();
            int orderNumber = 123;
            var theList = dpSorList.Fetch(orderNumber);

*Edit
and if you use the version without static method how do you know what parameters to give the fetch method when it only says params object[] criteria as parameter?

[rockfordlhotka]

I've discussed this in other threads, but there are three main solutions.

Use IDataPortal directly

As you note, you can inject an IDataPortal and use it directly in the viewmodel. I think this is a fine solution, but does not provide intellisense on parameters.

Create a factory class

You can create a factory class, and inject IDataPortal into the factory. The factory then implements methods that require parameters and provide them to the data portal. Similar to the static factory concept, but now the factory is an instance type that can be injected into the viewmodel.

This is probably the best solution overall.

Expose a global IDataPortal creator method

This only works in some app types, like WPF!!

In your App class, expose a static method that creates an IDataPortal, which you can then use in your existing static factory methods.

The upside to this is that you can continue to use your static factory methods. The downside is that this technique doesn't work in modern UI types like Blazor. I think this is a short-term solution for migration, but still leaves you with technical debt that'll need to be addressed at some point.

[RocketLabsDev]

Ok, sounds like the best approach would be the creation of factory class.
Got some info from here:
#2632 (reply in thread)
#2787

So for the factory this should probably suffice, or would it be better to have the ApplicationContext injected and from there get the data portal?

    public class SalesOrderRowListFactory
    {
        public IDataPortal<SalesOrderRowList> Portal { get; }
        public SalesOrderRowListFactory(IDataPortal<SalesOrderRowList> portal)
        {
            Portal = portal;
        }

        public SalesOrderRowList GetSalesOrderRows(int salesOrderNumber)
        {
            return Portal.Fetch(salesOrderNumber);
        }
    }

Then in App.xaml.cs i would register the factory with the Host:

  public partial class App : Application
  {
    private IHost Host { get; }

    public App()
    {
      Host = new HostBuilder()
        .ConfigureServices((hostContext, services) => services
          // register window and page types here
          .AddSingleton<MainWindow>()
          .AddTransient<SalesOrderRowListFactory>()

          // add other services
          .AddTransient<DataAccess.ISalesOrderRownDal, DataAccess.SalesOrderRowDal>()
          .AddCsla(options => options.AddXaml())
        ).Build();

      Host.UseCsla();
    }

    private void OnStartup(object sender, StartupEventArgs e)
    {
      var window = Host.Services.GetService<MainWindow>();
      window?.Show();
    }
  }

So far everything is good...
But then further down the line when I have a ViewModel and need to get the SalesOrderRowListFactory?
In the ViewModel:

var theFactory = ServiceProvider.GetService<SalesOrderRowListFactory>();
var soRows = theFactory.GetSalesOrderRows(_SalesorderNumber);

How do i find the ServiceProvider?

1. Should the Host be a public property in the App class, and i get it from there?
2. Should the ServiceProvider be a public property in the App class?
3. Should I create all the Views and/or ViewModels trough the ServiceProvider so I get the ServiceProvider injected?
4. Should I always bring the ServiceProvider along as a parameter?

[TheCakeMonster]

@RocketLabsDev There is no single answer/solution here, because WPF doesn't natively support DI, sadly.

Generally, my approach would be to use constructor injection as far as you possibly can. Have the service provider create something, such as MainWindow (within the OnStartup method in App.xaml.cs seems common) and then have everything else you need injected. In some places, where you need to create a new window, you will need the service provider; for everything else just request the types you need in the constructor.

Remember: the service provider itself can be provided via constructor injection. Use it that way where you have to, but minimise direct use of the service provider as much as you can. Some code that uses the service provider is necessary in WPF, but it is less easily maintainable/extensible than a constructor that you can add parameters to.

The exact code you will need depends slightly on what classes are responsible for creating what other class. Generally I like to have my UI code in the ViewModels, as that makes it all nice and testable. Therefore it is my preference to have my ViewModels take responsibility for creating other windows as part of the UI logic. Therefore each of my ViewModel classes would need the service provider injected into it to be able to fulfil that purpose - but ONLY that purpose. Rather than as you show, I would also have the CSLA factory injected into the ViewModel as a separate parameter of that same constructor, rather than writing code to create it from the service provider.

Your factory looks great. In your ViewModel you can do the same thing - have a constructor which requires both an IServiceProvider and a SalesOrderRowListFactory. Use the service provider as little as you possibly can - just for creating windows. The constructor of the window can accept the ViewModel, so that once the window is created from the service provider, the ViewModel and everything it requires is created automatically by the service provider.

In short, the fewer instances of manual creation you have, the more easily extensible your application. Do this sort of thing the fewest times you possibly can:

ServiceProvider.GetService<MyType>() // This is not optimal; we should do this as little as we can

Instead, maximise the amount you do this:

public MyType(MyDependency1 dependency1, MyDependency2 dependency2) // This is easy to maintain, we should do this as much as we can
{
	...
}

[TheCakeMonster]

@RocketLabsDev The other thing I would say about your example code is that you might get bored having to manually register all of the factory classes. Have a look at automating that, with one way being to use the DotNotStandard.DependencyInjection Nuget package (source code at https://github.com/DotNotStandard/DependencyInjection)

I wrote this because I was bored of my app failing to start because I had forgotten to add a new registration when adding a new type. A very simple bit of code can do that for you, for example:

// Register all of the factories from the current assembly
// This will register them with a lifetime of Transient
// This is a case-sensitive match unless we specify extra parameters
services.DiscoverTypes()
	.Where(t => t.Name.EndsWith("Factory"))
	.AsThemselves()
	.Register();

You can use this convention-over-configuration style for factories, ViewModels, windows/pages, repositories/DALs or whatever! This requires only one line of code per category of classes - and it is a line of code that never needs updating. For example, you might choose to have four lines of code - one for factories, one for ViewModels, one for windows/pages and one for repositories/DALs. I put each line in an extension method within the assembly in which the classes reside, and call that extension method from the startup class - in your case App.xaml.cs.

You can see an application that uses this mechanism at https://github.com/TheCakeMonster/Examples/tree/master/CSLA6/ProjectTracker/BlazorServer/V1

And here is the extension method for the business objects assembly, which contains all of the factories:
https://github.com/TheCakeMonster/Examples/blob/master/CSLA6/ProjectTracker/BlazorServer/V1/Objects/ServiceCollectionExtensions.cs

Scrutor is capable of doing something similar. However, I explain in my repo why I chose to write my own. In short, I wanted to make use of convention over configuration, and to minimise the potential risk by scanning only specific assemblies for specific things.

[RocketLabsDev]

Thank you @rockfordlhotka and @TheCakeMonster, looks like I'll get it working with these.