Next let's look at the role of object relational mappers in our applications
and how these relate to our core domain model.
First, let's look at Microsoft's ORM tool and Entity Framework.
Julie Lerman actually has a number of excellent courses on Pluralsight
that cover Entity Framework than I can do justice to here.
So I encourage you to take a look at some of her courses to learn more.
What I'd like to do here is demonstrate a few different ways you can implement EF
into your application and tests, and how you can swap out one flavor of any framework
with another or replace it with another ORM entirely.
There are two ways to use Entity Framework currently.
The first is with an Entity data model, which is what we've been doing so far
in our application for the PluralsightBook.
And the more common approach when using a domain-driven design is using code first.
You may use Entity Framework without code first using an Entity data model like this one.
This is the Entity data model we're using in our PluralsightBook application.
When you go this route, you can use these entities directly in your applications code,
or preferably, you can map them to your domain objects.
Assuming that you're using a repository for your data access,
it's best if you design your repository so that it knows
about your entities, but its clients do not.
Thus, you should map between your entities and your domain objects inside of your repositories.
Your repositories should return domain objects that your application works with.
Now, you can do this mapping by hand, perhaps taking advantage of LINQ's select method
for help, or you can use a tool like AutoMapper.
Let's see how we did this in our application so far,
and we'll investigate AutoMapper in a few minutes.
In our application so far, we've created a IFriendRepository interface
that has a few specific methods that we needed.
And we implemented it using Entity Framework as shown here.
Now, this code still could use some refactoring, of course, but I want to call your attention
to the ListFriendsOfUser method, which is the only one we currently have that's returning
anything from our repository.
This friend here is actually a model class,
so it's coming from Pluralsight.Core over here, this model friend.
Note that when we're querying these friends here,
these are actually friends in our data layer.
So these are aspnetdbEntities friends, not our model friends.
In order to map from one to the other, we're using LINQ's select statement here,
and we're instantiating a new friend and setting its ID to the one that's in our entity
and its email address also to the one within our entity.
This kind of mapping code can get very tedious if you have a large data model
and many different domain objects and you're having to implement this
for every different repository that returns a model object.
We'll see in a moment how we can make this a little bit easier using a special tool
called AutoMapper.