Minimal changes needed for new non-static DP and AppContext for CSLA 6

[swegele]

Let me see if I understand the implications of the answer for #2632 ... and to ask about what I think might be the most minimal changes to my business objects (and others like me) to get up to v6.

In that ticket, @rockfordlhotka said:

Static factory methods are no longer an option.
Your choices are to inject (or create) a DataPortal instance and use it, or put your static factory methods into a factory class (so they become instance methods of that class) and inject the DataPortal into that class.

He further explained that the whole thing stems from no longer being able to get a static reference to ApplicationContext which is required to get a DataPortal.

Question One - So is it correct that if I

1. get (via DI) a reference to ApplicationContext (within my UI I guess)
2. pass that into my root object's static Create/Fetch/Delete etc. methods
3. then "inside" my business object, I can create an instance of the DataPortal and proceed to call the DP like before
   (this would make it so that no one outside the business objects has to know anything about the DataPortal)

So this is what I had previously:

public static AgencyEdit NewAgency()
{
     var newObj = DataPortal.Create();
     newObj.BusinessRules.CheckRules();
     return newObj;
}

that could now become this:

public static AgencyEdit NewAgency(ApplicationContext appContext)
{
     var dp = new DataPortal<AgencyEdit>(appContext, ??);
     var newObj = dp.Create();
     newObj.BusinessRules.CheckRules();
     return newObj;
}

Notice the "??". I'm not sure what is that 2nd parameter on the DataPortal constructor: Csla.DataPortalClient.IDataPortalProxy
What is the IDataPortalProxy and how would I properly create/use it to get a DataPortal instance?

Finally, I do realize that if I can DI up an instance of ApplicationContext, then I could simply also get a proper DataPortal object...but for some reason that seems to make less sense to me. Maybe just my old twisted brain that will finally click eventually.

Thank you 1000 times for all your hard work on v6 Rocky. I just gotta get my mind wrapped around this big change.

[rockfordlhotka]

I have some example code in my blog post about the CSLA 6 prerelease.

Also, there is some discussion in that post's discussion area that includes (for WinForms/WPF apps) a way to expose a GetDataPortal method from the App object.

[swegele]

I can't help notice that you have this on ApplicationContext.

internal IServiceProvider CurrentServiceProvider
    {
      get => _serviceProvider;
      set => _serviceProvider = value;
    }

Maybe this would be related to #2658 as a helpful thing to expose as public. So if I were inside an actual instance of one of my business objects I could get a hold of:

1. ApplicationContext
2. GetDataPortal method
3. ApplicationContext.CurrentServiceProvider

public IServiceProvider CurrentServiceProvider
    {
      get => _serviceProvider;
      internal set => _serviceProvider = value;
    }

??

[rockfordlhotka]

Interesting. The ultimate decision-maker on why we implemented this massive change to adopt DI is because of the unique way server-side Blazor uses DI. It is the first UI framework that works the way it does, and so everything depends on correct use of DI in SSB. You can't really cheat like in WinForms or WPF.

SSB uses a DI scope (scoped provider) for isolation on a per-session basis. Because there's no way to get the current scoped provider from a static method (or any other code that is running outside of DI), you can't get access to any DI-based services. Interestingly enough, the current user is a DI-based service, and so you can't even find out who's logged into your app in a static method.

This is why ApplicationContext switched from a set of static methods to an instance: everything in ApplicationContext that is per-user or unique to a user or session used to be accessible via static methods, and now can only be accessed via DI.

Your best bet, imo, is to take your static factory methods and move them to a factory class, so they are instance methods of the factory class. Then you can inject the factory into your Blazor pages/components.

  public class CustomerEditFactory
  {
    public CustomerEditFactory(IDataPortal<CustomerEdit> portal)
    {
      Portal = portal;
    }

    private IDataPortal<CustomerEdit> Portal { get; set; }

    public async Task<CustomerEdit> GetCustomerEditAsync(int id)
    {
      return await Portal.FetchAsync(id);
    }
  }

[swegele]

I've been heavily researching SSB and you are right...it's unique and tough to get one's mind wrapped around (especially when trying to remember that your javascript is actually running on the server!) ... but it's seriously cool and I'm really looking forward to seeing how this cross over from web forms goes.

I like your CustomerEditFactory idea. It's definitely a more "native DI-ish" way to get what is needed. But I've always liked "less indirection/abstraction" so I'd go for less classes but that is just a preference. For example, thats why I've kept my DAL implementation inside my server side dataportal methods. One stop simple shop...but I know it's not the most testable and breaks single responsibility bla bla. I know.

Anyway, let's assume I use DI in the SSB component/page to get a DataPortal

Can you see how it would be helpful for me to be able to get from that one thing to the other things...if you exposed the property getters as public?
Example:
make the DataPortal.ApplicationContext getter public

and

make the ApplicationContext.ServiceProvider getter public

I know I can already use DI to get those various things individually/separately...but then I'd have to pass three things around instead of just one. Bottom line, it is still DI that is providing what is needed. Just kind of like using DI to get the big russian doll which already has all the littler dolls inside of it.

[rockfordlhotka]

Those properties aren't public because I don't want to be responsible for opening a path for people to abuse and misuse DI. That's just not a reputation that would be helpful to CSLA. Instead, I'm trying to retain as much backward compatibility I can, while still supporting established patterns for building apps in environments like SSB.

[swegele]

OK I'll assume I'm veering off the proper breadcrumb path and keep coming back to directly using DI to get the things I need one way or another. Appreciate the dialog and ideas. Will keep learning and playing.