-
-
Notifications
You must be signed in to change notification settings - Fork 6
Require Dependency Injection #948
Comments
@rockfordlhotka , I am very interested in DI, I have been looking at Prism lately and it's using Dependency Injection (Unity --- I was pleasantly surprised :)). |
If I make this change it wouldn't actually force you to use DI, but it would force you to initialize the standard dotnet DI service on app startup. The idea with logging, for example, is that DI provides a standard way for any code to get at the configured logger. There's no prescriptive logger, just a standard way to get at the logger you've chosen. Everyone using aspnetcore already has access to these features, because DI is a required part of aspnetcore. I suspect that it will become a standard for everything else too, but in any case I want to make it a standard requirement for CSLA because it enables many of the same benefits enjoyed in aspnetcore. |
This sounds like a great plan. We tried a project with pure DI and it is very hard to maintain (had to hire a contractor to fix it) but a service in DI, like this, that make a lot of sense. |
This sounds great on any .NET Core application. But will CSLA6 still support .NET framework 4.x ? or only .NET Core 3.x / .NET 5? |
CSLA 6 will support dotnet framework 4.8, not older. Dotnet 4.7.2 works with the standard DI framework from Microsoft today, so I don’t think this is a blocker. |
This should be the way to go. |
This discussion can continue in the new forum |
For CSLA 6 I am considering requiring that some dependency injection service be enabled/configured in all apps.
Microsoft has included (and used) dependency injection in ASP.NET Core and will continue in .NET 5.
Microsoft has enabled the use of dependency injection for Windows Forms, WPF, console apps, etc. Their templates don't set it up, but it isn't hard to do.
The reason I'm considering requiring it for CSLA 6 is that if I know that I can rely on there being a service provider it becomes much easier (and sometimes just plain possible) to implement some things throughout CSLA.
For example, it would be ideal if you could inject the current logging component into the data portal so you could log events. Today that's possible, but not as easy as in ASP.NET Core, because I don't know for sure that there's a service provider.
There are all sorts of other scenarios where CSLA could do nice/helpful things if only we knew for sure that a service provider was available.
The only negative/breaking impact here, is that any Windows Forms, WPF, console, or other not-ASP.NET style apps would need to add a few lines of code into
Program.cs
or the startup equivalent file. So I don't think the burden is high, and the potential gains are very high.Thoughts?
The text was updated successfully, but these errors were encountered: