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:
Each MapCompany can have many MapLocations ~5-25
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.
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);
}
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.
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
Related
I am trying to use EF Code First on an existing database. I first tried some of the reverse-engineering tools, but I ran into problems with that, so at the moment I am trying to hand-code some of the classes. I am having some trouble getting some of the foreign key relationships set up. Consider two tables. The first is called LocaleValueLookup:
public class LocaleValueLookup
{
public int Id { get; set; }
public Guid Guid { get; set; }
}
This table provides an Id for multi-language text held in a different table (that other table is not important for the purposes of this question). The second table is called SectionType, and it has an optional FK to LocaleValueLookup:
public class SectionType
{
public int EnumId { get; set; }
public string Name { get; set; }
public int? DefaultSectionTextLocaleValueLookupId { get; set; }
// Navigation property
public LocaleValueLookup DefaultSectionTextLocaleValueLookup { get; set; }
}
I have tried various things, including adding a [ForeignKey] attribute to the SectionType.LocaleValueLookup property, and various incantations in the DbContext.OnModelCreating() override, but when I query the DbContext, I can't get the DefaultSectionTextLocaleValueLookup to be anything but null. I can retrieve other objects from the context just fine, and I have verified that DefaultSectionTextLocaleValueLookupId is not null at least some of the time.
My OnModelBuilding() contains the following:
modelBuilder.Entity<LocaleValueLookup>()
.ToTable("LocaleValueLookup")
.HasKey(lvl => lvl.Id);
modelBuilder.Entity<LocaleValueLookup>().Property(lvl => lvl.Id).IsRequired();
modelBuilder.Entity<SectionType>()
.ToTable("SectionType")
.HasKey(st => st.EnumId);
modelBuilder.Entity<SectionType>().Property(st => st.EnumId).IsRequired();
A couple of other points:
I would prefer not to have a SectionType collection on the LocaleValueLookup object. LocaleValueLookup is a low-level class that a lot of other classes depend on, so to include a collection property on LocaleValueLookup for every other class that references it will make for an unwieldy class with a lot of collections on it that I don't need from a domain perspective.
I would prefer to do the mapping setup in DbContext.OnModelCreating() rather than using attributes on my model objects
Any help would be greatly appreciated!
It looks like your foreign key is nullable so that means an optional -> many relationship.
Could you try something like this:
modelBuilder.Entity<SectionType>()
.HasOptional(opt => opt.DefaultSectionTextLocaleValueLookup)
.WithMany() // no navigation on the other side
.HasForeignKey(fk => fk.DefaultSectionTextLocaleValueLookupId);
If you were to write a query like this you should get a value back:
var query =
from st in db.SectionTypes
where st.EnumId == 12345
select new
{
SectionType = st,
LocaleValue = st.DefaultSectionTextLocaleValueLookup
};
It will only be non-null if the foreign key has a value, obviously.
I am using Entity Framework/Fluent API and I am new to them. In my scenario I am having the following three classes.
public class Review
{
public int Id { get; private set; }
public float AverageRating { get; private set; } //Computed Field
public int TotalLikes { get; private set; } //Computed Field
public List<Rating> Ratings { get; private set;}
public List<Like> Likes { get; private set;}
}
public class Rating
{
public int CustomerId { get; private set; }
public int ReviewId { get; private set; }
public int Rating { get; set; }
}
public class Like
{
public int CustomerId { get; private set; }
public int ReviewId { get; private set; }
}
I have Fluent mapping for all three classes and their relationships. In the review class I have two computed fields. I could populate computed fields from child collections (Ratings and Likes). In that case in the Linq query I have to include both child collections, which I believe is a performance intensive operation. Alternatively I could also use computed columns in the DB. But I don't like to put anything in the database side. So, what is the best way of populating the computed fields (mostly aggregate operations like Count, Average, etc) without loading the child collections or using a database solution?
If you don't want to use a database solution like a stored procedure or using computed columns on the database side then this leaves us with one option i guess. That is have a method in your repository like GetRatings() or something similar and use a linq query in that method to compute ratings, of course LINQ to Entities will convert that Linq query to a native SQL query which should be faster as it is native to the database.
With out using Database solution...
Linq has count/max/average,Sum,groupby,distinct .... etc So Pulling data back once the DB has "calculated it", such as a count or sum integer isnt normally an issue.
So no need to drag back all objects.
The use of concurrency checking to keep integrity when posting back . ie Timestamp EF type Rowversion, Will be necessary
Basically with EF you put a value in the context and SAY Save.
So the key thing to remember is when Saving, how to make sure the data is OK.
Thats the role of the Rowversion. (optimistic locking)
If the record you are changing has changed since you read it, fail.
You re-read/recalc and try again.
However, if your application demands pessimistic locking
then this article from Ladislav is recommended reading
Essentially EF doesnt offer Pessimistic locking.
HOWEVER, you can call the DB using methods exposed on EF, or just call the DB.
Context.Database.ExecuteSqlCommand()
Note by default EF does not read Dirty data.(ie no uncommitted read)
After all that you still need/want pessimistic locking semaphore style to access to the data.
then see Application Lock on SQL server
YEP you will need the DB, unless you have an ENQUEUE server handy;-)
The official approach to defining navigation properties for complex entities is:
public class SuperEntity
{
public int Id { get; set; }
//Other properties
}
public class LowerEntity
{
public int Id { get; set; }
public int SuperEntityId { get; set; }
public virtual SuperEntity SuperEntity { get; set; }
//Other properties
}
The main thing here is that a class that references (allows navigation to linked super entity) has both public SuperEntity SuperEntity { get; set; } property, as well as it's Id in public int SuperEntityId { get; set; }.
I have gone a few days into my entities design ommiting the public int SuperEntityId { get; set; } property in the "lower entities". So I am navigating only by virtual SuperEntity property. And everything works fine! But I had people on SO telling me that it creates an excessive tables in the DB. I've checked, and that is not true. When I use my approach, the DB tables has the SuperEntityId column and just populates it with the referenced entity Id automatically. What's the point in this public int SuperEntityId { get; set; } field then?
Or, perhaps, what I am doing became available in a "fresh" versions of EF like 4.3?
The point of SuperEntityId is that it is sometimes easier to use a foreign key property in apps where your context isn't alive the entire time, e.g. a webapp.
In such a situation, it's a lot easier to just use a foreign key property, than to try to attach object B to object A.
As far as I know, with nav properties, EF uses an object to track the relation between 2 objects. So if you want to couple object B to object A, in a disconnected app, it's not enough to just set the property on object A, you also have to fiddle with the entry of object A in the changetracker to register the relation between B and A.
Setting a foreign key property is the equivalent of this fiddling.
When we were just beginning with EF and didn't know about all of this, every time we wanted to connect 2 objects, e.g. B to A, and B already existed in the DB, the context thought that B was a new object instead of an existing one, and duplicated the record in the DB.
It won't create excessive tables, but it will probably generate extra, or longer, queries on that database. But that depends on how you're using these entities.
I'm using Entity Framework Code First. The class i'm trying to create contains two collections (of the same type). I'm having problem recovering my respective collections.
My classes look like this:
public class Destination
{
public int DestinationId { get; set; }
public string Name { get; set; }
public List<Lodging> Lodgings { get; set; }
public List<Lodging> Lodgings2 { get; set; }
}
public class Lodging
{
public int LodgingId { get; set; }
public string Name { get; set; }
public Destination Destination { get; set; }
}
I created a new Destination, then I reopened (closed & opened) the database connection. When I retrieve the destination, my collections (dest.Lodgings and dest.Lodgings2) are null. How do I restore the respective collections? If my class only has one collection of a particular type, I could do the following:
var lodgings = context.Lodgings.Where(l => l.Destination.DestinationId == destId).ToList();
I can see that the relationships are maintained in the database schema (Destination_DestinationId1 and Destination_DestinationId2) but I don't seem to be able to get to them.
Any suggestion would be appreciated.
In addition to using Include (as you've discovered) (which loads the related data from the db at the same time the destination is retrieved) you can also retreive the lodgings after the fact. So if you query for the destination and then you want the lodgings, that's possible. One way is called explicit loading where you will use a Load method. The other is with lazy loading, which requires that your classes be set up a particular way and just the mere mention of the Lodgings property will trigger the call to the database to retrieve them.
there's a great blog post on the Ef team blog about the various ways to load related data with DbContext : http://blogs.msdn.com/b/adonet/archive/2011/01/31/using-dbcontext-in-ef-feature-ctp5-part-6-loading-related-entities.aspx
hth
Julie
I have a mental debate with myself every time I start working on a new project and I am designing my POCOs. I have seen many tutorials/code samples that seem to favor foreign key associations:
Foreign key association
public class Order
{
public int ID { get; set; }
public int CustomerID { get; set; } // <-- Customer ID
...
}
As opposed to independent associations:
Independent association
public class Order
{
public int ID { get; set; }
public Customer Customer { get; set; } // <-- Customer object
...
}
I have worked with NHibernate in the past, and used independent associations, which not only feel more OO, but also (with lazy loading) have the advantage of giving me access to the whole Customer object, instead of just its ID. This allows me to, for example, retrieve an Order instance and then do Order.Customer.FirstName without having to do a join explicitly, which is extremely convenient.
So to recap, my questions are:
Are there any significant disadvantages in
using independent associations? and...
If there aren't any, what
would be the reason of using foreign key associations at all?
If you want to take full advantage of ORM you will definitely use Entity reference:
public class Order
{
public int ID { get; set; }
public Customer Customer { get; set; } // <-- Customer object
...
}
Once you generate an entity model from a database with FKs it will always generate entity references. If you don't want to use them you must manually modify the EDMX file and add properties representing FKs. At least this was the case in Entity Framework v1 where only Independent associations were allowed.
Entity framework v4 offers a new type of association called Foreign key association. The most obvious difference between the independent and the foreign key association is in Order class:
public class Order
{
public int ID { get; set; }
public int CustomerId { get; set; } // <-- Customer ID
public Customer Customer { get; set; } // <-- Customer object
...
}
As you can see you have both FK property and entity reference. There are more differences between two types of associations:
Independent association
It is represented as separate object in ObjectStateManager. It has its own EntityState!
When building association you always need entitites from both ends of association
This association is mapped in the same way as entity.
Foreign key association
It is not represented as separate object in ObjectStateManager. Due to that you must follow some special rules.
When building association you don't need both ends of association. It is enough to have child entity and PK of parent entity but PK value must be unique. So when using foreign keys association you must also assign temporary unique IDs to newly generated entities used in relations.
This association is not mapped but instead it defines referential constraints.
If you want to use foreign key association you must tick Include foreign key columns in the model in Entity Data Model Wizard.
Edit:
I found that the difference between these two types of associations is not very well known so I wrote a short article covering this with more details and my own opinion about this.
Use both. And make your entity references virtual to allow for lazy loading. Like this:
public class Order
{
public int ID { get; set; }
public int CustomerID { get; set; }
public virtual Customer Customer { get; set; } // <-- Customer object
...
}
This saves on unnecessary DB lookups, allows lazy loading, and allows you to easily see/set the ID if you know what you want it to be. Note that having both does not change your table structure in any way.
Independent association doesn't work well with AddOrUpdate that is usually used in Seed method. When the reference is an existing item, it will be re-inserted.
// Existing customer.
var customer = new Customer { Id = 1, Name = "edit name" };
db.Set<Customer>().AddOrUpdate(customer);
// New order.
var order = new Order { Id = 1, Customer = customer };
db.Set<Order>().AddOrUpdate(order);
The result is existing customer will be re-inserted and new (re-inserted) customer will be associated with new order.
Unless we use the foreign key association and assign the id.
// Existing customer.
var customer = new Customer { Id = 1, Name = "edit name" };
db.Set<Customer>().AddOrUpdate(customer);
// New order.
var order = new Order { Id = 1, CustomerId = customer.Id };
db.Set<Order>().AddOrUpdate(order);
We have the expected behavior, existing customer will be associated with new order.
I favour the object approach to avoid unnecessary lookups. The property objects can be just as easily populated when you call your factory method to build the whole entity (using simple callback code for nested entities). There are no disadvantages that I can see except for memory usage (but you would cache your objects right?). So, all you are doing is substituting the stack for the heap and making a performance gain from not performing lookups. I hope this makes sense.