Earlier this month the data team shipped the Release Candidate of EF 4.1. The most exciting feature of EF 4.1 is Code First, a new development pattern for EF which provides a really elegant and powerful code-centric way to work with data as well as an alternative to the existing Database First and Model First patterns. Code First is designed based on Convention over Configuration paradigm and focused around defining your model using C#/VB.NET classes, these classes can then be mapped to an existing database or be used to generate a database schema. Additional configuration can be supplied using Data Annotations or via a fluent API.
I’m a big fan of the EF Code First approach, and wrote several blog posts about it based on its CTP5 build:
- Associations in EF Code First CTP5: Part 1 – Complex Types
- Associations in EF Code First CTP5: Part 2 – Shared Primary Key Associations
- Associations in EF Code First CTP5: Part 3 – One-to-One Foreign Key Associations
- Inheritance with EF Code First CTP5: Part 1 – Table per Hierarchy (TPH)
- Inheritance with EF Code First CTP5: Part 2 – Table per Type (TPT)
- Inheritance with EF Code First CTP5: Part 3 – Table per Concrete Type (TPC)
Compare to CTP5, EF 4.1 release is more about bug fixing and bringing it to a go-live quality level than anything else. Pretty much all of the API that has been introduced in CTP5 is still exactly the same (except very few changes including renaming of DbDatabase and ModelBuilder classes as well as consolidation of IsIndependent fluent API method). Therefore, the above blog posts are still usable and can (hopefully) help you in your Code First development. Having said that, I decided to complete my Code First articles by starting a whole new series instead of doing post maintenance on the current CTP5 ones.
A Note For Those Who are New to EF and Code-First
If you choose to learn EF you've chosen well. If you choose to learn EF with Code First you've done even better. To get started, you can find an EF 4.1 Code First walkthrough by ADO.NET team here. In this series, I assume you already setup your machine to do Code First development and also that you are familiar with Code First fundamentals and basic concepts.
Code First And Associations
I will start my EF 4.1 Code First articles by a series on entity association mappings. You will see that when it comes to associations, Code First brings ultimate power and flexibility. This series will come in several parts including:
- Part 1 – Introduction and Basic Concepts
- Part 2 – Complex Types
- Part 3 – Shared Primary Key Associations
- Part 4 – Table Splitting
- Part 5 – One-to-One Foreign Key Associations
- Part 6 – Many-valued Associations
Why Starting with Association Mappings?
From my experience with the EF user community, I know that the first thing many developers try to do when they begin using EF (specially when having a Code First approach) is a mapping of a parent/children relationship. This is usually the first time you encounter collections. It’s also the first time you have to think about the differences between entities and value types, or the type of relationships between your entities. Managing the associations between classes and the relationships between tables is at the heart of ORM. Most of the difficult problems involved in implementing an ORM solution relate to association management.
In order to build a solid foundation for our discussion, we will start by learning about some of the core concepts around the relationship mapping and will leave the discussion for each type of entity associations to the next posts in this series.
What is Mapping?
Mappingis the act of determining how objects and their relationships are persisted in permanent data storage, in our case, relational databases.
What is Relationship Mapping?
A mapping that describes how to persist a relationship (association, aggregation, or composition) between two or more objects.
Types of Relationships
There are two categories of object relationships that we need to be concerned with when mapping associations. The first category is based on multiplicityand it includes three types:
- One-to-one relationships: This is a relationship where the maximums of each of its multiplicities is one.
- One-to-many relationships: Also known as a many-to-one relationship, this occurs when the maximum of one multiplicity is one and the other is greater than one.
- Many-to-many relationships: This is a relationship where the maximum of both multiplicities is greater than one.
The second category is based on directionalityand it contains two types:
- Uni-directional relationships: when an object knows about the object(s) it is related to but the other object(s) do not know of the original object. To put this in EF terminology, when a navigation property exists only on one of the association ends and not on the both.
- Bi-directional relationships: When the objects on both end of the relationship know of each other (i.e. a navigation property defined on both ends).
How Object Relationships are Implemented in POCO Object Models?
When the multiplicity is one (e.g. 0..1 or 1) the relationship is implemented by defining a navigation property that reference the other object (e.g. an Address property on User class). When the multiplicity is many (e.g. 0..*, 1..*) the relationship is implemented via an ICollectionof the type of other object.
How Relational Database Relationships are Implemented?
Relationships in relational databases are maintained through the use of Foreign Keys. A foreign key is a data attribute(s) that appears in one table and must be the primary key or other candidate key in another table. With a one-to-one relationship the foreign key needs to be implemented by one of the tables. To implement a one-to-many relationship we implement a foreign key from the “one table” to the “many table”. We could also choose to implement a one-to-many relationship via an associative table (aka Join table), effectively making it a many-to-many relationship.