IoC and Microservices
I ran into an interesting benefit when pursuing my rewrite of one of my smaller services as a separate microservice; while services may share some dependencies, they may not necessarily share the way that they need them.
Case in point. I'm migrating a background service which is responsible for backups. Some of these tasks run once a day or once a week. I don't need the ISessionFactory to be a Singleton and I don't even need the ISession to be scoped. While there is no real reason to mess with the Session Factory here, I definitely DO want my ISession's to be transient. There is only one call (a health check) passing through the ASP.Net Core pipeline and it is just a single minimal API call doing everything inline in the Program.cs (shoot me).
But, in the main application, DB calls cross a lot of barriers and the ISession NEEDS to be Scoped.
Why does it matter? Well, it doesn't matter... much. But it does matter.
Good programming dictates that we shouldn't be exposing things in a more permissive manner than is necessary, even if it seems pointless. In short, we have lowered the attack surface in the Backup Service for access to the ISession object. This is good.
A small good. But, it is illustrative and likely not a unique case.
Comments
Post a Comment