Closed coderdnewbie closed 3 years ago
Of course, maybe in the near future? It is good also if there are use-cases the community can lists so we can start from that.
Well the bulk operations that EF Core does not support is why I asked the question. At work they need the bulk insert feature, but are locked in to using ef core. We should be able to convince to use the integration package and so use repodb for things that EF Core does not do. Another developer is trying the linq2db.entityframeworkcore package, so I wondered if you are doing anything similar as repodb seems to be quite good.
Work is saying that the ROI (return on investment, I think it means) is too big to switch away from ef core, so changing to dapper, repodb or linq2db was rejected.
@coderdnewbie - what's the reason why not just use RepoDB on top of EF? You can always use both ORM in a single solution. You can use RepoDB in some advance cases like Batch and Bulk Operations (as you mentioned).
I had tagged wrongly the fixes to the other issue here. Apology for that. 😄
We are trying different things for the bulk insert, like the bulk extensions package, and even trying ADO.Net directly. Making the decision is difficult and the manager is against having more than one orm in the system, in case developers in the future use the repodb when they should have used EFCore.
The idea of using the integration package is that this makes things more obvious to developers in the future about why we have more than one orm.
It seems to me you guys are locked up to EF Core. Think of the fact that, even if I deliver the integration package, it will still reference both library (EF and RepoDB), so that is not an argument IMO.
Of course, I will not insist the usage of RepoDb.SqlServer.BulkOperations if you guys can do the same job by writing it through ADO.Net. However, it is very unfortunate, you will be missing lot of cool stuffs on that specific package (i.e: Return Identity, Data Table, DbDataReader, etc).
Using ADO.net will be too hard to maintain in the future, that is why the manager is against that. Will leave it with the developer trying the linq2db version. Basically we want a simple implementation so that any developer will be able use with minimal work. My manager is very obsessed about it being maintainable as this is going to be used for the next 10 years plus, so he does not want it to depend on a single developers knowledge.
So something like this is ideal
public void BulkInsert(IList
this.BulkInsert<EmployeeSimple>(employees);
}
This is the reason I asked the question, we use repodb for this and EF Core for everything else, as an example.
I think, I cannot comment any further. But, if ever you guys are considering RepoDB, all you have to do is just below.
Install-Package RepoDb.SqlServer.BulkOperations
Then call the bootstrapper.
RepoDb.SqlServerBootstrap.Initialize();
And you can use the Bulk Insert anytime.
connection.BulkInsert<Employees>(employees);
You referenced single package only, same goes as Linq2DB.
But, any ORM you use for as long it solves your problem, then that is okay. Linq2DB is quite a cool one 😉
Ok thanks, I will let the developer trying linq2db know. He can evaluate which he thinks is better. I will close the issue.
We like trying different options, that is why we love the choices 😜
Linq2db can integrate with EFCore . see https://github.com/linq2db/linq2db.EntityFrameworkCore
Have you considered something similar for repodb ?