The problem you have is the difference in lifestyles between your service, repository, unitofwork and dbcontext. Because the MemberRepository has a Singleton lifestyle, Simple Injector will create one instance which will be reused for the duration of the application, which could be days, even weeks or months with a WinForms application. The direct consequence from … Read more
I thought I’d take a crack at answering my own question. What follows is just one way of solving the issues 1-3 in my original question. Disclaimer: I may not always use the right terms when describing patterns or techniques. Sorry for that. The Goals: Create a complete example of a basic controller for viewing … Read more
I’ve gone down many paths and created many implementations of repositories on different projects and… I’ve thrown the towel in and given up on it, here’s why. Coding for the exception Do you code for the 1% chance your database is going to change from one technology to another? If you’re thinking about your business’s … Read more
There’s a bit of a confusion here. Repositories access aggregate roots. Aggregate roots are entities. The reason for this is separation of concerns and good layering. This doesn’t make sense on small projects, but if you’re on a large team you want to say, “You access a product through the Product Repository. Product is an … Read more
Actually the T4 templates in EF 4.0 were designed with this scenario in mind 🙂 There are 2 templates: One for the Entities themselves (i.e. ModelName.tt) One for the ObjectContext (i.e. ModelName.Context.tt) You should put the ModelName.tt file in you POCO project, and just change the template to point to the EDMX file in the … Read more
This is duplicate of many topics already discussed on SO but I agree that some of them can be hard to find because they are nested in other question What’s the point of Generic repository in EF 4.1 Challenges with testable and mockable code in EF Another question about challenges with mocking EF code Implementing … Read more
The Per Thread Lifetime is a very dangerous lifestyle and in general you should not use it in your application, especially web applications. This lifestyle should be considered dangerous, because it is very hard to predict what the actual lifespan of a thread is. When you create and start a thread using new Thread().Start(), you’ll … Read more
Sure, a function to create and dispose your Connection will work great. protected void Execute(Action<IDbConnection> query) { using (IDbConnection db = new SqlConnection(ConfigurationManager.ConnectionStrings[“myDB”].ConnectionString)) { query.Invoke(db); } } And your simplified call site: public void SaveCustomer(CustomerDTO custDTO) { Execute(db => db.Execute(saveCustSp, custDTO, CommandType.StoredProcedure)); } With Return Values: public T Get<T>(Func<IDbConnection, T> query) { using (IDbConnection db … Read more
Repository Layer gives you additional level of abstraction over data access. Instead of writing var context = new DatabaseContext(); return CreateObjectQuery<Type>().Where(t => t.ID == param).First(); to get a single item from database, you use repository interface public interface IRepository<T> { IQueryable<T> List(); bool Create(T item); bool Delete(int id); T Get(int id); bool SaveChanges(); } and … Read more
DAO is an abstraction of data persistence. Repository is an abstraction of a collection of objects. DAO would be considered closer to the database, often table-centric. Repository would be considered closer to the Domain, dealing only in Aggregate Roots. Repository could be implemented using DAO‘s, but you wouldn’t do the opposite. Also, a Repository is … Read more