Associations in EF Code First: Part 1 – Introduction and Basic Concepts
|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:
A Note For Those Who are New to EF and Code-FirstIf 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 AssociationsI 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:
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?Mapping is 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 RelationshipsThere are two categories of object relationships that we need to be concerned with when mapping associations. The first category is based on multiplicity and it includes three types:
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 ICollection of 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.