11

This StackOverflow question asks "where can I get Microsoft.Data.Objects"

It turns out the answer was probably that its in the CTP4 (code first) release of Entity Framework 4 However there where a lot of guesses. Including

  • System.Data
  • Entity Framework
  • Microsoft.ApplicationBlocks.Data
  • Microsoft.Practices.EnterpriseLibrary.Data

10 years ago if someone asked a similar question for they might have gotten DAO, RDO, ADO.

Is this just the nature of the beast or is it MS.

Does this pattern happen with other vendors? Where the base data access strategy is either wrapped or changed?

Community
  • 1
Conrad Frix
  • 4,155
  • 2
  • 18
  • 34

4 Answers4

11

It's a combination of Historical/Evolutionary and Market force reasons

While working at Microsoft some years ago, it was clear that there was several different data offerings in development. Each of the offerings were aimed at a particular market or use case, e.g.:

  1. Access was aimed at desktop users comfortable with card indexing systems who could build up applications using the forms and reports. SQL was a natural addition. This all used its' own local-machine database engine named 'JET'. Eventually JET was sidelined - the word on the grape vine was that lack of (reliable) source control meant they'd lost a large chunk of the source.

  2. FoxPro was aimed at desktop users who wanted speed over relational data.

  3. SQL Server was the Enterprise/Server-side 'big' database system with all the scale/power/availability, etc that enterprises need. IIRC, MS licensed a version of Sybase 6 upon which to build MSSQL.

Over time, some of the boundaries have become blurred - e.g. SQL Server can run on a desktop machine now, but the use case remained.

So this gives us 3 'back ends' - database products produced by Microsoft.

To add to the mix, there was then different levels of developer API provided to gain access to these systems:

  1. Initially, there wasn't much in the way of APIs - you wrote your code inside the application (FoxPro/Access). VBA was one method.

  2. Microsoft implemented MS ODBC in order to connect to competing systems so that Windows could talk to big databases like Oracle, Sybase, etc. Excel was one of the notable apps to get ODBC tools - pull data from your big DB, manipulate it and product charts/graphs, etc. Many database vendors ended up implementing ODBC to allow disparate clients to connect, so this strategy was successful.. to a degree - ODBC could be considered as representing the lowest common denominator.

  3. Different teams started to produce their own ways to access a database engine like DAO (Data Access Objects) for local and RDO (Remote Data Objects) for remote, accessible through VB, which was the most popular MS developer product at the time.

  4. An internal effort to rationalize these diverse APIs and provide a single/unified highly flexible database access API gave us OLEDB, but it was very very hard to get into (lots of C++ templates).

  5. OLEDB couldn't be used from VB, so ADO was developed using ActiveX techniques, so it became re-usable by anything that could do COM/OLE/ActiveX, meaning Access, Excel, VB and hence ASP became database-enabled.

  6. As we moved into the .NET era, ADO was naturally moved into a .NET environment which brought various benefits.

  7. With the advent of LINQ, the actual database access mechanism became less of an issue.

Caveat - I left some time ago now, so my memory is a little fuzzy

JBRWilkinson
  • 6,759
  • 29
  • 36
  • +1 Nice explanation of the DAO, RDO, ADO part, but the question remains, why did the pattern repeat? – Conrad Frix Feb 18 '11 at 17:14
  • I always thought it was different MS departments coming up with their own (NIH) technologies. There's certainly a huge number of them -and you forgot LINQ2SQL, since replaced by EF! – gbjbaanb Apr 21 '11 at 14:46
5

To be fair all of the ones you mention are built on top of ADO.NET. Before that ADO was the favored route for a while but DAO just sort of hang around because it was native for Microsoft Access Databases. RDO was dead on arrival from what I can tell.

With all the different frameworks you mention I think the problem is that they are trying to give a solution for everybody and to compete with every other platform. If you want a simple way to just use SQL in your code then go for System.Data. If you want an ORM using Entity Framework. For something in between then use Enterprise Library Data. Everyone wants something different.

There is also the issue that MS is a very big company with different teams with different agendas. For example why do they also have 3 word processors (that I know of).

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Craig
  • 4,302
  • 3
  • 21
  • 21
  • this. There is no single one that suits everybody so they try to keep all options open. – stijn Oct 29 '10 at 10:48
2

Personally I think it is more of a result of the influence of marketing within Microsoft. By all rights, most of these technologies could easily be just released as version upgrades of the older versions, but there seems to be a big need to put on this image of continually reinventing even something as basic as a data access layer.

JohnFx
  • 19,052
  • 8
  • 65
  • 112
0

This is the very nature of IT! Things CHANGE! In the Java world, they had the same thing... JDBC, EJB 1.0, EJB 2.0, Hibernate, EJB 3.0 and so on.

LeWoody
  • 252
  • 2
  • 11
  • 1
    I'm not a Java expert but Hibernate is not from Sun so its not the comparison I was looking for. EJB seems to be more about SOA then data access, which is more of a software stack. Software stacks I get. Several different ways to do the same thing without integration seems like a see what sticks approach. – Conrad Frix Dec 15 '10 at 20:00