Home/ Questions/Q 971645
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T02:59:49+00:00

I am trying to put together a simple POC for a n-layer application using

  • 0

I am trying to put together a simple POC for a n-layer application using EF4 in the data tier. I have looked at numerous examples on the web and it seems to be a common practice to use a DAO or a Repository as the wrapper to an ORM. My understanding that the main difference between the two is that a Repository is more generic and takes IQueryable for example for parameters. I would like (for better of for worse) at this point to stick with simpler DAO objects that will contain fairly specific methods such as GetPersonByFirstName(string name), similarly to what has been done before with ADO.NET based stuff. That said, I still need several “cross-cutting” features for my DAOs.

  1. How do I go about sharing the context between DAOs? Preferably this would be in a way where the business object instantiating the DAO wouldn’t have knowledge of EF. Initially I was thinking that the BO will be passing the session along to the DAOs but that will violate my requirement of the BO being independent of EF (unless I am not thinking of something). Maybe some sort of Singleton/Factory approach?
  2. Is there a more elegant way to handle this for ASP.NET applications using the request context? Basically a session-per-request type setup, but without having to modify any of the presentation tier code.
  3. I imagine I might have a base class DAO with very basic CRUD methods that will be shared across all DAOs, but again not to the point of IQueryable.
  4. I would like to use TransactionScope within my business object to wrap my DAO (I don’t see this being an issue).

Thank you!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    After doing some more research it seems that I am on the right track of storing the Entity Framework context in httpContext.Items. There are plenty of solutions out there that basically create a factory that manages the lifetime of the EF context that way. My main issue with that solution is that my libraries wouldn’t work non-web projects, so I think I need to go down the path of using an IoC container (instead of the factory) to inject the context for me with the lifetime of object-per-request. This way if I need to use my libraries in a console application for example I could change the configuration to something like object-per-thread etc.

    • 0