1

Several teams I've been on (and no I don't recall all that we were doing, it's been a while) used IDataReader instead of SqlDataReader when coding the Data Layer CRUD methods.

Can someone tell me why our architects preferred IDataReader always?

PositiveGuy
  • 46,620
  • 110
  • 305
  • 471

3 Answers3

5

The reason has to do with coding to an interface: if you code to IDataReader, you have better assurance that you can switch to a different brand of RDBMS later, should there be a need to do so. If you code to SqlDataReader, on the other hand, your code may still be easy to port to use with, say, Oracle, but you would have less confidence of that (and you will have to do the porting, too).

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • `DbDataReader` already provides this abstraction in ADO.NET, so this might not heve been the main advantage of using the interface. (OF course it's impossible to tell what the actual motivation of someone else was.) – millimoose Oct 21 '12 at 21:33
  • most likely 90% of the time if you're Microsoft based, you're not gonna move to something like Oracle, or some other database... – PositiveGuy Oct 22 '12 at 00:08
4

IDataReader is abstraction, not enforcing any concrete types but rather contract (ie. perform CRUD operations). For the purpose of extendability and testability programming to interface is preferred.

Having dependencies represented by interfaces allows you to change them much more easily, be it in unit tests (when providing mock objects instead of real implementations) or non-production environments (like working with different implementations).

For additional research, I suggest giving a look at dependency injection and other concepts related to SOLID principles.

Why would you want to change data layer or replace database altogether?

That's ridiculous. Chances that you'll need to change entire data layer are relatively low (as this is rather large cost), but there are fairly good chances you'll need to support additional ones. Consider following scenario:

  • Clients want piece of software running running on Oracle boxes because that's what they have and they don't want any extra databases running on the servers. Being pragmatic, you never expose Oracle bits past DAL, but keep it clean and program to interfaces.
  • Project turns out to be good enough to attract another client. However, he isn't as wealthy and is running MySQL boxes - entire DAL has to now work on MySQL and it turns out it isn't particularly hard implementation-wise (leaving Oracle-MySQL differences aside). Majority of codebase is reused.
  • Finally, as a part of some loadbalancing work, Oracle client decides they want to delegate some computing to different boxes all working in master-slave mode (master being original software, tweaked to master-slave mode). Slaves were essentially small versions of the master running on old and slow machines. They have to use SQLite as data storage.

So there you go. This actually happened to a project I've been working on, and in the span of less than 10 months it all went from Oracle is all we need to Oracle, MySQL and SQLite. Sure, those transitions always required some extra work (primarily due to DB differences) but majority of DAL code was reused. Wouldn't that be possible if our DAL was tightly coupled to Oracle? I'm sure it would, but I'm just as sure it would take a lot more time and effort.

Lesson learned - always plan for success.

Community
  • 1
  • 1
k.m
  • 30,794
  • 10
  • 62
  • 86
  • Yea I know DI, but never really needed it in the DL. – PositiveGuy Oct 22 '12 at 00:06
  • You don't really explain why you'd want to do this in the DL...I get testing but how..test it how, like how would your unit test look and what are you testing exactly? – PositiveGuy Oct 22 '12 at 00:07
  • @CoffeeAddict: you usually don't unit test DAL. However, **if** you do some testing that replaces regular database with memory one this will help. Having flexible DAL won't hurt for sure - see my updated answer. – k.m Oct 22 '12 at 21:49
2

I think that the The IDataReader is an interface. that implements and handles many classes that handle database acces while if you use SqlDataReader is an implemented class that actually uses the IDataReader interface but instead of being limited to a class IDataReader allows you to implement and easily change the database provider if you decide to do so in the future therefore you can avoid rewriting references if you want to switch database engines

COLD TOLD
  • 13,513
  • 3
  • 35
  • 52