Injecting dependencies after the object has returned from the server

[GreatBarrier86]

Hi. Question. Right now, like the documentation shows, we’re defining the [Inject] attribute on the DP methods like usual. However, these business objects are sent to the server for save, and when the object is returned, obviously my dependencies are null.

How am I supposed to “reinject” them on the returned object given that CSLA object constructors can’t have parameters?

[rockfordlhotka]

What dependencies are you hoping to access on the client?

[GreatBarrier86]

To name a few, the DataPortalFactory and some Azure utilities like a KeyVault encryption/decryption utility class. Plus any connection manager we want to create.

[rockfordlhotka]

SystemLog class that wrote to disk for whatever purpose

This might make some sense, though are you logging inside your business classes? Like in rule types? Generally the only thing running in a business class on the client are properties and business rules.

Now if your desire is, on the client, to put logging into the client-side data portal pipeline, that makes sense to me, and I've been thinking about creating a client-side interceptor model like we have on the server - specifically for logging purposes.

[rockfordlhotka]

connection manager class is also usable client-side

Now this I think I'm directly opposed to. The idea of logical client-side code interacting with a data store without using the data portal to get to logical server-side code is explicitly outside the architecture CSLA supports.

I understand the desire to have the data portal dynamically switch between local and remote modes based on whether the internet is available (for example), and you can do that with a custom data portal proxy that does exactly that. Having spent a lot of time in that space though, I personally feel like that's a poor architectural choice, and a better choice is to use the model used by outlook and every other email client out there: always use a client-side data file, and have a separate agent/process that syncs the client-side data file with the server-side data file if the internet is available.

[rockfordlhotka]

@GreatBarrier86 I assume you've read the CSLA 6 migration doc?

https://github.com/MarimerLLC/csla/blob/main/docs/Upgrading%20to%20CSLA%206.md

Most notably the section on the client-side data portal and ways to use it now.

https://github.com/MarimerLLC/csla/blob/main/docs/Upgrading%20to%20CSLA%206.md#using-the-client-side-dataportal

[GreatBarrier86]

Rocky, yes I have read it. In our scenario, we have to support both a WinForms app with a DataPortalServer and multiple asp.net sites so basically we have to adopt DI given the multi-user nature and not just use statics.

Regarding the services I’m referring to, I don’t dispute some of the designs are a little unique but we don’t have the luxury of going 100% appropriate DI. I recognize there may be superior ways in the long term, but right now, we’re trying to migrate to .NET 8 without upsetting the entire apple cart.

[rockfordlhotka]

Let me switch my mindset then. Rather than discussing how CSLA can be altered for a specific scenario, let's discuss how you can solve your scenario. A side-effect may be improvements to CSLA.

imo, the ideal scenario would be to use DI in your WinForms codebase, allowing DI to create instances of the forms and their dependencies to be pretty much identical to aspnetcore or Blazor. That works really well, but is probably unrealistic in the context of an existing codebase.

