Tag Info

Hot answers tagged

115

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


91

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.


78

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


60

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


33

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


26

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


24

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


20

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


19

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


19

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


18

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.


17

All those things are optional, use them if they're helpful, don't if they're not. It's as simple as that. You can certainly write good/proper web apps w/o any of those acronyms in your solution. Personally, I tend to find MVC to be a pretty lightweight and easy to use framework (much easier to get started on than webforms, imo). Likewise, LINQ provides ...


16

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


14

SQL skill is a must have skill in IT today. LINQ is a Microsoft Only technology. SQL usages go beyond web and client/server application development. You can't model databases and do ETL if you are not good with SQL. You may not need to master SQL dialects used in ORACLE and SQL Server for their Data Warehous products, but you should know standard SQL. SQL ...


14

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


13

My opinion is that code first's automatic database creation is only for development. I answered similar questions on Stack Overflow where I described both how to upgrade the database and why is automatic functionality bad in production: Deploying database changes in EF 4.1 Using EF4 code first: How can I change model without loosing data Upgrading the ...


13

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


12

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


12

Returning IQueryable will definitely afford more flexibility to the consumers of the Repo. 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 or repository methods (at least on this layer) GetAllActiveItems, GetAllNonActiveItems, etc.. to ...


11

Entity Framework is a productivity tool. Unless you have a good reason not to (E.G. you are on SQL 2000 or have no time to ramp up on the technology), then use the best tools at your disposal. That being said, I find the concept of Entities to translate very well to the MVC pattern's Model. While having a 1:1 relationship with Models and tables is a bad ...


10

No, not really. LINQ is the greatest thing since sliced bread when interacting with a database. What you should remember is that these things are built on other things. LINQ is not adding to the number of things you need to know to develop an ASP.NET website, because now you don't need to know SQL. And LINQ is OO, which is far more in line with regular ...


10

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


10

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


9

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


9

This subject has already been covered several times, you may be interested in reading: http://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) ...


9

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


9

Doing any geospatial work in SQL Server without using the geospatial types is, frankly, insane. Store the postal code if you want for reference, but query based on latitude and longitude using the geography type. It even has an STDistance function that can use a geospatial index in order to return results in constant time. Yes, that involves what you'd ...


8

Yes, but with some caveats: It's fully supported by Microsoft, and has a growing community--but being newer than its closest competetor, nHibernate, it still doesn't have quite as mature a community. Along with having a less mature community, there will be times where a feature is available with EF4 but barely documented; or EF4 will throw exceptions which ...


8

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


8

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



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