Objets C# et opérations sur les données

Bonjour,
je me demandais quelle était la meilleure façon d'effectuer des opérations sur la base de données SqlServer avec des objets C#.
Par exemple, si j'ai une classe utilisateur avec plusieurs attributs(nom, adresse etc...), quel est le meilleur moyen d'insérer, supprimer, modifier et récupérer ces informations.
J'ai pensé à créer des fonctions à l'intérieur de la classe, celle ci utilisant system.data.SqlClient, afin d'effectuer les différentes transactions sur la base, par exemple une fonction ModifierNom(string nom) dans laquelle il y a la requête "UPDATE".
Serait-il préférable de faire ces traitements en dehors de la classe?
Vos conseils me seront d'une grande utilité, merci pour votre aide.

Salut,
Il serait plus judicieux d'utiliser un ORM qui fer tout ca tout seul.
Comme NHibernate ou EntityFramework.
D'autres personnes pourront te donner bien plus d'infos que moi qui n'y ai que très très peu touché.

l'utilisation d'un ORM est effectivement un choix potentiellement judicieux en ce qui te concerne.
je précise potentiellement, car après tout dépend des volumétries dont on parle, mais dans la majorité des cas, utiliser un ORM générera tout le code dont tu as besoin, et s'occupera de tout ce qui est mapping Relationnel-Objet, car c'est sa raison d'être :)

Entity Framework n'est apparût qu'à partir du Service Pack 1 de dotnet 3.5... donc si tu dois développer sur une plateforme antérieure, il est indispensable d'exploiter NHibernate.

Si tu développe sur dotnet 4... tu peux choisir en fonction de tes besoins l'un ou l'autre.
Si ton projet et le mapping qui va avec est sauvage/très complexe, il vaut mieux employer NHibernate, si tes besoins ne sont pas particulièrement horribles, question mapping, Entity Framework a l'intérêt d'être entièrement intégré à Visual Studio 2008 SP1 (+.NET3.5SP1) ou Visual Studio 2010.

Effectivement en lisant les lignes précédentes, tu va te dire que EF est moins performant ou complet. Il est très performant, mais moins flexible et complet que NHibernate, car à l'inverse de NHibernate, c'est un ORM récent qui pêche encore par sa grande jeunesse.
Tout est question de besoin et de choix.
Comme je disais, EF est totalement intégré à Visual Studio et est capable (pour peu qu'on installe les extensions VS nécessaires) de gérer des entités POCO (Plain Old CLR Object) qui ignore leur persistance dans la base.

EF te permet de créer ton modèle de données objet graphiquement et visuellement, soit à partir d'une base de donnée existante, soit en créant la base depuis le modèle.
NHibernate nécessite, lui, que tu décrive via des XML, les relations et mapping entre les deux mondes, bien que cela ne soit pas très compliqué, cela peut quand même demeurer assez long, mais en contrepartie, il est plus souple et flexible que EF, de même tu devras écrire tes classe POCO toi même.

EF est décrit sur les docs MSDN de .NET, NHibernate est un projet open-source, pour lequel on trouve pléthore de tutoriels sur le net.

Maintenant d'un point de vue purement conceptuel, je vais répondre à ta question initiale.
En général, lorsque l'on découpe son application en couches pour séparer les responsabilités, (et potentiellement permettre de transformer les couches en tiers)
on a tendance à avoir :

BOL (Business Object Layer) : Objets métiers, avec règles métiers de bases, mais aucune logique particulière, pas de persistance.
DAL (Data Access Layer) : Ici c'est un peu la boîte à outil d'accès aux données, et on y trouve la collections de classes qui gère l'accès aux données. Avec un ORM cette partie est intégralement prise en charge par l'ORM.
BLL (Business Logic Layer) : Généralement on a ici toute la logique métier. C'est typiquement ici que ce situe la logique de persistance et les règles métiers spécifiques de persistance des données, les contrôles, les différents process qui influent sur N entités différentes. Tous les traitements complexes, qui ne dépendent pas forcément que des données du modèle de base.

L'intérêt d'avoir une couche métier (BOL) totalement séparée de toute forme de logique complexe, et notamment libérée de toute gestion de la persistance, c'est que cette couche peut alors traiter uniquement de ce dont elle est sensé traiter, le métier.
On va y trouver les différentes opérations atomiques métiers sur chaque entités.
De même il sera alors possible, sans violer les règles de séparations et les best practices, et en minimisant les développements, de les exposer tels quels sur le réseau, via des services WCF.

Ainsi c'est ta couche logique, la BLL, qui finalement va gérer un peu les différents états de persistance des données, savoir s'il faut ou non les ajouter, les fusionner selon les processus métiers engagés ... et ensuite appeler les classes ou méthodes qui vont bien au niveau de la couche d'accès, la DAL. C'est typiquement cette couche, qui seule va avoir accès aux objets de contextes chargés de la persistance... ces objets représentant la DAL.

Bien entendu sur de petits projets, on peut simplifier, et rassembler BLL et BOL, en utilisant des entités non POCO et en exposant allègrement les objets de contextes.
Dans l'absolu tout est possible, mais alors tu prend des risques, et augmente la possibilité d'effets de bords, bugs, problème de responsabilités.
Cela implique également que tu diminue la possibilité de faire des tests unitaires ou la possibilité de programmer par contrat, afin de minimiser les bugs, et mieux les isoler dans le cas où il en reste.

Il existe aussi SubSonic qui fait un travail tout à fait décent en tant qu'ORM

ORM est le mot qui règne en tout cas :).
Tout ça me semble bien ardu, mais on ne peut rien y faire, c'est dans la logique de ce que je veux réaliser.
Je pense que je vais me pencher sur le sujet de NHibernate vu l'abondance de la documentation et la flexibilité du framework.
En tout cas merci beaucoup pour vos réponses, ça m'a bien aidé.