ILogger injection

[sacrejohn]

Hello all,

Is it possible to inject dependencies into business objects such as the ILogger<MyBusinessObject> class ?

Thank you for your help.

[TheCakeMonster]

Yes, you can have anything from DI injected into a dataportal method.

Add a parameter of the type you want injected to your DataPortal method, prefixed with the [Inject] attribute.

[Fetch]
private void Fetch([Inject] ILogger<MyBusinessObject> logger)
{
    logger.LogDebug("Hello world!");
}

[sacrejohn]

Thank you very much !

Is it a good or bad idea to store dependencies ?

private ILogger<PersonEdit>? _logger;

[Create]
[RunLocal]
private void Create([Inject] ILogger<PersonEdit> logger) {
   this._logger = logger;
}

[Fetch]
private void Fetch([Inject] ILogger<PersonEdit> logger, int id) {
   this._logger = logger;
}

Another question I have. Supposing I have an Invoice object. Is it a good idea to inject a dependency to generate an invoice and use it in the SaveAsync method ?

private InvoicePdfGenerator? _invoicePdfGenerator;
private ILogger<PersonEdit>? _logger;

protected override async Task<PersonEdit> SaveAsync(bool forceUpdate, object userState, bool isSync) {
   var result = await base.SaveAsync(forceUpdate, userState, isSync);
   this._invoicePdfGenerator!.Generate(this.Id);
    return result;
}

[Create]
[RunLocal]
private void Create([Inject] ILogger<PersonEdit> logger, [Inject] InvoicePdfGenerator invoicePdfGenerator) {
   this._logger = logger;
   this._invoicePdfGenerator = invoicePdfGenerator;
}

[Fetch]
private void Fetch([Inject] ILogger<PersonEdit> logger, [Inject] InvoicePdfGenerator invoicePdfGenerator, int id) {
   this._logger = logger;
   this._invoicePdfGenerator = invoicePdfGenerator;
}

[sacrejohn]

Maybe I should create my own instanve activator to inject dependencies through the constructor?

I'm in the process of migrating from version 3.6 to the latest version.

In my example, the Logger was a static member, and I instantiated the InvoicePdfGenerator class. But I can't anymore, as this class also has dependencies and must therefore be created using dependency injection.

[theafricaninternetgroup]

For the first question there is no need to store dependencies.CSLA Objects have a property called ApplicationContext which you can use for example

private void MyMethod()
{
    var logger=ApplicationContext.GetRequiredService<ILogger<MyBusinessObject>>();
    logger.LogInformation("Hello,world");
 }

[sacrejohn]

Thanks, but isn't this breaking the principle of dependency injection, if it's the class that's requesting a service?

[TheCakeMonster]

You can store dependencies, but it might cause you problems because of the behaviour of the dataportal. CSLA will serialize the object in quite a few scenarios. As a result, the objects you store are probably going to have to implement IMobileObject in order to be compatible with the serialization. That might be a problem for you.

I agree that using ApplicationContext.GetRequiredService() is a little bit of an anti-pattern. This is the service locator design pattern, and it is generally recommended that you avoid this pattern, if you can. However, needs must, and if the dependency you are using won't play nicely with CSLA's serialization, then this is an option.

You can write wrappers for types that need to be serialized and which implement IMobileObject, but it will create more work for you.

[sacrejohn]

Thank you, I really appreciate your help.

I'm a bit confused. My business objects contain all the code needed to perform an operation (this includes, for example, triggering e-mails or sending messages (via dedicated classes). But it seems complicated to provide services to my objects.

So I feel I have to either :

• use the locator service
• add a layer above the business layer to manage behaviors requiring dependencies.

Using the service locator doesn't seem to go in the way of dependency injection.
Adding a layer above it seems to me to make Csla objects less interesting.

Is there a solution recommended by the community ?

[TheCakeMonster]

Generally my apps using CSLA had other layers. I tended to call one of the layers orchestration, and that sat between the outermost layer - the interface, whether that be a UI, an API or whatever - and the CSLA objects.

One thing you could do is inject not the service itself, but a factory that is designed to create the service when you need it. That would be an extremely simple class that returns an instance of a specific class, and implements the IMobileObject interface - but the implementation doesn't do anything.

I think it is worth asking yourself the question of whether you are trying to use CSLA for domain modelling. Rocky's recommendation of how to use CSLA is different from domain modelling, yet there is a slight subtlety to the distinction that is easy to miss as you use the framework. In the ProjectTracker sample app, there are several objects that interact with the same underlying tables. Generally, it is better to design an object to do a single job - for use in a single scenario, or a single screen. I get the sense that you want to expose a lot of different functionality through a few, large classes. I think that may be contrary to what CSLA is intended for.

