0

I have DbSets that correspond to tables in a database using Entity Framework (code-first). I have some data that doesn't need to be stored in the database, but it makes sense to access it via the DbContext instance as that is how the program has been created.

    public DbSet<z> name0 { get; set; }
    public DbSet<y> name1 { get; set; }
    public List<x> name2 { get; set; } = new List<x>()
    {
        new x()
        {...},
        new x()
        {...},
...

I want (in this example) to NOT create any table or reference to name2, but I want to refer to it via the DbContext.

(Yes I know DbContext implies it is stored in the database, I am using the class to store "data", so whether that's externally supplied or through the application itself)

Tom Naughton
  • 1
  • A `DbSet` always represents a database table or view. If you define a `DbSet` the table will be created. Maybe use something like this: https://stackoverflow.com/a/45485220/13574233 – baltermia Nov 10 '21 at 10:29
  • Currently I have `List<>`s defined which didn't seem to stop EF from producing tables; I just want to define a collection of objects without creating a table and return instances of an object directly from the app without pulling from a database to improve performance. – Tom Naughton Nov 10 '21 at 10:43
  • I would say that polluting your context with lists is a bad idea to start with, though I am surprised that EF converts them into tables. I suppose you could configure the entities to be ignored, so for a `List` you would do `builder.Entity().Ignore()` – DavidG Nov 10 '21 at 10:56
  • Thanks for the suggestion, I'm currently considering creating a wrapper as something like "AppData" So I can return either DbSets or Lists based on TEntity, something like that. Creating abstract implementations like this is still somewhat new to me but I imagine this is the correct way to go about this. – Tom Naughton Nov 10 '21 at 13:50

0 Answers0