426

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


216

The question "which ORM should I use" is really targeting the tip of a huge iceberg when it comes to the overall data access strategy and performance optimization in a large scale application. All of the following things (roughly in order of importance) are going to affect throughput, and all of them are handled (sometimes in different ways) by most of the ...


151

It depends a bit on how much abstraction you need. Everything is a compromise; for example, EF and NHibernate introduce great flexibility for representing the data in interesting and exotic models - but as a result they do add overhead. Noticeable overhead. If you don't need to be able to switch between database providers, and different per-client table ...


109

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


97

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


90

Absolutely! SQL is still the lingua franca of databases and although you may do a lot with ORMs you have to understand SQL to understand the decisions ORMs make and the SQL they generate. Also, there are still lots of things that you have to do with custom sql and stored procedures as well. Sorry, no free lunch.


63

This is hard to explain to a lot of programmers, because if you only know basic SQL then it really doesn't give you much of an advantage over the crutch of an ORM. The more advanced SQL concepts, however, are a crucial part of the difference between applications that just work vs. applications that are high quality (in particular, fast and reliable). I'm ...


46

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


45

I recently switched from using in-line SQL queries to using EF and here's what I've found: Pros Much faster to build the DAL (love not writing the SQL queries!) Much easier to maintain No longer need to remember to parse my input before building an in-line sql statement, which means less chance of a SQL injection attack (of course, it's still possible ...


44

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


37

Edit: Based on @Aaronaught great answer I'm adding few points targeting performance with EF. Those new points are prefixed by Edit. The biggest improvement in performance in high traffic websites is achieved by caching (= first of all avoiding any web server processing or database querying) followed by asynchronous processing to avoid thread blocking while ...


37

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.


35

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


27

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

Yes, you still need to know SQL. ORMs are a very leaky abstraction, and do not provide access to the full power of SQL. For toy applications you may be ok with limited SQL knowledge. For enterprise applications, you will have to understand the database to get decent performance from the ORM. Also there are a great many tasks that are much more easily ...


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


22

Both arguments against existing ORMs are invalid: "Well at least we'll be in control of our own code" Why not write your own language? Your own framework? Your own operating system? And to be sure you're in control of everything, it's also a good idea to create your own hardware. "Oh I've used L2S/EF in a previous project and it was nothing but ...


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


19

Use Entity Framework for all of the ordinary CRUD stuff (80 to 95 percent of the code), and use custom data access code for any remaining code that needs to be optimized. This should satisfy the concerns of those who are arguing that you don't have enough control.


19

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


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

I may have some detractors out there, but when I read some of those post from Hanselman and Gutherie, then read Julia Lerman's book on Entity Framework, I had a REALLY hard time with code first. In my many years of building applications, I've gone down many paths, both forced by process, and by choice, and have found that I have much more success when ...


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.


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