Mapping c++/cli entities to tables (Entity Framework) - entity-framework

I'm trying to map my classes which are defined in a c++/cli library to database by EF6. Table attributes are added to the c++ classes but EF generates
System.ArgumentNullException: 'Value cannot be null.'
as soon as accessing any c++ types, but c# mapped types can be instantiated.
any idea how to resolve this issue?

Related

How does EF codefirst know which model class to create a table for?

I was not able to find the answer to this online - please link me if I've overlooked any resources.
I understand how Entity Framework's codefirst works. The question is: how does EF know which model class to create a table for and which model class to just treat as a class?
For example, in the sample MVC4 application that comes from creating a new MVC project with VS 2012 Express Developer, there are classes (LocalPasswordModel, LoginModel, RegisterModel, etc) in the Account Model that have no tables, and EF knows not to generate tables for these classes.
How does EF know this?
Entity Framework looks at your DbContext class, and creates a table for each DbSet<T> property that you define.
EF won't even see any class which is not referenced by the DbContext.

Entity Framework, Inheritance and Namespacing

I am using the Entity Framework 4.0 and have a conceptual model that makes heavy use of inheritance.
I can perform the standard inheritance functionality just fine but I am having trouble with the namespacing of the generated C# classes.
My problem is that the Entity Framework always generates all the classes (both base and derived) in the same C# namespace. A hypothetical example of the fully qualified names of the classes generated by the Entity Framework (both base and derived) with a root namespace of "MyApp" would look like the following
MyApp.MyBaseClass
MyApp.MyDerivedClassA
MyApp.MyDerivedClassB
MyApp.MyDerivedClassC
etc...
However, I want to to put the base and derived classes into different namespaces. For example, the base class would still be defined in the root namespace (eg. MyApp) but the derived classes would be defined in a "sub namespace" (eg. MyApp.MyDerivedClasses). The fully qualified names of the derived classes would then look like the following:
MyApp.MyDerivedClasses.MyDerivedClassA
MyApp.MyDerivedClasses.MyDerivedClassB
MyApp.MyDerivedClasses.MyDerivedClassC
etc...
I managed to achieve this with Linq To Sql by manually creating (ie. not using the Linq To Sql Designer) InheritanceMappingAttribute on the base class and pointing the mapping to the derived classes that are defined in the "derived" namespace.
However, I can not figure out if it is possible to use different namespaces between the base and derived classes with the Entity Framework 4.0 (with or without the designer). Can this be done and if so how can I do it?
No it is not possible using the standard set of tools.
The namespace specification on the designer file applies to all entities contained in it.
You could try a code first approach to get around this (prolly your best option). Other than that get a good book on T4 templates and modify the T4 POCO generator to let you specify these things.

Asp.NET MVC 2 EF4 Dynamic Proxies

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

Table per hierarchy inheritance with POCO entities in Entity Framework 4

Our organization is looking to standardize on Entity Framework once v4 comes out. As a result, I am looking at what it would take to migrate our application that uses NHibernate for persistence to EF4 using POCO support. In a couple of places we use single table inheritance (also known as Table Per Hierarchy). I have been unable to get it to work using the following.
Payment (base class [should be abstract but having trouble there as well])
CreditCardPayment (concrete implementation)
ACHPayment (concrete implementation)
CheckPayment (concrete implementation)
Right now, I am mapping them with only the base class properties. All of these classes are in the same namespace. They have a discrimimator that is called PaymentTypeId in the database, so the Payment mapping has a condition of "When PaymentTypeId = 0". Each of the subclasses have the same condition with different values (i.e. CreditCardPayment = 1, etc.).
When I try to load each a list of all payments using DataContext.Payments.ToList() (DataContext inherits from ObjectContext) I am getting the following exception:
"Object mapping could not be found for Type with identity 'DataLayer.DataModel.CreditCardPayment'."
I can't figure out what this means, as the POCO CreditCardPayment class lives in the same namespace as the POCO Payment class does (in fact in the same file).
What am I missing?
This is complaining not about database mapping, but model to CLR mapping.
The EF can't for some reason find your CreditCardPayment class.
Now one possible reason is that you haven't loaded the metadata for it yet.
For example if you have this:
Assembly 1:
- Payment
Assembly 2 references Assembly 1:
- CreditCardPayment extends Payment
Then when you query the EF doesn't know where CreditCardPayment lives.
The way to get around this is with LoadAssembly i.e:
using (DataContext ctx = new DataContext())
{
ctx.MetadataWorkspace.LoadFromAssembly(typeof(CreditCardPayment).Assembly);
// now do your query.
}
You need to tell to LoadFromAssembly every assembly that isn't directly reference by your DataContext class.
Note: typeof(Payment).Assembly is directly referenced because of the IQueryable<Payment> Payments property.
Hope this helps
Alex
Microsoft.
What I didn't represent before (I didn't think it relevant, but it was). Was that CreditCardPayment inherited from an intermediary class named "CreditPayment" and ACHPayment inherited from CashPayment. CreditCardPayment and CashPayment live in the same namespace and file, but were not represented in the EF mapping. Once I added those within the mapping file, everything worked ok.
So, even thought EF does not ever map to one of those types directly, it seems to need to know about them, because it changes the basetype of the CreditCardPayment classes et al. Thank you for your help on this.

Is there a transient type in ADO.NET Entity Framework?

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.