Given that, I suspect your best bet is to create some services that you can access in WinForms via the service locator pattern (based on a static App.ApplicationContext property, and can inject in your aspnetcore code. These services may be similar to a viewmodel, or may be more like a set of domain type factories.

These factory types/services would be created via DI (again, using ApplicationContext or injection) and would abstract the use of the data portal. Within each factory you can inject and use ILogger, IDataPortal, etc.

I'm just brainstorming here, so might be off base, but that's my first thought from an abstraction perspective.

[GreatBarrier86]

Also, on the DataPortalFactory, we're doing it at a base level where we don't have the ability to work with a generic as a parameter, so we're using the DataPortalFactory. While the initial call may be from the ViewModel, it may be very possible that a child list is fetched on-demand AFTER the BO has been returned from Save or even the original fetch. Does that make sense?

1. Client ViewModel calls DataPortalFactory.GetPortal().Fetch(myCrit)
2. Server fetches the object and injects the services in Fetch([Inject] Foo foo)
3. Server returns the object to the client
4. Client ViewModel receives the object.
5. Client needs to fetch a child list after user clicks Button1 to bind it to a DataGridView.

Given that we now need to do another fetch from within the BO, how would you expect us to do so without the dependency?

[rockfordlhotka]

You are using a lazy loading pattern to get the child on demand by using a command object to retrieve it? In that case, you'd use the ApplicationContext.GetRequiredService method to get the appropriate IDataPortal<T> for the command object.

[GreatBarrier86]

You are using a lazy loading pattern to get the child on demand by using a command object to retrieve it?.

I have a BusinessBase object that has a child BusinessBindingListBase registered child object. When the BO is bound to the WinForms UI, after Fetch/Save, our DataGridView is bound to the child list object. So i guess you're saying that since each BO/BO List has a reference to ApplicationContext, any necessary dependencies should be requested through ApplicationContext.GetRequiredService?

[GreatBarrier86]

imo, the ideal scenario would be to use DI in your WinForms codebase, allowing DI to create instances of the forms and their dependencies to be pretty much identical to aspnetcore or Blazor. That works really well, but is probably unrealistic in the context of an existing codebase.

I've already rewritten all my form constructors to match your WinForms project example. It was better to just bite the bullet and do it. That part is working fine because I'm then able to use the injected DataPortalFactory to do GetPortal from Form_Load to retrieve the BO. My issue is how to handle if the BO needs some of those injected dependencies AFTER it's been returned to the client.

Possibly there is a concept I'm misunderstanding but imagine the following:

[GreatBarrier86]

Most notably the section on the client-side data portal and ways to use it now.
https://github.com/MarimerLLC/csla/blob/main/docs/Upgrading%20to%20CSLA%206.md#using-the-client-side-dataportal

Here was my concern about this section. I'm fine following this for getting the IChildDataPortal specifically, but in a general sense, using a Service Locator is an anti-pattern: https://blog.ploeh.dk/2014/05/15/service-locator-violates-solid/#:~:text=The%20Service%20Locator%20anti-pattern%20violates%20the%20ISP%2C%20and%20thus,is%20that%20it%20violates%20encapsulation.

Given that, I was thinking that what should PROBABLY (?) happen is that upon return from the server, when you do the "if (IUsesApplicationContext)', since you're going through each object anyway, the dependencies should be reinjected then.

[rockfordlhotka]

Service locator is an anti-pattern, but it isn't clear to me that mobile objects can avoid it. The DI provider changes out from under BO objects, and any time that happens then all injected services become invalid.

So were we to do ctor or property injection on a BO type, we'd also have to figure out a way to "fix up" any service references you are holding any time the DI provider is swapped out.

This happens behind the ApplicationContext today, and so any time (in a method or property) you get a service via ApplicationContext, you are getting that service from the proper DI provider (and/or scope). And that's fine, because the reference to that service is per-method, and so we can be confident that the DI scope won't change out from under you as that method is running.

[rockfordlhotka]

Also, when lazy loading, you must not directly use an IChildDataPortal - you must use a command pattern so the fetch of the child object occurs on the logical server.

[GreatBarrier86]

So were we to do ctor or property injection on a BO type, we'd also have to figure out a way to "fix up" any service references you are holding any time the DI provider is swapped out.

So maybe that's where I'm a little lost. Why can we not do ctor injection? I'm not entirely sure why that's off the table.

Regardless though, I would think a method similar in signature to fetch/create might do what we would need here. This obviously couldn't be an override, but it gives you the idea. Something that's called automatically during deserialization or even during Initialize, allowing the dependencies to be set as soon as possible.
protected override void OnApplicationContextSet([Inject] IDataPortalFactory dataPortalFactory, [Inject] SystemLog loggingUtilities)

[GreatBarrier86]

So that means we just have to make the assumption that any dependency backing fields that were used by the server will simply happen to never be touched by the client? Basically, it's the responsibility of the developer to know that certain fields can't be used by the client?

[StefanOssendorf]

IMHO it's bad to even have services in fields. We used that and got a lot of errors. It's not cslas fault but our bad understanding of the client/server side stuff.

[rockfordlhotka]

So that means we just have to make the assumption that any dependency backing fields that were used by the server will simply happen to never be touched by the client? Basically, it's the responsibility of the developer to know that certain fields can't be used by the client?

Parameters injected into data portal operation methods should never be stored as class-level fields or properties. So this should not be a source of confusion.

[GreatBarrier86]

The issue we have is that our classes are extremely tightly coupled which is a massive no-no with Dependency Injection, making the entire conversion somewhat awkward and fudgy. Because of that, we have requirements that don't always make a ton of sense from a 3rd party.

Given that, I guess we're saying this:

1. Any dependencies needed server-side will be injected through the DP methods.
2. Any dependencies needed client-side will be accessed through ApplicationContext.GetRequiredService()

[StefanOssendorf]

Yes. I would say:

1. Prefer: Request dependencies injected in the DP method
2. Like you wrote
3. Requesting a dependency via application context is regardless of server/client always the last way to get something you need xD

[GreatBarrier86]

I think in principlel, it would be this. Basically use it if you already have it somehow and only get if it it's null.

[rockfordlhotka]

I think that should work. Usually at least. Maybe always.

The big thing is that you don't want to end up holding a reference to a service from a DI scope that's no longer valid. I don't think that should happen as the object graph flows through the data portal (local in particular), though there is a setting for LocalProxy that turns off cloning of the graph, and then I'm sure this would fail.

[GreatBarrier86]

We have not changed that parameter for the local proxy, so we should be fine. Thanks for the help everyone.