I use visual studio 2005 , but recently I've heard that there is a new technology which called entity framework .. should I move on and use it instead of using the usual SqlDataReader !!
the most important thing to me is the performance , note that I get the data from the DB using DataReader and return it as a generic List ..
any suggestion .. thanx :)
views:
333answers:
6
+2
A:
If you want to switch to Linq to Entities then yes, you will need VS2010.
Or you can stay with VS2005/2008 and use nHibernate or similar framework.
But none of those ORM tools is (primarily) about speed, so it may not be the right thing for you.
The reasons for switching to an ORM framework would be to use a more OOP approach, ie to replace your generic list.
Look through a few demos/walkthroughs to decide if it is something for you.
Henk Holterman
2010-08-02 10:19:41
LINQ to Entities doesn't require VS 2010, does it? Admittedly the latest version will, but the previous version should be fine with VS 2008, AFAIK.
Jon Skeet
2010-08-02 10:21:20
@Jon, yes, but I would not recommend the first EF version, or upgrading to VS2008 anymore.
Henk Holterman
2010-08-02 10:24:35
@Henk: That's fair enough, but it's not the same as saying "If you want to switch to L2E, you will need VS2010" :) (There may be other reasons why the OP *can't* use VS2010, but he may be able to use 2008 and EF may still be the best approach.)
Jon Skeet
2010-08-02 10:28:43
He can also use LINQ to SQL which is included in .NET 3.5. I think you need Visual Studio 2008 to be able to use its designer.
Steven
2010-08-02 10:30:38
@Jon, correct but very hypothetical. If I can't use VS2010 for something, I won't use EF. @Steven: That is one of the 'similar' frameworks. The list is longer.
Henk Holterman
2010-08-02 10:52:08
why does using a version of EF have dependency on VS version? Isn't it a bad idea?
thewpfguy
2010-08-02 11:13:10
@Henk, Can you pls elaborate on this "If I can't use VS2010 for something, I won't use EF."
thewpfguy
2010-08-02 11:14:06
EF4 requires dotNet4 and dotNet4 requires VS2010. The first version of EF left a lot to be desired. If you're limited to VS2008 I would recommend L2S or nHibernate. But that is subjective.
Henk Holterman
2010-08-02 11:19:28
A:
Writing the queries yourself still beats any automatic process performance-wise. Entity framework makes the data layer more abstract, which improves portability and readability.
deltreme
2010-08-02 10:20:19
+4
A:
The SqlDataReader and the Entity Framework are two completely different approaches to access your data. With SqlCommands, you yourself write the SQL queries. With an O/R mapping technology such as the Entity Framework, the relational database structure is mapped to objects whose properties you access, e.g. Linq to Entities. Note that the O/R mapping approach is not about speed.
Marius Schulz
2010-08-02 10:22:21
+3
A:
If you are in VS 2005. I think you can't use Entity FrameWork. For that you required 2008 and .NET 3.5 SP1. Entity Framework has some issues. If you are going with Entity Framework; go with Visual Studio 2010 and .NET 4.0. This will be a better option.
Latest update from Scott Gu
anishmarokey
2010-08-02 10:26:04
A:
The performance of Entity Framework isn't great compared to other O/RM tools (such as LINQ to SQL), but things have improved a lot with .NET 4.0. However, nobody here can tell you whether Entity Framework is fast enough for what you need. You will have to test this yourself.
Steven
2010-08-02 10:33:25
+2
A:
I'd recommend to write up your requirements, then identify the options, evaluate each option with some tests that are meaningful for your requirements (e.g. ease of use, speed, etc.), and finally decide. With some smart design and implementation choices you might even be able to switch between some of them with relatively limited effort at least at the beginning.
The Entity Framework is certainly an option. I'd recommend to also include NHibernate and in particular fluent-nhibernate in your investigation. Good luck!
John
2010-08-02 10:49:59
I have to agree - there is a lot to commend EF and NHibernate and various other options but every single option is a compromise, as soon as you use an ORM or any other technology between the client code and the database you are going to start to add overhead (i.e. loss of performance) *however* in the real world the loss of performance is more often than not insignificant and the benefits to the developer considerable. You need to decide what you want to do first (i.e. do you want to change your db access philosophy) and then look at your options.
Murph
2010-08-02 10:54:48