Tag Info

Hot answers tagged

105

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.


68

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


31

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


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


23

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


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


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.


18

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


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

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


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


11

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


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


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

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

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


7

My dependency injection framework controls the creation and lifetime of the DbContext. The instantiation usually happens when the controller (or one of its dependencies) is instantiated.


7

I think the general goal with ORMs is that the database is mapped directly to domain objects, which are ideally POCOs. So the answer to your question is yes. Now that EF is capable of mapping to POCOs it is ideal to consider those POCOs as domain entities. For other ORMs such as NHibernate this has been possible for awhile and I believe people have ...


7

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



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