Question

I’m making a start on an MVC project, having gone through the MvcMusicStore tutorial. I’m trying to get my head around how the POCO-generated data/entity context is intended to be stored.

In the samples, the controller generates a copy of the entity context, and all operations complete there:

        MusicStoreEntities storeDB = new MusicStoreEntities();

        //
        // GET: /Store/

        public ActionResult Index()
        {
            // Retrieve list of Genres from database
            var genres = from genre in storeDB.Genres
                         select genre.Name;
            [...]

If I’m to split my solution into layers, what is the standard practice (or key options) for retaining the context? Do I generate it in the controller, and pass it to the repository, or is it possible for the repository to keep a general-use copy?

I understand that the the above would be necessary to use the Unit of Work pattern.

My layers are:

• Data (edmx file)
• Entities (Generated from POCO)
• Repository
• Mvc web app

My other questions:
– What is the overhead of generating the context?
– As there is no .Close(), and it doesn’t implement IDisposable, is the ObjectContext behind it generating individual connections, connection pooling, sharing a single instance?
– Is it possible to lock an ObjectContext if it’s passed around between layers / operations too much?

Thanks in advance.

Answer 1

I don’t want to go into too much detail/code here, so i’ll just mention some points:

1. Your controller can work with multiple repositories
2. There should be one repository per aggregate root
3. Controller work amongst multiple repositories are made possible by Unit of Work
4. Use a DI container to handle lifetime management of Unit of Work (which is actually the context)
5. Do not use singletons for the Context, let the DI container instantiate/dispose of the context per HTTP request