Well, there's Set<T>
you can use to generically access a DbSet
, i.e. instead of _context.Company
, you can use _context.Set<Company>()
. However, where things get sticky is in allowing this to be specified dynamically.
Regardless of how you handle it, you're going to somehow have to "convert" a string into some entity type. For example, even if you use the actual class name as the option values in your select list. You're going to get "Company"
back, not Company
, the class. You could use reflection to try to find the actual type via the string, but that's not going to be be trivial, especially if these classes could be in different namespaces, or if the class name is ever repeated (i.e. the same class name exists in multiple namespaces). Even then, you'd also have to use reflection to access the set generically, which is also kind of a pain.
Long and short, unless there's a true need for this to be truly dynamic, or you're dealing some number of tables where it would be infeasible to not handle it dynamically, then you should just switch on the value and handle it somewhat statically. For example, if all you have is Company
and Department
, then it would be more clear, faster, and less error-prone to just check what the user selected and manually call the right DbSet.