16

I am looking for any ORM for Cosmos DB. Most of the client which have been mentioned in samples create a new connection to table when they need i.e. there is no connection pooling policy. It seems creating new connection always as is given in samples is non scalable. Please correct me if I am wrong. And does anyone have any good ORM solution which comes with connection pooling

Akshat
  • 615
  • 7
  • 18
  • 1
    I understand the reason for wanting to close this question and do agree, but these types of questions have historically helped me in the past.. what is the correct forum then for these questions? – Mark Redman Jul 11 '18 at 12:12
  • It helped you, me and many others. Hey! That's how I got here. Why would someone want to "clean"? "Oh the community bla bla" non-sense. It's because they want to feel important. That's all. Unfortunately, this keeps happening. Anyway +1 for an excellent question. – Fabio Milheiro Aug 24 '18 at 21:03

3 Answers3

11

Cosmonaut is exactly what you're looking for.

It is a simple and minimalistic object mapper, which creates a collection-to-object relationship. You can use your POCO objects and do all the CRUD operations.

The idea is pretty simple. You can have one CosmosStore per entity (POCO/dtos etc). This entity will be used to create a collection or use part of a one in Cosmos DB and it will offer all the data access for this object. It is optimized for performance out of the box and takes a lot of efficient decisions for you.

It supports collection sharing in order to reduce the cost of having multiple objects in one collection as well.

Read more about Cosmonaut here.

Disclaimer, I am the creator of Cosmonaut.

Nick Chapsas
  • 6,872
  • 1
  • 20
  • 29
  • 1
    Great to know that you're the creator of Cosmonaut! BTW i did not notice your answer when i posted – Sajeetharan Jul 01 '18 at 17:39
  • 1
    @Sajeetharan No worries. I just think that Cosmonaut is exactly what he is looking for, as it is actually inspired by EF heavily. – Nick Chapsas Jul 01 '18 at 17:41
  • downvoter for both answers and question reason please – Sajeetharan Jul 01 '18 at 17:49
  • Hi Nick, From my understanding it seems even in this case I have to share the same collection name in-case I have to pool connections, Otherwise I have to create different store corresponding to each DB. Please correct me if I am wrong – Akshat Jul 02 '18 at 00:49
  • @Akshat There is no need for you to create any connection pooling. Internally the SDK is actually pooling connections for you, so all you need to do is to have as many CosmosStores as you want, registered as singletons (which is how Cosmonaut does it) and the rest is taken care of on the lower level. – Nick Chapsas Jul 02 '18 at 08:44
  • It's a nice ORM for that matter. However, I am still trying to figure out how I can leverage the pros of UnitOfWork like in EF & EF Core. a **saveChanges** method to persist changes. Also from what I have gathered from the docs is that every entity should/will have its own **CosmosStore**. Would it not be ideal to have the CosmosStore representing the entire database container...so one could do something like **cosmosStore.blogs** and with the same instance be able to do **cosmosStore.authors** – rey_coder Aug 08 '19 at 08:10
  • @rey_coder What are the pros of exposing your whole unit of work when you don't need it? In EF Core your DbContexts should be segregated by responsibility so you end up in the same solution anyway. Also the SaveChanges method in Cosmos is pointless since Cosmos does not support transactions. The CosmosStore represents a container or part of that container. Ideally you would only have a single container (unless you have a scale reason not to) and many CosmosStores to manipulate the data in the container based on their type. This is the abstraction that Cosmonaut gives you. – Nick Chapsas Aug 08 '19 at 08:22
  • Thank you for the clarification @Nick. I am new to Cosmos and coming from an EF Core background. I am still digging through the docs. I believe there is a better way to add my configure CosmosStore DI (_dependancy injection_) so I don't fill my **ConfigureServices** with AddCosmosStore for every model I have. – rey_coder Aug 08 '19 at 08:37
  • Happy to see any suggestions to improve the DI code. Feel free to create a PR at the repo if you come up with something. Also it is highly recommended to follow [this recommendation](https://github.com/Elfocrash/Cosmonaut#optimizing-for-performance) if you have many CosmosStores to optimize performance. – Nick Chapsas Aug 08 '19 at 08:43
  • 1
    Cosmonaut is obsolete. They recommend you to use Microsoft's official documentation. – Pepito Fernandez Jul 22 '20 at 22:06
7

Cosmos DB now supports Entity Framework (announcement) (although at this point at the preview state); but works quite nicely.

p.s. nice 3rd party guide with more details on how to set things up:

However, you should really think whether you need EF (ORM). It is probably useful if you are switching you db to CosmosDB; and don't want to change your EF code right away; note though that in any case switching dbs requires work on EF-front; even more so if switching db types: relational to NoSQL.

EF does ORM (object to db mapping); however NoSQL already has object mapping so EF is not really needed (actually unnecessarily complicates things.

There is a nice write up from Microsoft on the related topics: https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/nosql-database-persistence-infrastructure

Neil
  • 7,482
  • 6
  • 50
  • 56
1

There is no recommended ORM framework available for CosmosDB, there are few ORM libraries out there which you could try,

(i) Cosmonaut

(ii) CosmicGraph

Update:

ORMs are there in general to solve the problem of mapping objects to relational databases. Document database like CosmosDB, you can store plain objects as JSON and not have to worry about the constraints of a relational database.

However, CosmosDB team provided support to it, The provider works like any other EF Core provider. You reference its package in your project and then specify it in OnConfiguring or if you’re using ASP.NET Core when defining the DbContext in Startup.

The provider is named Microsoft.EntityFrameworkCore.Cosmos.You can add it with the command,

dotnet add package Microsoft.EntityFrameworkCore.Cosmos
Sajeetharan
  • 216,225
  • 63
  • 350
  • 396