Entity framework or just plain old SqlDataReader?

[Andy B.]

I need to determine if I need to be using just plain old SqlDataReader or
use entity framework before I get too far deep into my project and have to
change around a lot of code. Can someone help with this in general terms?
This is the overall concerns that need to be looked at when deciding either
one or the other.

1. Excessive overhead needs to be kept to as much of a minimum as possible.
Even though database usage from the web application is very small right now,
it will grow and could have years worth of gathered data.
2. In reference to #1 above, whatever I use for data access objects must be
as fast and as clean as possible.
3. It must be easy to understand and code writing must be as effortless and
as limitless as possible.. There limitations on the entity framework that I
had blocking my way. I had to write 1 stored procedure just to get around
it.
4. I am on a deadline with this project and whatever I use must be able to
let me move on to other things in a reasonable amount of time.

If there is more that needs to be said before anybody can advise, let me
know.

 

[sloan]

I haven't taken the "Entity Framework" plunge yet.
And not sure if I will for my current project.

If you want the "leanest", than I think sticking with the IDataReader is
still a viable solution.
"Fast and clean" is probably leans toward IDataReader as well.

The place where you pay a price for an IDataReader solution is probably
maintainability.
You pay a higher cost to edit the code which takes values from the
IDataReader and push them into an object.



I have a few samples:
If you write interfaces and concretes, then try this: ("public interface
IEmployee" and "public class Employee : IEmployee")
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry
(You can ignore the WCF part, and just look at the datalayer and the
..Controllers folder in the business layer.

If you write only concretes you can check out:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
Note, I now use
public class EmployeeCollection : List<Employee>
instead of placing List<Employee> all over the place (like the demo code
has)


One thing to pay attention to is the "Layout" definitions in the Data layer.
This idea was given to me via a former colleague.
Basically, I create a bunch of static int variables that match the Ordinal
of the IDataReader columns.
This provides 3 things.
1. Readability. Instead of mydatareader.GetString (0) ... I have
mydatareader.GetString( EmployeeLayout.EmployeeID )
2. Maintainability. The "layout" is defined within the datalayer, thus if
the stored procedure changes, I change(maintain) the layout in the data
layer, which makes sense to me.
3. Slight performance increase. The concrete SqlDataReader has a
..GetString("EmployeeID"), but behind the scenes it has to do a lookup to
find the ordinal. I avoid this lookup by using the ordinal number
(Layout.EmployeeID) instead of the column name ("EmployeeID"). It also
keeps my code written against the Interface (IDataReader) instead of the
concrete SqlDataReader, so my code is somewhat "future rdbms proof". Odds
are very low I wouldn't be using Sql Server, but in case some group buys out
our company and some CEO is like "We ONLY use Oracle", the code is somewhat
ready.


Also check
http://sholliday.spaces.live.com/feed.rss
If you're supporting multiple RDBMS's, there is a way to code it up to
handle that as well.
(Its one of the links there)



PS, Why are you posting the same thread multiple times? I see the same
question posted at 9:21AM and then 11:57AM today.

 

[Andy B.]

Ok. Newsgroup servers must be lagged behind where I am then. I posted my
original post on this at 3am and it didn't show up until 9:51am. That's not
normal usually. Didn't get this post until after I posted a reply asking for
a repost so ignore that.

So the basic idea is that the SqlDataReader is faster and a little more
reliable except for a few maintainence issues?

 

[sloan]

That's my take, but I'm not a EntityFramework expert.


But to me, the IDataReader will always be the "most close you can get"
without implementing your own database access provider.


I also heard in a conference that "Microsoft changes their database access
technology every 2.64 years" (<< I think Rocky of CSLA was the source).
DAO,RDO,ADO,ADO.NET.

Hopefully the IDataReader will be around for a while and not all into
archaic land.


PS
Code to an interface, not to an implementation.
http://www.google.com/search?hl=en&...e+not+an+implementation&aq=1&oq=code+to+an+in