CosmosCollectionAttribute breaks POCO benefits

[RobEyres]

We're trying to refactor our Cosmos entity models to allow them to be reused over numerous projects / applications. One of the big problems introduced was that the entities are now marked up with [CosmosCollection] but we don't want to drag in a dependency to Cosmonaut everywhere the entities are referenced (the consuming libraries have nothing to do with Cosmos or storage concerns).

Would it be possible to abstract the concepts of "entity to collection mapping" and also partition key mapping away by providing an interface. E.g. By having a ICosmosEntityToCollectionMapper type class, the consumer can get away without having to mark up entities with Cosmonaut attributes.

Perhaps the default ICosmosEntityToCollectionMapper could rely on Cosmonaut attributes and fall back on convention as is the current behaviour.

Anyway...please let me know what you think. I could always spike this concept in a branch if this would help?

[Elfocrash]

Hey Rob,

Those are all solid points. I would like to see a more detailed example of your proposal to potentially add it as an alternative to the existing solution with the attribute.

[RobEyres]

Ok...give me a little time to flesh out a POC. Will get back to you. Thanks

[roberino]

Hey...I created a POC on a fork...take a look at IEntityConfigurationProvider and related implementations.

I think something like this will allow the collection and partition configuration to be defined completely separately from entities while still supporting the default attribute based configuration of entities.

https://github.com/roberino/Cosmonaut/tree/feature/collection-mapping

[Elfocrash]

I really like this approach. Feel free to clean it up, write tests and create a PR. Make sure it's backwards compatible.

[roberino]

Done :) #97