si ormai parlare di modalità connessa e disconnessa è superato, ehehe 
se ci penso mi fa ridere come tutte le volte, nella storia della programmazione, ci siano sempre stati nuovi mostri da combattere.
più che altro il concetto rimane solo uno, se si fa una query a database, si vuole che quest'ultima venga eseguita e liberata nel minor tempo possibile, per dare la possibilità ad altre query concorrenti di sfruttare le risorse del server, senza che quest'ultimo sia tempestato di connessioni aperte a fare niente, cosa che poteva succedere con un approccio "connesso", per cui mentre si scorreva il resultset connesso ci si preoccupava anche di creare l'eventuale html (per il buon classic asp), o popolare dati in una form, ma questo porta tanti svantaggi, stai tenendo in piedi una connessione, continui a scaricare dati dallo stream aperto verso sql, e il tutto per il tempo di elaborazione di altre cose non legate all'accesso ai dati (creazione html / elementi form), quindi ora non si ragiona più in quel modo (a dire la verità è sempre stato possibile evitare quelle cose anche in linguaggi non OOP), ma semplicemente ad entità, ed è qui che l'OOP ci viene estremamente in aiuto, potendo rappresentare tutto il nostro modello database, in un modello quasi identico, anzi più potente perchè rappresentato da un grafo di classi, che può essere "navigato".
in poche parole potrai avere cose tipo:
public class User
{
public int UserId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string Username { get; set; }
public string Password { get; set; }
public string Address { get; set; }
// proprietà di navigazione che di fatto in SQL sarebbe rappresentata con una JOIN
public List<Post> Posts { get; set; }
}
che esprime un entità utente, con le sue proprietà, questo rappresenterà poi probabilmente una tabella simile a database.
Per fare l'accesso ai dati, attualmente ci sono davvero tante possibilità e strumenti, tra l'altro quasi tutti open-source, compreso quelli della microsoft! Ad esempio abbiamo Entity Framework della microsoft, che è un ORM (object-relational mapper) per accedere a database relazionali, oppure ugualmente anche NHibernate anch'esso open-source. Alla base di questi framework c'è sempre il buon vecchio ADO.NET, che è l'evoluzione di ADO che conoscerai... L'evoluzione dei RecordSet, sono i DataSet con i loro DataTable (ma ti prego non usarli)... i DataSet nascevano dall'esigenza di dare un qualcosa che fosse simile ai recordset per non fare sbroccare che veniva dalla vecchia programmazione, sono anche molto più potenti e possono gestire anche insert,update e delete, ma... ma non usarli, anche perchè di fatto vanno un po' contro alla pura OOP, perchè rappresentano entità diverse con la stessa classe, appunto il DataSet, che può contenere tante tabelle DataTable, utilizzando quegli oggetti si finisce per programmare con un sacco di stringhe schiantate per accedere alle colonne, non sapendo mai di che diavolo di tipo è una colonna, e sopratutto non sapere che proprietà ha una entità... invece è meglio sviluppare partendo da semplicissime classi di modello, anche chiamate POCO (Plain Old CLR Object), che è un acronimo inglese, ma in italiano rende abbastanza l'idea , infatti sono classi povere di codice, definiscono semplicemente l'entità, definendo solo le proprietà senza nessun comportamento (quindi NO metodi con codice).
un esempio di classe poco è quella che ti ho postato sopra, che puoi sfruttare per ritornare i dati dopo un accesso a database, capisci bene che avere una collezione fortemente tipizzata di User, è estremamente più comodo da utilizzare a codice, perchè invece che avere roba del tipo "dataRow["FirstName"]" di cui devi sapere l'esatta stringa del nome colonna e di cui non sai il tipo dato a priori, avere una cosa così invece è molto meglio "user.FirstName", che è compilato, non puoi sbagliare niente, perchè te lo direbbe subito in fase di compilazione.
io ti consiglio di vedere un po' ADO.NET, e poi di passare a Entity Framework 6 (EF).
per quanto riguarda ADO.NET trovi un sacco di roba cercando su google "tutorial ado.net", come questa: http://www.csharp-station.com/Tutorial/AdoDotNet
in molti esempi però fanno vedere l'uso di DataSet, per vederli male non fa, ma per me fanno più male che altro, cerca guide che ti mostrino semplicemente come funziona il SqlDataReader e il SqlCommand, che sono i due oggetti più importanti, dopo ovviamente SqlConnection 
...si il SqlDataReader è l'oggetto per l'accesso ai dati "connesso", ma se carichi un oggetto come ti dicevo, e poi chiudi subito la connessione, di fatto hai implementato un metodo di accesso ai dati "sconnesso" dal momento che poi utilizzerai la tua collezione di oggetti nel resto della tua applicazione e non direttamente il sqldatareader, per questo non mi piacciono tanto le guide che si trovano in giro, perchè fanno la differenza obsoleta, di dire che sqldatareader è "connesso" e il dataset è "sconnesso", e via tutti a usare i dataset, queste affermazioni portano a fare scelte sbagliate, si il SqlDataReader è connesso, e si il DataSet è sconnesso, ma puoi usare il SqlDataReader e lavorare comunque sconnesso, basta caricare un oggetto e staccarsi nel più breve tempo possibile dal sqldatareader, e stai sicuro che caricare una tua misera classe POCO, sarà per forza di cose più veloce che caricare un dataset, perchè entrambi alla fine usano comunque un SqlDataReader, ma con la differenza che il DataSet ha migliaia di righe di codice di comportamenti che la tua piccola classe POCO non ha... io ci vedo solo vantaggi nell'usare una bella modellazione a classi in vero stile OOP
mentre per quanto riguarda entity framework (EF), qui trovi un sacco di info: http://msdn.microsoft.com/it-IT/data/ee712907
e qui trovi un bellissimo tutorial per creare un sito MVC 5 e EF 6: http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
suggerimento con EF: approccia con uno stile Code-First piuttosto che Model-First, in pratica usando codice invece che il designer, è molto importante, perchè hai molto più controllo su quello che fai, e capisci anche molto meglio come funziona una modellazione in c# OOP, non per niente al sql saturday a Parma che ci sarà il 22 novembre terrò proprio una sessione su EF 6 Code-First:
http://www.sqlsaturday.com/viewsession.aspx?sat=355&sessionid=25373
puoi ancora iscriverti se vuoi: http://www.sqlsaturday.com/355/register.aspx
Magari prova un po' a fare qualcosa e poi incomincia ad aprire thread sul forum con richieste specifiche, su vuoi qualche esempio diretto, prova ad aprire un thread mirato "Esempi accesso ai dati con ADO.NET" / "Esempi accesso ai dati con Entity Framework (Code-First) ", in tanti hanno avuto la tua stessa esigenza, quindi qualche link utile arriverà
Michael Denny | Visual C# MVP
http://blogs.dotnethell.it/Regulator/
http://dennymichael.wordpress.com
http://mvp.microsoft.com/mvp/Michael%20Denny-5000735
Twitter: @dennymic