ffernandolima / mongo-db-data-access Goto Github PK

I noticed that the current implementation of services.AddMongoDbContext wires up a singleton instance of a given MongoDbContext. This assumes that one would never have a connection with a different Mongo DB database (for the likes of multi-tenancy) for the duration of the application lifetime. Is there a reason why it cannot instantiate a new instance per scoped session? (I did notice that the AsyncLocal was causing some trouble when you're invoking it at the wrong stack level and so I was forced to add a workaround of adding a dummy command to the list of commands on creation so as to retain the same list of commands throughout my request).

I have noticed that the current pattern for applying configurations for Mongo Entities is done using the ApplyConfigurationsFromAssembly method inside the MongoDbContext constructor. Since its static and not reliant on an instance of a MongoDbContext, one can place that somewhere else (like a static constructor) to be initialized only once (if performance is an issue) especially since it uses the Mongo Bson Class Mapping API.

How would you feel about changing the MongoDb Infrastructure library to cater for this concern so that I can have an out of the box experience that can cater for scenarios where I may have to connect to different Mongo DB instances during an application lifetime?

Thanks