Im working on Asp.NET MVC 2 project with EF 4(POCO, Lazy disabled) and have a problem with DynamicProxies generated by EF runtime.
I have strongly typed partial view for EF POCO class ie Property, but from EF context i get Property object wrapped by Dynamic Proxy Class, so after calling RenderPartial i get this error:
The model item passed into the dictionary is of type 'System.Data.Entity.DynamicProxies.Property_3A99F7A8373036F07B8DA663F79779BF4FE2B241564ECC50420D0228E5B35C1E', but this dictionary requires a model item of type 'GenReal.Shared.Entities.Property'.
I dont know how to disable EF to do not use Dynamic Proxies, using interfaces instead of classes did not help.
Thank you
Related
Is it possible in Entity Framework using Code First to create a domain model of pure POCOs that are totally ignorant of the Entity Framework?, i.e. don't decorate any classes or properties with any attributes and annotations related to the EF, and don't use virtual keyword to be able to support lazy loading.
Can I achieve this? or do I have to make two models one for persistence model and one for domain model to achieve this.
Entity Framework Code First best practice question?
Hi All I am using EF codeFirst 6 on an NTier app.
I have found that poco object that I am using to map to EF are really EntityFramework specific. Let me give you an example
If I want to add a property that is not related to EF in the object ,EF does not like it.
I Read you can put the "NotMapped" attribute however it start making this object difficult to maintain .
Also there might be developers that are not familiar with EF and that will not understand the issue.
My question is it good practice to keep EF Entity Models separate and have a dto to convert to/from to a Domain Model where
a developer can do what he likes with it without interferring with EF Model which is clearly a 1 to 1 with the tables in the database
Any Suggestions?
Your problem could be resolved by using the Fluent API approach instead of the Attribute-based (Annotations) approach. See Entity Framework Fluent API.
You would configure your entity mappings in the DBContext rather than in the entity classes.
From the above linked article:
Specifying Not to Map a CLR Property to a Column in the Database
The following example shows how to specify that a property on a CLR
type is not mapped to a column in the database.
modelBuilder.Entity<Department>().Ignore(t => t.Budget);
that would mean "ignore the Bugdet property in the Department entity."
Okay, I feel a bit foolish for having to ask this but I guess my understanding of the inner workings of Entity Framework is lacking.
I'd like to experiment with work with DbContext. I have an existing ASP.NET MVC application using EF 4.2. I can get my entities using:
var context = new MyEntities();
And this works just fine.
But how the heck to I get the same data represented by a DbContext?
So I guess you are using default code generator provided by EDMX designer - it will use ObjectContext and heavy weight EntityObject based entities.
If you want to use DbContext you must:
Turn off that default code generation - in property window remove Custom Tool for EDMX file
Download and install DbContext T4 generator (you can get it directly from extension manager in Visual Studio)
In EF designer select Add Code Generation Item from context menu in the designer surface (not on entity)
Now EF will add two .tt files to your project - one will be responsible for creating a new class for every entity or complex type defined in your EDMX file and the second will be responsible for creating class derived from DbContext and exposing sets for all your entity types
What does one loose by creating POCO using T4 templates in entity framework 4.0? Why is the default behavior when using entity framework 4.0 not to create POCO?
You lose a number of things. A "pure" POCO is of limited use in an ORM, because it will not do change tracking. In other words, when you mutate the object and then save changes to the context, you would like the changed properties saved to the database. With a "pure" POCO you can do this with snapshot based change tracking, which is fairly inefficient. You can also do it with runtime proxies, which force you to make your track properties public virtual, so you arguably don't have a "POCO" anymore. Also, using proxies means that you don't know the true runtime type of the instance.
You also lose some of the convenience properties like EntityState.
"Pure" POCOs cannot do lazy loading. Again, you can work around this with proxy types, but, again, if you're using proxies, you don't really have a "pure" POCO.
On top of all of this, there is less need to use POCO entities in the Entity Framework than in some other ORMs. This is because you can always project your entity types onto POCO instances using LINQ, without having to materialize the entity instances first. So "pure" POCOs are always available in an Entity Framework application, even if you don't happen to map your entities that way.
I am using .net 3.5 framework sp1 and VS 2008 sp1. I have created an edmx model. I couldn't create a transient (which is not persisted to the database) property .
Any ideas?
You can add properties to a partial class for the type you are interested in adding transient properties to - see here.
The Entity Data Model doesn't currently support the idea of transient properties. However as Christopher pointed out, you can create a CLR properties in a partial class, that doesn't map to an Entity property.
This will work fine, but bear in mind all references to that property in LINQ to Entity queries will result in exceptions.