I’m putting together a code first model that has a lot of reference data. This model is based around applications, servers, and build deployments. Thus, there are a lot of many to many relationships. The pain that I’m feeling is that new records are being placed in the entity tables which I’m attempting to use as reference data. For example, we have a list of servers. I only want to see a server ONCE in the table. For all the entities referring to that server, I want them to use that row. The same can be said of my ServerRoles and Applications tables. These tables contain static data that I’m seeding and should rarely change.
I know I could solve this with look-ups and hand wiring, but I would think EF would comprehend this scenario.
Using Entity Framework code-first you can create an immutable object with protected parameter less constructor and private set properties.
It works for sure with EF 5 Beta.
[Update]
Tested also with EF 4.3.1, it works.
public class Nation
{
protected Nation() {}
public Nation(Guid id, string name)
{
Id = id;
Name = name;
}
public Guid Id { get; private set; }
public string Name { get; private set; }
}
Related
Since I already have a DB project in my solution, I was wondering can I leverage Entity Framework so that the Web Application may communicate with the database without having to do any migrations, or is migration necessary in order to use the Context of Entity Framework?
If migrating is not necessary then I also won't need the designer (edmx) file, I could just make my models and link them into my context right?
Not necessary at all.
I often write short solutions towards some databases where I just want to add some functionality on the fly. What I typically do is to just open SQL Server Object Explorer in VS2015, Expand the table I'm interested in, and just write a class on the fly, matching the fields that I need.
I.e for a table named "Classes" in the database, I would end up with a class in C#
public class SomeClass
{
public int Id {get; set;}
public string Title {get; set;}
// +other intersting fields
}
Then I simply create a DbContext class pointing to my database:
public class MyContext : DbContext
{
public DbSet<SomeClass> Classes{get; set;}
public MyContext() : base("myConnectionString"){}
}
That's it. No need for migrations. It then simply just works :)
We're looking at upgrading our dinosaur of EF 4.2 this week to EF 6.0.2 (Code First). For the most part, aside from some namespace changes, everything works, with one exception.
Using EF 4.2, one particular many-to-many relation had a specific join table name expected. EF 6 expects a different one.
Here is the relevant portions of code
public class MyDbContext : DbContext {
/* some unrelated collections*/
public IDbSet<DBFoo> Foos { get; set; }
/* some unrelated collections */
public IDbSet<DBBar> Bars { get; set; }
/* some unrelated collections */
}
public class DBFoo {
/* DBFoo's properties */
public virtual ICollection<DBBar> Bars { get; set; }
}
public class DBBar {
/* DBBar's properties */
/*some unrelated navigation properties (some single, some collections)*/
public virtual ICollection<DBFoo> Foos { get; set; }
/*more unrelated navigation properties*/
}
It's important to note that the "unrelated" properties mentioned are other entities, but themselves have no references to "DBFoo".
Now, in EF 4.2, the join table between these two entities was expected to be DBBarDBFoos. This was without any configuration in the model builder or context or by using any data annotations.
After upgrading to EF 6.0.2, the join table is expected to be DBFooDBBars. Why?
Note: I have "fixed" this issue by using the fluent API to bind the relationship to its proper table. What I want to know is why this table(and only this table) changed in it's convention.
Ninja Edit - rearranging the property declaration in the DBContext had absolutely zero effect.
see the answer from the EF team
https://entityframework.codeplex.com/workitem/1677
Answer by RoMiller
Hello,
Prior to EF6 there were some areas of model creation that were non-deterministic - depending on whether you were running on x86 or x64 you could get a different model. The many to many join table name was one of these areas.
In EF6 we addressed this to ensure the results would always be the same. Unfortunately, that does mean that for some models (depending on which architecture they were running on) upgrading to EF6 can cause a model change. But the model that is now calculated will be consistent across machines and future versions of EF.
If you want to continue using the original name, the best option is to use the Fluent API to specify the join table name.
~Rowan
On my own projects I use RavenDB. At work I use SQL Server and Entity Framework (code first).
So designing domain entities is a challenge, as I really enjoy RavenDB's ability to create an application-centric, DDD style application, that isn't tied at all to a database implementation.
At the moment I'm trying to persist an entity that has a collection of GUIDs that reference other entities in the system. For example (not the actual class, but the same concept):
public class Thing
{
public Thing()
{
this.VisibleSectionIds = new Collection<Guid>();
}
public Guid Id { get; set; }
public string Name { get; set; }
public ICollection<Guid> VisibleSectionIds { get; set; }
}
Using RavenDB, I can persist this in a few lines of code with no need to redesign the database. I can even make my collection of ids read-only.
Can people suggest ways that I could do a similar thing in EF without introducing mapping properties to other entities (this would break my DDD approach and possibly introduce N+1 issues). Can I use EF to convert my collection of GUIDs to a text datatype in the database and convert it back again?
How to create an entity type and then generate a database table from it?
I know this feature was not supported two years ago in EF, what about now?
You've got 2 options:
Entity Framework Model First where you create the model first and then generate the database from that or
Entity Framework Code First where you create normal Poco objects and generate the database from that.
I've personally used Entity Framework Code First for MVC development and it works like a charm, it really is an awesome feature and easy to use.
Now, Entity Framework introduced these feature.
Basically, with only two steps is sufficient for this, please see below steps to go:
Create your Entity
public class Resturant
{
public int ID { get; set; }
public string Name { get; set; }
}
Create Context class
public class OdeToFoodDb: DbContext
{
public DbSet<Resturant> Resturants { get; set; }
}
However, you may need more coding in Global.ascx for advance options but these are the basic steps.
A database named "OdeToFoodDb" will create and a table named "Resturant" also will create by these steps.
Im currently looking at migrating from fluent nHibernate to ADO.Net Entity Framework 4.
I have a project containing the domain model (pocos) which I was using for nHibernate mappings. Ive read in blogs that it is possible to use my existing domain model with EF4 but ive seen no examples of it. Ive seen examples of T4 code generation with EF4 but havent come accross an example which shows how to use existing domain model objects with EF4. Im a newby with EF4 and would like to see some samples on how to get this done.
Thanks
Aiyaz
Quick walkthrough :
Create an entity data model (.edmx) in Visual Studio, and clear the "custom tool" property of the edmx file to prevent code generation
Create the entities in your entity data model with the same names as your domain classes. The entity properties should also have the same names and types as in the domain classes
Create a class inherited from ObjectContext to expose the entities (typically in the same project as the .edmx file)
In that class, create a property of type ObjectSet<TEntity> for each of you entities
Sample code :
public class SalesContext : ObjectContext
{
public SalesContext(string connectionString, string defaultContainerName)
: base(connectionString, defaultContainerName)
{
this.Customers = CreateObjectSet<Customer>();
this.Products = CreateObjectSet<Product>();
this.Orders = CreateObjectSet<Order>();
this.OrderDetails = CreateObjectSet<OrderDetail>();
}
public ObjectSet<Customer> Customers { get; private set; }
public ObjectSet<Product> Products { get; private set; }
public ObjectSet<Order> Orders { get; private set; }
public ObjectSet<OrderDetail> OrderDetails { get; private set; }
}
That's about it...
Important notice : if you use the automatic proxy creation for change tracking (ContextOptions.ProxyCreationEnabled, which is true by default), the properties of your domain classes must be virtual. This is necessary because the proxies generated by EF 4.0 will override them to implement change tracking.
If you don't want to use automatic proxy creation, you will need to handle change tracking yourself. See this MSDN page for details