ApplicationContext.GetRequiredService

[ajohnstone-ks]

So we can't do ctor injection with Csla BOs or BusinessRules, but I see that BO instances and the rule contexts provide access to ApplicationContext, which has GetRequiredService. Is this the way to inject services we need during rule execution and custom business logic methods?

[rockfordlhotka]

Yes, that's correct.

The problem with ctor injection is that the object graph gets serialized/deserialized into different contexts - usually client and server - and so that model would require that you implement and register all the same services in both contexts. You'd be forced to have a DAL service on the client, for example.

Also, you'd need to register all your domain types (business and rule classes) as DI services, which seems like an onerous process.

Finally, there's a perf cost to using DI, and it would have a noticeable impact on loading large lists or other large object graphs. And on any deserialization of those graphs.

Given all that, I chose to support a service locator pattern. Perhaps not ideal, but this avoids all the negatives of using ctor injection.

[ajohnstone-ks]

Your reasons make sense, and I think this is a fine alternative. As long as we have a supported way to inject stuff, that will allow us to get rid of our custom solution to do injection, so that's great and will work well for us. I mainly just wanted to make sure it wasn't just visible b/c of interfaces but something you should call manually (like the ObjectAuthorizationRules methods).

The problem with ctor injection is that the object graph gets serialized/deserialized into different contexts - usually client and server - and so that model would require that you implement and register all the same services in both contexts. You'd be forced to have a DAL service on the client, for example.

We actually have our business rules in a shared code project, and have a Client & Server assembly. We use compiler directives so that server side only code is excluded from the Client library (everything ends up being in the Server assembly). So that's how we've been able to avoid having DAL code in our client app. Its also good b/c as a SaaS company, if there's stuff we really don't want on the client, we can just implement a command object which runs the code we don't want on the client.

Just wanted to throw that out as another way to keep DAL code off of the client.

[kcabral817]

Thumbs up. Have a nice day. Kevin https://rb.gy/syiuf

…

________________________________ From: Rockford Lhotka ***@***.***> Sent: Friday, December 8, 2023 11:36 AM To: MarimerLLC/csla ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [MarimerLLC/csla] ApplicationContext.GetRequiredService (Discussion #3604) Yes, that's correct. The problem with ctor injection is that the object graph gets serialized/deserialized into different contexts - usually client and server - and so that model would require that you implement and register all the same services in both contexts. You'd be forced to have a DAL service on the client, for example. Also, you'd need to register all your domain types (business and rule classes) as DI services, which seems like an onerous process. Finally, there's a perf cost to using DI, and it would have a noticeable impact on loading large lists or other large object graphs. And on any deserialization of those graphs. Given all that, I chose to support a service locator pattern. Perhaps not ideal, but this avoids all the negatives of using ctor injection. — Reply to this email directly, view it on GitHub<#3604 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGJTVDQR3P6SYNOWZFRF3YLYIM6YFAVCNFSM6AAAAABAJQALG2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TQMBRGYZDG>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>