Passing generic DBset entities to DbContext

Question

Here is my dbcontext

public partial class MyDbContext : DbContext
{
    //dbset 1
    public DbSet<Customer> Customers { get; set; }

    //dbset 2
    public DbSet<Order> Orders { get; set; }
}

I want to pass my models i mean Customer and order outside MyDbContext .something like this :

public partial class MyDbContext<T> : DbContext
{

    public DbSet<T> <T>{ get; set; }

}

And a function to get the list of entities to add to my context like this

addEntityToDbContext(Customer)
addEntityToDbContext(Orders)

Is it possible?

I am using EF Core .

@TanvirArjel because i use microservices in my project and each of them has its own database,and i want to create a public EF for each of them — Ehsan Akbar, May 28 '19 at 09:44
DbSet is a generic class already. What you ask is the DbContext class itself. Microservices have nothing to do with what you ask, nor do multiple databases. You can change the connection string of a context at runtime. — Panagiotis Kanavos, May 28 '19 at 09:48
@PanagiotisKanavos but each of microservices has its model and database . — Ehsan Akbar, May 28 '19 at 09:49
here is my question :https://stackoverflow.com/questions/56273847/persistance-datalayer-in-ef-core-dynamic-ef-separate-ef-from-models — Ehsan Akbar, May 28 '19 at 09:49
So use different contexts and different connection strings. Load the connection strings at runtime. That's what DbContext already supports. There's nothing "dynamic" about this. — Panagiotis Kanavos, May 28 '19 at 09:49
@EhsanAkbar a DbContext is a Unit of Work, not a model of the entire database. Even a simple web application can have different contexts for different modules/functionality. In fact, in a moderately complex application the same business entity may have to be represented using different classes. The `User` in a forum's post isn't the same as the `User` in the same forum's authentication system — Panagiotis Kanavos, May 28 '19 at 09:52
@EhsanAkbar and speaking of services (micro is just branding), [your data model is not your object model is not your resource model is not your message model](https://codeopinion.com/web-api-resource-model-isnt-data-model/). — Panagiotis Kanavos, May 28 '19 at 09:56
Don't try to be generic everywhere on any cost. It not worth it, especially in microservices. — Fabio, May 28 '19 at 09:57
@Fabio you know i am following the D-Shop pattern.https://github.com/devmentors/DNC-DShop,In this project the mongodb is separated from all microservices and each microservices send its classes to mongoextenstion to create the database — Ehsan Akbar, May 28 '19 at 10:00

score 1 · Accepted Answer · answered May 28 '19 at 09:43

1

I'm not sure what your question is? But DbContext has a generic DbSet method already built in?

    public virtual DbSet<TEntity> Set<TEntity>() where TEntity : class => 
(DbSet<TEntity>)((IDbSetCache)this).GetOrAddSet(DbContextDependencies.SetSource, typeof(TEntity));

answered May 28 '19 at 09:43

Robert Perry

1,906
1
14
14

Thank you.could you please give me a sample – Ehsan Akbar May 28 '19 at 09:46
Can you add some clarity to the question then please? Its not entirely clear what you're actually asking for – Robert Perry May 28 '19 at 09:47
https://stackoverflow.com/questions/56273847/persistance-datalayer-in-ef-core-dynamic-ef-separate-ef-from-models – Ehsan Akbar May 28 '19 at 09:49
@EhsanAkbar that question doesn't clarify anything. The *answer* explains that the question confuses different concepts – Panagiotis Kanavos May 28 '19 at 09:51
in fact i want to work with my context like a nuget and i pass my entities and my connection string to create my database . – Ehsan Akbar May 28 '19 at 09:51
Sorry @EhsanAkbar, it appears that I'm not making myself clear. Your question isnt detailed enough. You need to change the question so that we can answer it. What specifically are you asking? – Robert Perry May 28 '19 at 09:52
@EhsanAkbar the context has no similarity to NuGet. It's a Unit of Work. It's not a "Repository" either. A DbSet is a *higher-level* concept than a simple Repository. The connection string can be changed at runtime. I suspect you are confused by using the wrong terms, or perhaps by following a "tutorial" that uses trendy words instead of actually explaining anything? A "microservice" can be implemented as a single Web API controller with a single context. Its connection string can easily change at runtime - just pass a different one to its constructor! – Panagiotis Kanavos May 28 '19 at 09:57
@PanagiotisKanavos did you see th Dshop sample ? – Ehsan Akbar May 28 '19 at 10:51
@PanagiotisKanavos in d shop the database is mongo but each domain and microservice sends its entities and connection to the mongoRepository to generate the database – Ehsan Akbar May 28 '19 at 10:53
1

@EhsanAkbar that's a built-in feature of EF Core. It doesn't need any special treatment. I'd **strongly** advise you to take care when following "courses" from companies that can't even be bothered to use a valid SSL certificate. That site is full of buzzwords and the "repository" classes are the same generic repository **antipattern* that plagues beginners – Panagiotis Kanavos May 28 '19 at 11:02
I think this question is more about confusion and misunderstanding than an actual coding problem.. – Robert Perry May 28 '19 at 11:04
@EhsanAkbar there's no need for "distributed .NET Core". .NET was used to create distributed, service-based applications from day 1, back in 2002. – Panagiotis Kanavos May 28 '19 at 11:04
2

@EhsanAkbar I'd also *strongly* suggest following the courses of a reputable training company like Pluralsights or Wintellect. Pluralsight course authors are some of the best known authors and bloggers in the .NET world. You can get 3 months free access to all of their courses through Microsoft's also free Visual Studio Dev Essentials program – Panagiotis Kanavos May 28 '19 at 11:06

Passing generic DBset entities to DbContext

1 Answers1