Injecting the SharedCollection Name

[reddy6ue]

I use multiple shared collections in my app. I want to make sure that I injection the collection name for groups of entities. How can I accomplish that with Cosmonaut?

Currently, the only way to use Shared Collection is through an attribute, which doesn't lend itself to injecting a collection name.

[Elfocrash]

I’m trying to understand this one.

You can use the SharedCosmosCollectionAttribute and set the collection name there. You can also override this collection name when you initialise or register your CosmosStore with the ‘overridenCollecrionName’ parameter in both the constructor and the dependency injection methods. This name overrides the attribute.

Let’s me know if that makes sense.

[reddy6ue]

I missed that constructor. My bad!

[kitsu]

I ran into this same problem, and was going through some weird code contortions to try to alter the attribute at run time. It would be nice if the readme mentioned this variation. I also think it would be helpful to split the DI and constructor usage into two sections.

Reading the intro I missed the reference to the plain constructor three times, and none of the samples use the plain constructor. In my use case I don't want to expose the data-layer implementation details to the app, and thus don't want to reference Cosmos anything in the app DI config.

Thanks for making this though, I think it will be very helpful and a definite upgrade from the Microsoft API.

[Elfocrash]

@kitsu Sorry that you had this issue. I will add it in the readme today.

I started moving some stuff to https://cosmonaut.readthedocs.io which will eventually be the way to go when it comes to documentation. I don't wanna have everything in the readme file.

Can you explain a little bit more on the DI thing. I didn't quite get what you mean.

[kitsu]

Cool, some more through docs would be great (especially for selling your lib to my dev team).

For dependency injection: I am wrapping data access in a separate project from my main web app. I don't want to expose any of the data access implementation to the app (which is where I am configuring DI), and I don't want any DI infrastructure exposed in the data layer either. My data layer classes are registered with DI, they internally instantiate Cosmonaut stores, but the app is decoupled from the data storage mechanism.

(App)--->(Data(Cosmonaut(Cosmos)))

[Elfocrash]

I see. That's why ServiceCollectionExtensions are in a separate Nuget package all together.

The way I get around this issue is I am using the Nuget package in the data layer and I have an extension method for my service container called .InstallDataServices() (not the actual name but you get the point) which will then register ICosmoStores instances in the background. That way my App layer know only about this one method and the data layer knows about what to register and in what way (IE CosmosStores should be singletons).

[kitsu]

That is actually a pretty nice design. Unfortunately my team is new to DI (and Core and Azure, etc.) so I want to keep it as basic as possible. We'll have to work up to data access layers with their own DI registration methods.

[Elfocrash]

I see. That's fine I guess. These are concepts that you can get into later anyway.

Also added the documentation for this issue: https://github.com/Elfocrash/Cosmonaut/blob/develop/README.md#specifying-a-different-collection-name

I hope it's clear now. If you find anything else that's not explained properly or it's missing feel free to open an issue.