449

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 ...


111

Checking for uniqueness and then setting is an antipattern; it can always happen that the ID is inserted concurrently between checking time and writing time. Databases are equipped to deal with this problem through mechanisms like constraints and transactions; most programming languages aren't. Therefore, if you value data consistency, leave it to the expert ...


103

I don't see any reason for the 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/...


49

Returning IQueryable will definitely afford more flexibility to the consumers of the repository. It puts the responsibility of narrowing results off to the client, which naturally can both be a benefit and a crutch. On the good side, you won't need to be creating tons of repository methods (at least on this layer) — GetAllActiveItems, ...


46

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 ...


38

I think what you call “fail fast” and what I call it is not the same. Telling the database to make a change and handling the failure, that is fast. Your way is complicated, slow and not particularly reliable. That technique of yours is not fail fast, it is “preflighting”. There are sometimes good reasons, but not when you use a database.


36

Generic repository is even useless (and IMHO also bad) for Entity Framework. It doesn't bring any additional value to what is already provided by IDbSet<T> (which is btw. generic repository). As you have already found the argument that generic repository can be replaced by implementation for other data access technology is pretty weak because it can ...


31

Personally, I've tried making one huge schema for all my entities on a fairly complex but small project(~300 tables) . We had an extremely normalized database (5th form normalization (I say that loosely)) with many "many to many" relationships and extreme referential integrity enforcement. We also used a "single instance per request" strategy which I'm not ...


30

Exposing IQueryable to public interfaces is not a good practice. The reason is fundamental: you cannot provide IQueryable realisation as it is said to be. Public interface is a contract between provider and clients. And in most cases there is an expectation of full implementation. IQueryable is a cheat: IQueryable is nearly impossible to implement. And ...


25

I think a lot of programmers first try to take the shortcut of binding directly to the model, but in my experience this has some major drawbacks. The primary problem is that if your entity model is persisted by NHibernate or similar, then as soon as the View updates the model property, then NHibernate could persist those changes to the database. That doesn'...


23

In my applications I have always separated things out, with different models for the database (Entity Framework) and MVC. I have separated these out into different projects too: Example.Entities - contains my entities for EF and the DB context for accessing them. Example.Models - contains MVC models. Example.Web - web application. Depends on both Example....


23

It is up to you. Most people will tell you that it's not a good practice but you can get away with it in some cases. EF never played nicely with DDD for multiple reasons, but two stand out: you can't have parameterized constructors on your entities and you can't encapsulate collections. DDD relies on that, since the domain model should include both data ...


21

There are times when doing a ToList() on your linq queries can be important to ensure your queries execute at the time and in the order that you expect them to. Those scenarios are however rare and nothing one should worry too much about until they genuinely run into them. Long story short, use IEnumerable anytime you only need iteration, use IList when you ...


20

I believe you mean "junction" table, not "join" table. There is no need for a junction table to have it's own ID field. You would never need to join or filter on such an ID. You would only join or filter on the ID's of the tables you're mapping. An ID on a junction table is a waste of disk space. So the "best" option is to avoid the ID. Typically a ...


19

Realistically, you've got three alternatives if you want deferred execution: Do it this way - expose an IQueryable. Implement a structure that exposes specific methods for specific filters or "questions". (GetCustomersInAlaskaWithChildren, below) Implement a structure that exposes a strongly-typed filter/sort/page API and builds the IQueryable internally. ...


19

The advice at the post you linked about using GUIDs for clustered primary keys is seven years old and almost certainly bad advice today. The article it refers to references SQL Server 7. We use GUIDs for every primary key in our database, and expose those GUIDs in the URLs that hit our JSON services. We can do this because we don't expose our database ...


18

There's no substantive difference, except that you'll have to actually build a binary if you wanted to make a configuration change if you put it in a DLL, whereas an admin could just modify the configuration with well-understood off-the-shelf tools if it's in the config. There's already a mechanism for encrypting configuration strings and additional guidance ...


18

To get this out of the way, I am a big proponent of Entity Framework, but it does come with some drawbacks that you need to be aware of. I also apologize for the long answer, but this is a very hot topic with many opinions and many required considerations. For small application, a lot of these considerations don't matter, but for enterprise-grade ...


17

EntityFramework is a great tool, but like any great tool you would do yourself a great disservice to not understand the inner workings of how it translates a data model into a database schema, and also how it translates its own queries into SQL. Everything works great until something goes wrong, then you are looking in log files trying to decipher the ...


16

The point of a ViewModel is that it is a model of the View. You should be binding the ViewModel to the View, not any Model properties (not directly, anyways).


16

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.


15

This started as a comment but grew too large. No, as the other answers have stated, this pattern should not be used.* When dealing with systems that use asynchronous components, there will always be a race condition where the database (or file system, or other async system) may change between the check and the change. A check of this type is simply not a ...


14

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


13

The example you provide is hardly layered architecture. I know it is intentionally simplified, but: Your presentation layer is directly tied to the Person entity. This is OK only in simplest cases, and definitely not when you are trying to define your layers. The GetPerson method is also using a rather bad practice of creating a new context for each call. ...


13

Let me start by simple clarification: I don't have experience with such large database so the rest of my answer is not based on the real world example. So you have a BIG database and you want to use it with ORM / EF. I would go with the second choice. Here is my simple explanation why: Mapping adds complexity. There is no need to add complexity with ...


12

It doesn't matter where the encrypted data is stored, it matters how it's encrypted. Encrypted sections in an web.config are normally encrypted with the Data Protection API, which is extremely difficult to crack without compromising the entire machine. You can also use an RSA key container, which is similar (difficult to get those off the machine). If you ...


12

so it would have been impossible to switch out to another ORM (not that we wanted to)). That seems wrong. A major advantage of the repository pattern is that you hide the data access logic and that it is easily exchangeable. So far it feels as though I put my business logic in my domain model and via repositories I would work with the ORM (which ever ...


12

This subject has already been covered several times, you may be interested in reading: https://stackoverflow.com/questions/8676/entity-framework-vs-linq-to-sql. The top answer is short and right on the spot although a little bit dated (2008) https://stackoverflow.com/questions/3293995/what-is-the-difference-between-entity-framework-and-linq-to-sql-by-net-4-...


12

You can create a User class that has nothing to do with ASP.NET Identity in your core library. public class User { public Guid UserId { get; set; } public string UserName { get; set; } public string EmailAddress { get; set; } public string EmailAddressConfirmed { get; set; } public string PhoneNumber { get; set; } public string ...


12

I think you are conflating repositories and generic repositories. A basic repository just interfaces your data store and provides methods to return the data IRepository { List<Data> GetDataById(string id); } It doesn't leak the data layer into your code via an IQueryable or other ways of passing in random queries and provides a well defined ...


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