0

I am coding an MVC5 C# Internet application and I have a class called MapCompany and a class classed MapLocation.

Each MapCompany has a list of MapCompany's. My question is, for the context class, should I just have a DbSet<MapCompany>, and add MapLocations to the specific MapCompany, or should I have both a DbSet<MapCompany> and a DbSet<MapLocation>?

EDIT

Here is a bit of information about the application:

  1. Each MapCompany can have many MapLocations ~5-25
  2. I wish to be able to access any MapLocation by its id

Because I wish to be able to access each MapLocation by its id, will there be a lot of database searching if there is only a DbSet<MapCompany>, as I would have to search through each MapCompany to find a MapLocation by its id?

Would it be more economical to have a DbSet of each because of the increase in database searching? Also, will this make the database a lot larger?

Either way, each MapCompany needs to have many MapLocations, and I need to be able to retrieve any object by its own id efficiently.

With this above information, I am interested in whether I should code a DbSet for each object.

Simon
  • 7,991
  • 21
  • 83
  • 163

3 Answers3

0

I would recommend you use the Repository Pattern for your data layer.

http://msdn.microsoft.com/en-us/library/ff649690.aspx

I would also make a relationship between your two models IF you are not expecting a large amount of Map Location records for each MapCompany. Otherwise it might be more optimal to return a list of id's instead of models.

Its hard to say without knowing anything about your application.

jennas
  • 2,444
  • 2
  • 25
  • 31
  • Great, yes use two db sets as well as a foreign key relationship. Having two dbsets will not make your database any larger.. Entities would have done this any way. – jennas Jul 19 '14 at 22:22
0

As suggested, you need to use Repository Pattern... Try to check this example on Repository Pattern:

http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

andrew0007
  • 1,265
  • 4
  • 18
  • 32
0

If you have foreign key relationship between those entities.

public class MapCompany
{
    public int Id { get; set; }
    public ICollection<MapLocation> MapLocations { get; set; } // foreign key
}
public class MapLocation
{
    public int Id { get; set; }
    public int MapCompanyId { get; set; } // foreign key
    public MapCompany MapCompany { get; set; } // foreign key
}

It's okay to only have DbSet<MyCompany>, the MapLocation will still be generated on the database because of the foreign key relationship.

If you want to also have DbSet<MapLocation>, it's also okay.

If you don't have DbSet<MapLocation>, but want to access it directly without retrieving MyCompany entity first, you can do this.

using (var context = new MyDbContext())
{
    var mapLocation = context.Set<MapLocation>().Find(1);
}
Yuliam Chandra
  • 14,494
  • 12
  • 52
  • 67
  • Yuliam, can you explain what happens with the above MyDbContext code? – Simon Jul 20 '14 at 13:29
  • @user3736648, like I explained in the answer, you can put all your DbSet in the DbContext to make sure all entities are generated to database, but if you want to make your DbContext looks slim, you can take out all children entities (like MapLocation). If you do that, you can still access MapLocation, by using context.Set() instead of context.MapLocations, same result – Yuliam Chandra Jul 20 '14 at 14:04