CODEWITHSUNDEEP
entity-frameworkc#-4.0architectureentity-framework-4entity-framework-4.1
Mohsen
Mohsen

Reputation: 163

Entity Framework code first in data access layer

I am using N-layer architecure in my project. In the data access layer I use Entity Framework code first. When I fill an object in the DAL, dispose the context and transfer the object to the business layer, the navigation properties become null. I have no problem if I don't dispose the context, but my question is it good to dispose the context? If yes, how can I solve the problem when I transfer the object to the next layer (business), so that the navigational properties don't become null. My code in Data access layer:

public List<DomainObject.ContractCenter> GetAll()
{
    try
    {
        List<ContractCenter> contractCenters = new List<ContractCenter>();
        using (var context = new DBContext())
        {
            contractCenters = context.ContractCenters.ToList();
        }

        return contractCenters;
    }
}

Upvotes: 1

Views: 1138

Answers (2)

khellang
khellang

Reputation: 18102

The DbContext should be kept alive as long as your "Unit of Work" is active. E.g. If you are making a web-application, it should be created when the request starts, and disposed, at the latest, when the request ends.

In your case, the DbContext should be kept alive until you've finished populating your domain model, or else the navigation properties which are being lazy loaded will be null, as you mentioned. The downside of "detaching" your entities by disposing the DbContext when you have populated the model is that you lose state tracking of the entities, and you will need to do this yourself when you want to save the data.

If you don't have lots of domain logic I would just add it directly to your code-first POCO entities. In that way, you will still have the state tracking in place.

I would recommend using an IoC container to manage the lifetime of your DbContext, as well as the repository or whatever you are using for data access. Maybe in combination with the Unit of Work pattern. There are lots to choose from, some of my favorites are

There are lots of good tutorials for using an IoC Container to manage lifetime, google it! :)

Upvotes: 2

Yakimych
Yakimych

Reputation: 17752

To answer your questions:

is it good to dispose the context?

Yes, the context should be as short-lived as possible (see @khellang's answer regarding UnitOfWork and IOC if you have a possibility to restructure your project and implement cleaner architecture).

how can i solve the problem when i transfer object to next layer

You need to eager-load the related collections (navigational properties):

public List<DomainObject.ContractCenter> GetAll()
{
    try
    {
        using (var context = new DBContext())
        {
            return context.ContractCenters.
                           Include(c => c.YourChildCollection1).
                           Include(c => c.YourChildCollection2).
                           ...
                           ToList();
        }
    }
}

Upvotes: 1

Related Questions