In the Entity Framework it is possible to declare abstract types in the EDM model (.csdl file) — that is, no entity instances can be created for these types, but types can be derived from them. In fact, types can be marked as abstract in the designer. The
runtime even allows abstract types to be the base type for multiple different entity sets (imagine a scenario where you want a single base type for all your entities even though they live in multiple sets). For more information, see
EntityType Element (CSDL).
Complex type is the Entity Framework name for value properties that have more intricate structure than scalars. The canonical example is an Address type that contains several parts (street, city, state, etc.) Complex types are somewhat like entities except
that they do not have any identity of their own (they are value types). This means that a complex type instance is always a part of some other enclosing entity—it can't stand on its own, it doesn't have relationships, etc. The Entity Framework supports complex
types, but currently the mapping scenarios for complex types are significantly limited: inheritance is not supported (inheritance is supported for entities—just not for complex types), complex type properties cannot be null and they can only occur in single
instances, not in collections. For more information, see
Complex Type (CSDL).
The Entity Framework supports multiple entity sets per type -- this means you can define a model that has more than one entity set with the same base type. This is important because it enables models that work more naturally with various database models.
If you have two tables with the same schema (for example, "accounts" and "expired_accounts"), then you can define an entity set for each table that uses the same entity type rather than needing to create a different entity type that just happens to have all
the same properties. For more information, see
Entity Sets (CSDL). That said, creating multiple entity sets for the same type can add significant complexity to your model and in practice is rarely used. As a result, the designer, and an increasing number of new Entity Framework runtime features such
as ObjectSet have less full featured or no support for multiple sets for the same type. It is generally recommended to restrict yourself to at most one entity set for each type
The Entity Framework supports associations between subtypes. This means you can define relationships between any types in the type hierarchy even if they aren't the base types. So, for instance, if you have a hierarchy that has Customer and BigAccountCustomer,
then you could create an entity type DiscountPolicy and a relationship that relates BigAccountCustomers to DiscountPolicies, but does not relate Customers to DiscountPolicies.
It should be noted, though, that WCF Data Services (aka Astoria) does NOT currently support associations between subtypes. With Data Services, all associations must be between the root types of the entity sets involved.
Yes. The EDM supports GUID as one of its primitive types. You can use GUIDs as regular columns or as primary keys in your conceptual model. See
Working with Entity Keys for more information on using GUIDs in EntityKeys.
Yes, enums are now supported. Please checkout ADO.Net blog enum support in the June 2011 Entity Framework CTP.
How do I delete an object and all of its related entities? Is it okay to specify the
cascade delete action in the model and not in the database (or the other way around)?
To delete an object and all of its related entities, specify the cascade delete action in the model and in the database. To avoid unexpected results it is strongly recommended that you specify cascade delete rules in both the model and the database.
The following considerations apply when adding cascade delete rules:
The following blog explains why you should have cascade delete rules specified in both the model and the database:
Also, see the Cascade Delete Rules on Relationships section of
Creating, Adding, Modifying, and Deleting Objects.
Yes. The Entity Framework allows storing metadata files as resources in the assembly; in the connection string you can tell the Entity Framework to find them there. The way to do this is to add the CSDL, MSL, and SSDL files to your project and set the "Build
Action" property on each one to "Embedded Resource". Then when you specify your connection string, rather than explicitly listing the metadata files, you can just add "metadata=res://*/;" which tells the EF to look for appropriate resources in your application's
statically linked assemblies. For more information, see
Connection Strings (Entity Framework). The only thing to be careful about is that the assembly that has the resources should be loaded in the same app domain that has the entity connection.
The EDM designer uses a file called EDMX to store all of the metadata about an Entity Framework model. This one file includes the CSDL, MSL, and SSDL files in separate sections within it. At run time, the system requires the three separate files, and the
designer projects automatically create them at build time in the application out directory or as resources in an assembly.
<Using> support in metadata files: Models can be built from multiple separate CSDL files—somewhat like a "using" statement in a C# file, which brings a namespace into the file, or like an #include statement in a C/C++ program except with greater validation
than you get in the purely textual preprocessing of #include. For more information, see [Using Element (CSDL). That said, this feature only allows composition of CSDL
files not MSL or SSDL files and there is no support in the designer. This is a very limited feature that most programmers will not find useful in practice, so it should be ignored.
The EF does not support queries across object contexts (o-space) or entity connections (c-space). It also does not support models mapped to more than one database (if it did, it would be possible to create one object context over tables from multiple databases).
There are two workarounds:
There is support in CSDL files to include custom annotations, which the framework ignores but can be useful for tools or other systems built around the EDM. These annotations are surfaced in the metadata APIs but not otherwise used by the EF.