[CSHARP-3837] MongoDB Provider for Entity Framework Core Created: 07/Sep/21 Updated: 01/Nov/23 Resolved: 01/Nov/23 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Epic | Priority: | Unknown |
| Reporter: | Soham Dasgupta | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 22 |
| Labels: | size-xlarge | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Quarter: | FY24Q2, FY24Q3 | ||||||||
| Documentation Changes Summary: | 1. What would you like to communicate to the user about this feature?
2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to? |
||||||||
| Start date: | |||||||||
| Scope Cost Estimate: | 0 | ||||||||
| Cost to Date: | 0 | ||||||||
| Final Cost Estimate: | 0 | ||||||||
| Cost Threshold %: | 100 | ||||||||
| Description |
|
Currently, there are no MongoDB EFCore providers in the market that are maintained. There is a huge amount of code enterprises like mine have already written using EfCore and it would be great if there was a MongoDB provider which can just be used to replace the SQL Server provider. Appreciate the great work you guys are doing. Thanks!
https://docs.microsoft.com/en-us/ef/core/providers |
| Comments |
| Comment by Esha Bhargava [ 01/Nov/23 ] |
|
Closing this ticket since Entity Framework Core is now available in public preview. All the work is being tracked in the "Entity Framework" Jira project and external users can use it to file bugs. Details on what the team has accomplished so far can be found in our blog post and documentation. Limitations and our future roadmap and be found here. |
| Comment by Shay Rojansky [ 20/Dec/22 ] |
|
Shay here, from the Entity Framework team at Microsoft. > EntityFramework by contrast is quite focused on the relational model of data, and in fact all the providers are in the same scope, without any plans from Microsoft to provide support for non-structured models (don't be fooled by the support to Cosmos, that is only for the new-SQL API of the system). While it's true that the EF Cosmos provider uses SQL, that in no way means that that EF is bound to relational concepts or unsuitable for use with document databases. EF Core (unlike the older EF) was purposefully designed with non-relational databases in mind, keeping clear separations and splitting all relational-specific logic out to a different package. So I think EF would be a good fit for MongoDB - would be happy to discuss further. |
| Comment by Antonello Provenzano [ 20/Dec/22 ] |
|
As mentioned by James, there is a valid implementation in the domain, that is the project named MongoFramework ( here a presenation) and I personally use it for a couple of projects: it emulates the design of the EntityFramework and its repository pattern model, although it's completely outside of the EntityFramework scope and integration. Anyway, although if valid alternative for design, it lacks (as it's normal and understandable) the overall benefits provided natively by the framework, such as the temporal tables (historical replications of tables), or other functions of such. EntityFramework by contrast is quite focused on the relational model of data, and in fact all the providers are in the same scope, without any plans from Microsoft to provide support for non-structured models (don't be fooled by the support to Cosmos, that is only for the new-SQL API of the system). I think that implementing an adapter for the EntityFramework would benefit many, providing an access to the mentioned built-in functions by the framework, but for the moment I am happy with what provided by the MongoFramework implementation. |
| Comment by Jaroslav Zaoral [ 05/Nov/22 ] |
|
+1 |
| Comment by Sipke Schoorstra [ 25/Feb/22 ] |
|
Just wanted to describe my use case for a MongoDB provider for EF Core. I am the author of the Elsa Workflows library, which aims to be a modular workflow library where developers are able to create modules in the form of .NET projects to extend the workflow engine. An important aspect of this library is that it is database-provider agnostic, which means that it supports any persistence provider by exposing repository interfaces that providers then implement. The disadvantage of this approach is that it does not allow modules to introduce new database collections/tables without them having to bring their own persistence providers (one for each supported provider: MongoDB and SQL Server through EF Core). To solve for this, I would get rid of the repository interfaces and instead allow modules to share a DB Context that they can extend with their own DB sets. Although this would enable all kinds of relational DBs such as SQL Server and even NoSQL DBs such as Cosmos DB, it does not support MongoDB. Unless there would be a MongoDB provider for EF Core, which is what brought me to this ticket
An initial attempt was made here: https://github.com/BlueshiftSoftware/EntityFrameworkCore but the project appears to be abandoned (last commit was about 2 years ago).
So yeah, a big fat +1 from me and the Elsa Workflows community to this feature. |
| Comment by Soham Dasgupta [ 15/Sep/21 ] |
|
Hi @James Kovacs, I work at Deloitte. This is such an important feature at least to us, that we will start using it in production, if released. We already have a ton code aleady invested in EfCore and Sql Server, and some those data models were force fitted in SQL Server and perform poorly, which I know will shine in Mongo land. Of course there are times we wished that we could rewrite parts of our application to use Mongo but that never sees the light of day due to other commitments. Like us I'm sure, there are many teams out there who would jump at the first opportunity to just swap out EfCore SqlServer package with MongoDb package, and maybe do a few adjustments, but will immediately benefit without having to think about a rewrite. I know for sure we will. So +1 from our team to this feature. Conversely, I'm sure that the interest from community will definitely arrive if this is given some serious thoughts. Many may not realize this now, but will definitely benefit if it sees the light of day.
Thanks, Soham |
| Comment by James Kovacs [ 07/Sep/21 ] |
|
Hi, soham1.dasgupta@gmail.com, Thank you for reaching out to MongoDB with your suggestion. While we do not have an official EF Core Provider for MongoDB, there are third-party implementations such as MongoFramework, which are built on top of our official driver. While we do not have plans at the moment to release an official EF Core Provider for MongoDB, it is something we may consider in the future if there is sufficient interest. Sincerely, |