Hello all, 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.
- 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?
- 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.
- 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.
- I would like to use TransactionScope within my business object to wrap my DAO (I don't see this being an issue).
Thank you!