First I need to state that ADO.Net is a very good component. It does an excellent job of what it was designed to do. ADO.Net provides an object based representation of a database.

Some the excellent features ADO.Net are:

• DataTables: Provide a memory representation of a database table (or combination of tables). This allows software to directly read and write to the database data. The ADO automatically takes care of concurrency issues.
  
• DataSets: Provide a memory representation of a number of data table and the relationships between the tables. With DataSets the database schema can be represented in an object format.
  
• XML tools: Provides ability to both input and output XML representations of data to and from data sets and data tables.
  
• Serialization: Data sets can be serialized allowing database data to be available via a web service or remote service. This allows for rich clients to have direct access to the database.
  

There is an issue with ADO.Net and Data Sets (summarized in this discussion on wikipedia), but that is not bad part.

The bad part is that ADO.Net falls short of the requirements to properly support Object-Oriented design (OOD). While doing an excellent job of providing an object oriented view of a SQL database, a SQL database itself is not very object oriented. That is ADO.Net provides objects that map one to one to the features of database. In the absence of any other components what typically happens is that ADO.Net is used directly with application code. Even with careful planning it can still result in these bad design practices:

• OOD tenant of encapsulation is violated. What occurs when ADO is used is that many of the SQL database issues are not encapsulated, but brought into the application code.
  
• Complex objects and especially object composition are not used. Databases only support the storage of built-in types. The result is that the application objects that deal with the database data tend not to use software structures such as queues, FIFOs, collections, and references (object composition). Instead application objects use the built-in types almost exclusively and use the database foreign key structures directly, instead of references. In fact the code is likely not to be object oriented at all.
  
• There is significant code that needs to be created that is dedicated to ADO configuration, setting up data tables/data sets, reading and writing to database, etc. This isn't bad code; the bad part is that it needs to be written, tested, deployed and maintained.
  

This results in really ugly application code. This ugly code has a number of nasty features:

• Software and the database must be changed at same time. Typically changing the database schema requires changing the application software. Adding new features requires not only adding the new objects, but insuring the database is also changed.
  
• The issue of versioning the database schema and software needs to be accommodated. For example when new features require database changes there needs to be a deployment process where the existing databases are upgraded. Alternately the software needs to handle both the old and new database schema.
  
• The application code becomes larger than it needs to be in order to handle that lack of true objects in a database. Bugs become harder to fix. New features become more difficult to add. The code just becomes harder to understand because of its size, lack of encapsulation and use of structured programming
  instead of object programmer techniques.
  
  

This begs the question, how should you employ OOD and still use a database? One answer is to use an object-relational mapping technique such as is provided by Hibernate or product such as DB4O that makes a standard SQL database look like an object oriented database. These are good, but have their draw backs. Fortunately there will shortly be solution from Microsoft that extends ADO.Net called ADO.Net Entity Framework. It may not solve all the "ugly code" issues and will certainly have some drawbacks, but is very promising. We are excited by it.

The ADO.Net Entity Framework is a very attractive solution since it is not only provides an object-relational mapping service, but will provide Query support using LINQ as well as integrating tightly with Visual Studio. This is great, but in my opinion the biggest advantage of the Entity Framework is that it allows new, and even ongoing, software projects to use OOD while using existing databases, existing database tools and practices. In other words the substantial investment in databases can be protected, while building OOD software to exploit it.