Tag Info

Hot answers tagged

30

The single best reason to not use the repository pattern with Entity Framework? Entity Framework already implements a repository pattern. DbContext is your UoW (Unit of Work) and each DbSet is the repository. Implementing another layer on top of this is not only redundant, but makes maintenance harder. People follow patterns without realizing the purpose of ...


28

I don't see any reason for Repository pattern to NOT work with Entity Framework. Repository pattern is an abstraction layer you put on your data access layer. Your data access layer can be anything from pure ADO.NET stored procedures to Entity Framework or an XML file. In large systems, where you have data coming from different sources (database/ XML /Web ...


18

Here's one take from Ayende Rahien: Architecting in the pit of doom: The evils of the repository abstraction layer I'm not sure yet whether I agree with his conclusion. It's a catch-22 - on the one hand, if I wrap my EF Context in type-specific repositories with query-specific data retrieval methods, I am actually able to unit test my code (sort of), which ...


9

The reason why you probably would do that is because it's a little redundant. Entity Framework gives you a wealth of coding and functional advantages, that's why you use it, if you then take that and wrap it in a repository pattern you are throwing those advantages away, you might as well be using any other data access layer.


7

In theory I think it makes sense to encapsulate the database connection logic to make it more easily reusable, but as the link below argues, our modern frameworks essentially take care of this now. Reconsidering the Repository Pattern


6

static ObjectContext class This is actually even worse than what you think. The ObjectContext class is not thread safe so even if you manage to get what you think is good synchronization, (without actually locking) you will still be throwing exceptions all the time in a multi-user environment. The ADO.NET team recommends using a new ObjectContext ...


5

Re: "UOW tracks the elements that needs be changed, and repository contains the logic to persist those changes, but... who call who?" You understand the basic responsibilities of these classes. You say that each of the articles, that you've read, connects them together in different ways. This implies that the decision about "who calls who" is up to you. ...


4

I just finished an article today about the repository pattern (with sample implementations). The thing with most .NET ioc containers is that they support scoping. That is, they can create objects with a limited lifetime. That works very well with HTTP applications since the scope is the same as the lifetime of a HTTP request. If you use ASP.NET MVC you ...


3

Your repositories need to depend on the DbContext and not vice versa. Also, you don't have to implement Unit of Work since the DbContext already implements it. You could do it like this: public interface IRepository<T> { T ReadOne(object key); // so on, so forth... } public class Repository<T> : IRepository<T> where T : class, ...


3

What you want is to instantiate one ObjectContext per web request, regardless of how many different database accesses might be required by that request. And you don't want to share it with any other web requests, or else you'll get your multithreading issues. The approach I take is based on this blog post: "LINQ-to-SQL: the multi-tier story" by Steve ...


3

One reason the Unit Of Work pattern can be efficient, as the paragraph states, is because it can batch several operations and reuse resources. Using Unit of Work provides a context that can contain several operations into a single transaction that might otherwise be difficult to operate on together. Also, not only can the Unit of Work use a single prepared ...


2

What you're describing is a really common pattern where instead of injecting the object of interest you want to inject an object that can create instances of the object of interest. You might call it a factory. If you are using Autofac it is baked in by simply injecting Func<T> (to create instances of T). I'm pretty sure Castle Windsor has this same ...


2

The methods are most commonly given to the UOW interface (which is normally constructed via a factory). You typically call methods on a UOW interface from command pattern class(es) / facade. Since UOW simply defers database IO until later (to prevent you from having long-running transactions or multiple calls to the database that may be unnecessary), ...


2

Services which just change model properties don't sound like data services to me. They sound like model functions, and could (probably should) be in one model class or another. Maybe those methods weren't put in a model class because it wasn't clear where they belonged. I avoid circular references between model classes, so I let owning models depend on ...


2

A very good reason to use the repository pattern is to allow the separation of your business logic and/or your UI from System.Data.Entity. There are numerous advantages to this, including real benefits in unit testing by allowing he use of Fakes or Mocks.


2

Yes, there are many problems with this approach. First, The EF DBContext is not thread safe. If you make it static, then multiple users hitting this DbContext at the same time can cause data corruption, particularly if you're saving any items to the database. Even if it's read-only, you still have to deal with the fact that objects get inserted into the ...


1

I have went through this loop in the last few years, Unit Of Work, wrapping of repo's all calling Entity Framework. You end up with a lot of pointless repository classes (with associated interface), probably wrapping a generic base repo class with a Unit Of Work on top that has lots of properties which expose the repo's. And yes, you are correct, Entity ...


1

DBContext only provides you with a UoW pattern if you code up all the changes in one go yourself, which is pretty much no different to writing a single query in SQL yourself. You should use the UoW pattern if performance is your concern - writing a single hit to the DB is better than writing 1 hit per change. However, most people use an ORM for RAD tooling ...


1

Not everyone of us has the luxury of using a framework which provides a built-in "Unit of Work" component. If you are using Entity Framework's DbContext and it serves you well, use it. If it doesn't, you may have to implement your "Unit of Work" yourself.


1

If you stop worrying about your data and start thinking about your domain model it will become much more clear. I now see you are stuck with unit of work, repositories, data operations, layers and adapters but you forget about your business. What I would suggest to do is to have proper rich domain model designed and have a service layer that will play ...


1

You can add idea 1 on top of idea 2. So I would start with idea 2. I would avoid having lengthy conversation stored locally at the client end. It will result in synchronization complexity and the client may end up being very chatty (and thus slow). Try looking at your web service as a facade. Try sticking to a single call - complete operation pattern. Ask ...



Only top voted, non community-wiki answers of a minimum length are eligible