6.0 DI Questions

[saulyt]

I am working on upgrading a project to 6.0 and have a few question as to the appropriate way to gain access to the DataPortal and ApplicationContext when using them in the business library itself.

• Using them in Create/Fetch/Update etc. seems to be doable via the [Inject] parameter. How would I use in other methods that are not invoked via the DataPortal? Can I Inject them in Create as I would do if I was using constructor injection and expect them to survive serialization to the server?
• I have a Lazyloaded child property that uses the DataPortal to load the child. How can I get the DataPortal for use in the property? (If the answer to my first question is to inject in Create this will be answered.)
• Ho do I gain access to ApplicationContext inside and AuthorizationRule? Does the Execute method allow parameters to be injected?

Thank you.

[rockfordlhotka]

Using them in Create/Fetch/Update etc. seems to be doable via the [Inject] parameter. How would I use in other methods that are not invoked via the DataPortal? Can I Inject them in Create as I would do if I was using constructor injection and expect them to survive serialization to the server?

The Inject attribute is specific to the data portal, and so it only works for parameters in server-side data portal operation methods like create/fetch/etc.

If you want to inject services for use in methods not invoked directly by the data portal, you should probably use constructor injection like "normal". Make sure the object containing your methods is created via DI, and then you can get the necessary services from the constructor.

That's a general answer, but if you have a specific scenario I can probably provide more details.

I have a Lazyloaded child property that uses the DataPortal to load the child. How can I get the DataPortal for use in the property? (If the answer to my first question is to inject in Create this will be answered.)

This is a good question, and I appreciate you bringing it up. I haven't thought through this scenario, and it needs a good answer.

Every domain object does have access to ApplicationContext, but I think it is private, so end-user code does not have access. Maybe it should be protected, so end-user code does have access. Or perhaps the base classes should expose a GetDataPortal<T> method so it is easy to get a data portal instance for lazy loading. Hmm.

Ho do I gain access to ApplicationContext inside and AuthorizationRule? Does the Execute method allow parameters to be injected?

In a business rule the context includes a reference to a User property. That should be true in an authorization rule as well, though maybe I forgot to do that? It does occur to me that a rule might need access to local/client context as well.

[saulyt]

@rockfordlhotka Thanks for the reply.

Is it now possible to use constructor injection on a CSLA business object? When I tried, I started getting errors stating that a CSLA business object must have a constructor with no arguments. I have methods in my business classes themseleves that use the DataPortal operations and I need to figure out how to get access to them in there.

I am still not clear on using Create to inject my data portals. If I inject them in a Create that is running local, and save them as private field variables, would they still be around after calling a server side operation such as Update or would they get lost due to the serialization?

I'll need to check out the reference to the User property in the auth rule.

Thank you.

[rockfordlhotka]

It is not possible to use ctor injection in a CSLA domain class, no.

There are two places you should need to interact with the client-side data portal.

First is in your client-side code (often a controller, viewmodel, etc.) where you need to create/fetch a root domain object. In this case, you would normally inject the IDataPortal<T> into your controller/viewmodel/etc.

Second is in your server-side data portal operation methods, where you have a root object that needs to create/fetch a child object. In this case, you would inject the IChildDataPortal<T> into the data portal operation method using the Inject attribute on a parameter.

What other scenario do you have where you need access to the client-side data portal?

[rockfordlhotka]

I'll need to check out the reference to the User property in the auth rule.

@TheCakeMonster just submitted (and I accepted) a PR that fixes a bug with the User property in the context object. So the current code in main (and the next prerelease) will have that fix.

[saulyt]

What other scenario do you have where you need access to the client-side data portal?

I have some methods where I do processing using one or more root objects. I would put that operation at the application level but sometimes I want to be able to run the same operation from multiple applications. For example, I am currently working on a project where I use such a method to process data from both an Azure Function and as well as an end user application. If there is no other way, I guess I will need to create more business/command objects for these methods.

Thank you.

[saulyt]

Every domain object does have access to ApplicationContext, but I think it is private, so end-user code does not have access. Maybe it should be protected, so end-user code does have access. Or perhaps the base classes should expose a GetDataPortal<T> method so it is easy to get a data portal instance for lazy loading. Hmm.

I love both these ideas. Having access to the ApplicationContext will make upgrading much simpler as you wouldn't need to make nearly as many modifications to the calling application. A base class GetPortal would not only solve the lazy loading. It would also solve my other issue of using the DataPortal in non Create/Fetch/Update methods where they can't be injected. That would also make upgrading so much easier.

Thank you.