One more thing that springs to mind, based upon what you said, is that I would tend to architect bigger systems to use messaging between sections of the application. Sending an email is something that I would have a separate background service doing, triggered by receipt of a message sent via a queue. However, it's very hard to know, or even decide when you do know, how big your system is, and thus whether that is applicable to apply that sort of architecture. Remember too that you can lose/impact the transactional nature of a system as you split it up in that way, and that can make things more error prone, unreliable, and hard to maintain, unless you do more work to allow for that.

[sacrejohn]

We've been using Csla for 15 years in version 3.6.

We've always been careful to create a dedicated object to perform a single behavior.

In rare cases, we have coupled the saving of an object with the triggering of other actions.

Example: An "Invoice" root object which, during the "save" process, requests PDF generation for the invoice. (The object doesn't actually generate the PDF, it simply calls the class in charge (or sends a message on an event bus, but to do this I need a communication class). Previously, we used to call a static method, but this will no longer be possible.

[rockfordlhotka]

Generally speaking, logically server-side behaviors (such as sending an email) should be implemented in data portal operation methods, and you can inject parameters into those methods.

Logging I see as a potentially different thing, since it seems reasonable to think about logging user interactions with the domain objects when they are running on the logical client. There's no good answer for this at the moment, because constructor injection isn't possible with mobile objects. Nor is property injection, though perhaps that's something to consider. Hmm.

Basically, CSLA controls the lifecycle of domain objects, because it may serialize them to/from the server, or to implement n-level undo, or for the Clone operation, etc. There are quite a number of scenarios where an object graph gets serialized and then deserialized into a different context - often on a different computer or runtime.

Deserialization means invoking the constructor of the domain types, and at least so far I have been unwilling to treat all domain types as "services" from a DI perspective. There are some interesting consequences of doing such a thing. We would

1. have to declare every domain type as a transient service on the client and server.
2. have to ensure that every service injected into a domain object is declared on the client and server - and deal with all the fun DI scoping issues that come with Blazor.
3. have to accept the non-trivial performance impact of using DI to create every domain object in every business object graph (vs using CreateInstance like today); I suspect this would be a real killer to the use of CSLA for a lot of scenarios involving lists of objects.

To avoid those negative consequences, I've chosen to implement method-level injection of parameters in the data portal operations, and leave any other (more rare) scenarios to relying on the service locator pattern via ApplicationContext.

[sacrejohn]

I understand better, thank you.

To sum up, if I need a client-side dependency, I have to use the service locator, and if I need a server-side dependency, I ask for the parameters in the methods called by the DataPortal.

Note: We previously did this in the save, so we could be sure that the transaction to save the data had been completed successfully.

If I add the code to the Insert and Update methods, the transaction won't be completed yet. So:

• either I manage the transaction myself

[Insert]        
private void Insert([Inject] InvoicePdfGenerator invoicePdfGenerator) {
    using (var t = new TransactionScope()) {
       // Save in database
       // ...
    }
    // PDF generation request
    this._invoicePdfGenerator!.Generate(this.Id);
}

• or I can make sure that my generation request can be cancelled if the transaction is aborted

[Insert]
[Transactional(TransactionalTypes.TransactionScope)]
private void Insert([Inject] InvoicePdfGenerator invoicePdfGenerator) {
  // Save in database
  // ...
  // PDF generation request
  this._invoicePdfGenerator!.Generate(this.Id);
}

This is outside the context of my question, but I'm asking why it's now necessary for the constructor to be public and no longer private. This breaks the encapsulation that was emphasized in previous versions.

[rockfordlhotka]

You can also use the OnDataPortalInvoke, OnDataPortalInvokeComplete and OnDataPortalException virtual methods to know generally when the data portal has been invoked, completed successfully, or failed due to an exception. This is all logically server-side, where it is an exception that terminates and rolls back the transaction.

Though looking at the implementation, parameter injection isn't supported, and you'd still have to use the service locator pattern in those methods.

On the upside, you could handle them in a custom base class, centralizing all that logging so it isn't scattered in every individual business class.

[Chicagoan2016]

For logging we have considered 'DataPortal_OnDataPortalInvoke' in the past.
It's something to look into, although we didn't end up using 'DataPortal_OnDataPortalInvoke' because it turned out we didn't need such 'granular' logging.

I am assuming if you don't send emails for logging then we have implemented an EmailSender class which is essentially a BusinessBase and the reason is, we have some business/validation rules and Command object wasn't adequate.
For invoice generator type use cases, we use a child object (inside e.g. PersonEdit).

[sacrejohn]

For invoice generator type use cases, we use a child object (inside e.g. PersonEdit).

Do you have an example? I'm having difficulty understanding how you put this into practice.