How do I use ConnectionManager in csla in a blazor program? How do I do dependency injection?

[knox007]

I am using csla.net 8.2.9, but I still want to use ADO.NET to connect to the database. I want to use ConnectionManager under Csla.Data to manage the database connection. How should I set it up and use it?

[rockfordlhotka]

The connection managers were removed in favor of using dependency injection with .NET 8.

If you want to use the old ConnectionManager, you'll need to take it from the previous version of CSLA and include it directly in your project.

I recommend using DI though, as this is the modern way to manage connections.

[knox007]

I have obtained ConnectionManager from the previous version, included it into my project, and implemented dependency injection. However, there is a problem that when ConnectionManager is disposed, ApplicationContext is always null. I don't know why?

[knox007]

I understand a little bit if ConnectionManager is not di enabled in CSLA.NET 8 or later?

[rockfordlhotka]

You'll probably need to change ConnectionManager to have the ApplicationContext injected.

[knox007]

I changed the ConnectionManager constructor to inject ApplicationContext into it, but it worked fine when I created the database connection. When I tried to release the database connection, ApplicationContext was null. Is there anything else that needs to be changed?

[knox007]

@rockfordlhotka

[StefanOssendorf]

How are you retrieving the connection manager instance?
And how is the connection manager registered in your di?

[knox007]

Thanks for your response,Previously, csla 3.8 was used,Now I want to upgrade to CSLA.NET8.2.9 or CSLA.NET9.0.0, and make blazor server program, is currently a variety of difficulties, due to historical reasons a lot of business logic is still using sql server stored procedures

[Chicagoan2016]

This discussion #3287 might help.

[Chicagoan2016]

Also #2979

[knox007]

In discussion #3287, someone used TransactonScope, he used the latest csla, he encountered exceptions related to distributed transaction and database connection pool errors, he used the solution discussed in #3287

[knox007]

I did a test today, TransactionScope really can work normally, your judgment is correct, thank you very much for your guidance @Chicagoan2016

[Chicagoan2016]

@knox007 glad to help

[knox007]

When using TransactionScope, the database connection pool problem is easy to occur, indicating that the connection cannot be obtained in the connection pool, the cause of this should be that the connection is not closed immediately after the use of the connection, I added the connection release logic in the Maindb class, the connection pool problem does not appear at present, the transaction is normal,Moreover, the speed of inserting data into the database is actually faster.

At the same time, I also use rock's scheme, which has an obvious problem. In the parent-child object, if an exception occurs when the child object inserts data into the database, the transaction in the child object can be rolled back without affecting the parent object, and the data of the parent object can still enter the database.
These are my conclusions @Chicagoan2016

[rockfordlhotka]

@knox007 I think you are starting to see why we dropped the whole connection manager concept from CSLA. It was a way of solving a problem that no longer exists when using dependency injection, and the DI solution is much cleaner and easier to understand.

The data portal creates a DI scope for each root data portal call - which means that there's a DI scope that only exists during the processing of a single data portal server call, and includes the root and all children in the object graph.

When using the Transactional attribute, all data operations within that data portal call are in the same transaction.

When using DI to get a scoped database connection object (which is normally how it is done), the database connection exists for the lifetime of the DI scope, and therefore is automatically injected into the root and all child object data portal operation methods. You automatically get reuse of that single connection, and the connection is automatically disposed when the data portal call completes, because the DI scope containing the connection is automatically disposed by .NET.