Discussion :

[rv26t]

Bonjour,

Cette discussion est destinée à recueillir vos commentaires sur l'article « Architecture de couche d'accès aux données (DAL) de hautes performances — Partie 1 » et des Data Transfer Object (DTO).
Traduction de l'article « High Performance Data Access Layer Architecture Part 1 » de M. Rudy Lacovara.

DTO, DAL, BLL… Tout le monde s'en sort ? Pas si sûr !
Voici le premier chapitre d'un article qui vous aidera à comprendre cette architecture et ses concepts-clés.
Dans cette première partie, nous allons nous intéresser à l'architecture globale de la DAL et l'utilisation des DTO pour transférer des données entre les différentes couches de l'application.
Nous allons aussi voir la mise en pratique de ces concepts à l'aide d'une classe PersonDB qui contiendra l'ensemble de nos méthodes d'accès aux données permettant d'obtenir et de sauvegarder les données d'une entité « personne ».

Cette série de trois articles décrit comment écrire une couche d'accès aux données de hautes performances.
Lien sur les discussions des autres articles : Discussion sur la partie 2, Discussion sur la partie 3.

Bonne lecture.

[Immobilis]

Salut,

Intéressant mais les références citées sont un peu anciennes (2008 et 2009). Outre l'architecture tu aurais pu refaire des tests avec les derniers Framework, non?

Personnellement, compte tenu de la lourdeur de la maintenance d'une telle architecture, en dehors d'une course à la microseconde, il y a peu de chance que je revienne à cette façon de faire.

A+

[Kropernic]

Lourdeur de maintenance ???

C'est l'architecture que j'utilise pour chacun de mes projets et, mise à part la factory où, selon l'exemple de l'article, les noms des objets sont hard codés, la maintenance n'est pas lourde du tout.

Tout est justement très clair je trouve. Tout ce qui concerne l'accès au données se trouve dans la DAL. Tout ce qui concerne les contraintes métiers (validation, traitement, etc.) se trouve dans la BLL. Et elle communique entre elles via les DTO. Rien de plus simple.

C'est propre et rigoureux. Et puisque c'est ainsi, la maintenance est donc très simple (A partir du moment où l'on comprend bien où chaque chose doit se mettre. C'est vrai qu'au tout début, j'avais un peu de mal).

Bien sûr, comme tout pattern (ce n'est p-e pas le bon mot mais tant pis), ce n'est qu'un guide de base. Libre à chacun de l'adapter suivant ses besoins. Par exemple, et je sais que ça va faire hurler certains, j'ai adapté tous mes DTO en leur ajoutant une méthode ToString.
Certains diront qu'alors ce n'est plus un DTO et que je sors de cette architecture mais qu'importe. C'est mon besoin d'avoir cette méthode.

Quant au pourquoi j'utilise cette architecture, c'est simplement car je suis un paranoïaque du contrôle de mon code. J'aime avoir le contrôle "absolu" sur la moindre chose que je fais. Je n'ai encore jamais utilisé d'ORM mais d'après tous les articles que j'ai pu lire à leur sujet (et ça en fait quelques uns), c'est l'ORM qui s'occupe de faire la requête SQL pour récupérer les objets. Comment puis-je alors m'assurer que cette requête est correctement écrite (de manière optimale afin d'utiliser les bons indexes) et qu'elle me retournera bien ce que j'ai besoin et uniquement ce que j'ai besoin ?

My 50 cents...

[Immobilis]

Lourdeur de maintenance ???

Ben oui, L'ajout d'un champ implique une intervention dans le code que je trouve très lourde et génératrice de bug. Mais bon comme tout c'est un choix.

J'aime avoir le contrôle "absolu" sur la moindre chose que je fais.

C'est une illusion dans la mesure où tu utilises déjà un Framework qui fait 99,99% du boulot. A moins de coder en langage machine tu ne contrôles pas tout.

Je n'ai encore jamais utilisé d'ORM

Ceci explique peut-être cela

A+

[Kropernic]

Ben oui, L'ajout d'un champimplique une intervention dans le code que je trouve très lourde et génératrice de bug. Mais bon comme tout c'est un choix.

J'imagine que par champ, tu veux dire une colonne dans une table de la DB. Tout ce qu'il y a à faire, c'est d'ajouter la propriété dans le DTO et de gérer son assignation dans le parser... Pour le reste, il n'y a pas plus de travail qu'avec un ORM.

C'est une illusion dans la mesure où tu utilises déjà un Framework qui fait 99,99% du boulot. A moins de coder en langage machine tu ne contrôles pas tout.

Dans le genre argument en carton... Une petite comparaison (caricature). Je souhaite construire une maison mais je veux le faire moi-même car je veux être sûr d'avoir exactement ce que je veux. Je vais donc acheter des briques (et du ciment) et je me mets au boulot. Je ne fabrique pas les briques moi-même...

Pareil ici. J'utilise les briques du framework et je ne fais pas appel à un entrepreneur (ORM).

Ceci explique peut-être cela

Ce n'est pas parce que je n'en ai jamais utilisé pour un projet que je ne sais pas comment cela fonctionne. Ce ne sont pas les tutos et articles qui manquent à leur sujet. Et j'ai brièvement testé EF sur un projet trash (je ne sais plus quelle version c'était) avant de revenir à mes requêtes/procédures stockées écrites moi-même.

[rv26t]

Salut,

Intéressant mais les références citées sont un peu anciennes (2008 et 2009). Outre l'architecture tu aurais pu refaire des tests avec les derniers Framework, non?

En fait j'ai surtout été intéressé par la partie 3 (l'utilisation de DTO), et dans une moindre mesure la partie 1. Mais je ne pouvais pas seulement traduire juste une partie, j'ai fait la série.
Je n'utilise pas oracle donc difficile de refaire des test.
J'ai une bibliothéque DAL générique qui me sert pour mes nouvelles appli. J'y ai intégré les DTO, aspect qui m'intéressait (J'ai créé une bibliothéque DataTrnsfertObject). J'ai transformé la méthode GetSingleDTO pour justement ne plus avoir de paramètre de type command. Après, je fais de petit projet.

Comme l'indique Kropernic, on peut utiliser certaines idées ou principes selon les besoins.

Personnellement, compte tenu de la lourdeur de la maintenance d'une telle architecture, en dehors d'une course à la microseconde, il y a peu de chance que je revienne à cette façon de faire.

L'auteur indique bien dés le début que la solution proposé est seulement pour certain cas ou la performance est la priorité.

[rv26t]

... mise à part la factory où, selon l'exemple de l'article, les noms des objets sont hard codés, ...

Justement, j'ai fait une petite modif de ce coté. J'essayerais de faire un billet.
J'ai rendu la méthode générique (note : je ne parle pas des paramètres de la requête pour GetSingleDTO que je passe de façon particulière, ce n'est pas le but du sujet)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
''' <summary>DTOParserFactory : fabrique pour obtenir un objet analyseur (parser).</summary>
''' <remarks>Les méthodes sont déclarées en Shared.</remarks>
Public NotInheritable Class DTOParserFactory
 
    ''' <summary>Fabrique générique d'analyseur, (Parser) Cré une instance de classe concrête quelconque de type « DTOParser ».</summary>
    ''' <typeparam name="T">Un type de classe héritant de DTOParser abstraite.</typeparam>
    ''' <returns>Une instance de la classe DTOParser spécifique demandé par l'application utilisatrice.</returns>
    ''' <remarks>Méthode générique. Performance. Déclarée en Shared.</remarks>
    Public Shared Function FabriqueClasse(Of T As {New})() As T
        Return New T
    End Function

Et dans ma nouvelle méthode GetSingleDTO qui se présente ainsi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    ''' <summary>Lit une ligne de données renvoyé sous forme d'une instance de classe définie par l'appelant.</summary>
    ''' <typeparam name="T">Type de classe analyseur qui sera utilisé pour créer un DTO léger recevant les données.</typeparam>
    ''' <param name="Requete">La requête de sélection.</param>
    ''' <returns>Une instance de classe DTO léger d'un ensemble ligne de données.</returns>
    ''' <remarks>Méthode générique ne connaissant pas le type de classe analyseur en entrée. 
    ''' Une fabrique générique renvoie une instance de cette classe analyseur,
    ''' une méthode de cette instance retourne une instance DTO léger contenant l'ensemble d'une ligne de données.</remarks>
    Public Function GetSingleDTO(Of T As {New})(ByVal Requete As String) As DTOBase

Je fais un appel à la fabrique de cette façon (dans GetSingleDTO)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

parser = DTOParserFactory.FabriqueClasse(Of T)()

Pour un ensemble d'info (de DTO) j'ai donc une méthode qui renvoi une liste

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
    ''' <summary>Lit plusieurs lignes de données renvoyé sous forme d'une liste d'instance de classe définie par l'appelant.</summary>
    Public Function GetListDTO(Of T As {New})(ByVal Requete As String) As List(Of DTOBase)

Cela fonctionne très bien, mais il me reste un petit souci avec le parser que je dois déclarer de type object, je préférerais arriver à le typer.

Voilà, simplement pour dire que l'on peut, comme l'indique Kropernic, puiser des idées et adapter à ses besoins.
Les messages arrivent plus vite que mes réponses.

[Immobilis]

Tout ce qu'il y a à faire, c'est d'ajouter la propriété dans le DTO et de gérer son assignation dans le parser...

Je comprend bien sauf que dans cette phrase qui a l'air simple tu réalises des opérations lourdes (à mon avis): ajout de propriétés en cascade, des noms de colonnes en dur, des conditions, des initialisations. En fait ça me rappelle des méthodes que j'utilisais en 2006...
Sinon, tu as oublié la mise à jour du constructeur du DTO (alors que le Framework instancie lui-même les types "valeur"), de la méthode PersonDb.SavePerson pour lequel il faut aussi mettre à jour le paramètre. Tu vois, deux oublis, pas si simple.
Une autre raison pour laquelle je n'utilise plus ce système est que je ne vois plus où est l'avantage (le gain) à faire des méthodes du type GetMonObjectByXXXXXX(string). C'est bien plus pratique/fiable d'utiliser une expression lambda sur un repository qui va adapter la requête SQL.
De plus, le gain de temps de l'ordre de la milliseconde est négligeable par rapport au reste de l'exécution de la page. En proportion ok c'est deux fois plus peut-être mais cela reste insignifiant si tu ne fais pas de l'aéronautique.

Pareil ici. J'utilise les briques du framework et je ne fais pas appel à un entrepreneur (ORM).

Entity Framework fait parti du Framework .NET. Pour moi tu moules tes parpaings alors qu'on en trouve de très bons sur le marché. Le seul entrepreneur auquel tu fais appel c'est ADO .NET auquel tu délègues la récupération de tes données auprès de la base (le sable, l'eau, le ciment). L'assemblage, la création de l'objet, c'est toi qui le fais.

avant de revenir à mes requêtes/procédures stockées écrites moi-même.

L'utilisation de procédures stockées et d'un ORM est effectivement la meilleure solution.
A+

[Kropernic]

Je comprend bien sauf que dans cette phrase qui a l'air simple tu réalises des opérations lourdes (à mon avis): ajout de propriétés en cascade, des noms de colonnes en dur, des conditions, des initialisations.

Pourquoi ajout en cascade ? La propriété s'ajoute dans la DTO concerné et c'est tout non ?

Sinon, tu as oublié la mise à jour du constructeur du DTO (alors que le Framework instancie lui-même les types "valeur"), de la méthode PersonDb.SavePerson pour lequel il faut aussi mettre à jour le paramètre.

Effectivement, je n'ai pas parlé du constructeur. Suivant les cas, il ne faudra pas forcément le modifier.

Tu vois, deux oublis, pas si simple.
Une autre raison pour laquelle je n'utilise plus ce système est que je ne vois plus où est l'avantage (le gain) à faire des méthodes du type GetMonObjectByXXXXXX(string). C'est bien plus pratique/fiable d'utiliser une expression lambda sur un repository qui va adapter la requête SQL.

Là je suis bien obligé de reconnaître que expression lambda et repository, ça ne me parle pas... P-e que, à l'instar de Mr. Jourdain, je les utilise sans savoir que ça s'appelle comme ça (mais j'en doute). Je n'ai jamais eu aucune formation .NET. Me suis auto-formé sur le tas (ça commence à faire un gros tas maintenant XD).

De plus, le gain de temps de l'ordre de la milliseconde est négligeable par rapport au reste de l'exécution de la page. En proportion ok c'est deux fois plus peut-être mais cela reste insignifiant si tu ne fais pas de l'aéronautique.

Certes, ce n'est pas grand chose mais bon... J'ai des tendances perfectionniste qui ont déjà causées quelques débats houleux avec mon collègue d'ailleurs ^^. Mais au delà de ça, pourquoi faire moins bien quand on peut faire bien ?

Entity Framework fait parti du Framework .NET. Pour moi tu moules tes parpaings alors qu'on en trouve de très bons sur le marché. Le seul entrepreneur auquel tu fais appel c'est ADO .NET auquel tu délègues la récupération de tes données auprès de la base (le sable, l'eau, le ciment). L'assemblage, la création de l'objet, c'est toi qui le fais.

Je savais bien que j'aurais du m'abstenir de faire une comparaison (ça n'apporte jamais rien de bon ^^).

L'utilisation de procédures stockées et d'un ORM est effectivement la meilleure solution.

Mon prochain projet qui ne sera pas urgent, je retournerai voir du côté d'EF. Parce que, après tout, tu avances quand même de bons arguments et qu'il est vrai que je ne travaille pas pour la NASA.

Ca me fait penser que je suis curieux de voir comment un ORM résous des problèmes de référence circulaire. Typiquement, lorsque dans la DB on a une relation plusieurs à plusieurs entre 2 tables issues d'entité-type du MCD.
Ex :
Une marque peut être contenues dans plusieurs rayons et un rayon peut contenir plusieurs marques.
J'ai donc une classe Marque et une classe Rayon. D'instinct, je suis poussé à mettre une liste de Marque dans la Rayon et une liste de Rayon dans Marque. Mais lors d'un New, c'est le bordel XD.

[Immobilis]

Pourquoi ajout en cascade ? La propriété s'ajoute dans la DTO concerné et c'est tout non ?

Il y a aussi le parser dans lequel se trouve un champ privé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Class DTOParser_Person
      Inherits DTOParser
 
  Private Ord_PersonGuid As Integer

Là je suis bien obligé de reconnaître que expression lambda et repository, ça ne me parle pas... P-e que, à l'instar de Mr. Jourdain, je les utilise sans savoir que ça s'appelle comme ça

C'est très probable ça m'arrive souvent. Exemple de lambda:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public class Personne
{
    public int Id { get; set; }
    public string Email { get; set; }
}
protected void Page_Load(object sender, EventArgs e)
{
    IList<Personne> personnes = new List<Personne>();
    var personne1 = personnes.Where(x => x.Email == "user@domain.tld").FirstOrDefault();
    var personne2 = personnes.Where(x => x.Id == 1).FirstOrDefault();
}

Le Repository, pour moi, c'est juste une abstraction qui est l'équivalent de la DAL: http://msdn.microsoft.com/en-us/library/ff649690.aspx

Mais au delà de ça, pourquoi faire moins bien quand on peut faire bien ?

C'est toujours un compromis.

comment un ORM résous des problèmes de référence circulaire

J'aurais tendance à dire qu'il s'agit plus d'un problème de conception.

A+

[DotNetMatt]

Il ne faut pas non plus oublier un problème assez important vis à vis d'Entity Framework : le travail en équipe est un véritable calvaire !

D'après certains collègues quand on est en Code-First, il y a un peu moins de problèmes, mais si on est en Model-First ou en Database-First, c'est une perte de temps.

[Immobilis]

Il ne faut pas non plus oublier un problème assez important vis à vis d'Entity Framework : le travail en équipe est un véritable calvaire !

D'après certains collègues quand on est en Code-First, il y a un peu moins de problèmes, mais si on est en Model-First ou en Database-First, c'est une perte de temps.

Sans plus de détails c'est un peu léger comme commentaire. Ok il y a un fichier qui si il est en extraction l'est pour une seule personne. Après c'est une question d'organisation... Je l'ai déjà fait et on a pas été gênés. En code first tu peux créer plusieurs fichier partiels. En tous les cas ça ne remet pas en cause EF

[EDIT]Tu peux/dois aussi créer plusieurs contextes EF[/EDIT]

[DotNetMatt]

Effectivement je n'ai pas donné de détails, c'est un peu comme si j'avais dit "ça marche pas"

Personnellement j'ai eu deux mauvaises expériences :
- Sur une équipe de 3 personnes (dont je faisais partie) : il s'agissait d'une application visant à manipuler les données d'un CRM (nettoyage, validation, formattage, etc).

Chacun avait sa partie (en gros, un sur les fonctionnalités de nettoyage (dédoublonnage...), un sur la validation des données (vérification via un web service tiers...) et un sur la qualité des données (formatage, etc.)

Au début nous avions pensé à éclater en plusieurs contextes EF mais c'était plus compliqué à mettre en oeuvre. Nous avons donc dû se mettre en mode extraction exclusive, résultat du temps perdu car il fallait attendre qu'il soit libéré...

- Sur une équipe de 15 personnes (dont je faisais partie aussi, 10 à Paris et 5 en Inde) :

Projet visant à fournir une analyse de certaines données financières. Là encore, le modèle de données n'étant pas totalement figé pendant les développements (une autre équipe travaillait dessus) et le modèle objet étant relativement complexe, il était fréquent de toucher à l'EDMX.

Au début nous n'étions pas en mode exclusif pour les extractions, ce qui nous a valu la perte de certains morceaux de codes à cause de merges râtés. D'autant plus qu'on ne fait pas que merge du code, on merge aussi la position des objets dans la fenêtre de Visual Studio ... !

On est donc repassé en mode exclusif, ce qui nous a pas mal ralenti. Au bout de 2 mois, on a laissé tomber EF et on est repassés sur une DAL classique.

Cela dit je ne dénigre pas totalement EF. Sur certains projets perso, je l'utilise, mais je suis seul à coder. En tout cas, et ce n'est que mon humble avis, tant que ces points n'auront pas trouvé de solution, je ne compte plus proposer l'utilisation d'EF dans le cadre de projets en équipe.

[Immobilis]

D'après certains collègues quand on est en Code-First

Un tuto intéressant: http://reward.developpez.com/tutorie...he-code-first/

tant que ces points n'auront pas trouvé de solution, je ne compte plus proposer l'utilisation d'EF dans le cadre de projets en équipe.

Il faut que je vérifie, mais il est probable que ce soit réglé. Sous EF 5, grâce au modèle de génération, chaque entité est dans un fichier séparé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
foreach (var entity in typeMapper.GetItemsToGenerate<EntityType>(itemCollection))
{
    fileManager.StartNewFile(entity.Name + ".cs");
    BeginNamespace(code);
    // ... reste du code
}

Pour en modifier une il suffit d'éditer le fichier en question. Plus d'excuse

A+

[DotNetMatt]

Merci pour les ressources Immobilis J'ai tendance à partir en général sur l'approche Database first, ça ne me fera pas de mal de découvrir l'autre approche.

Effectivement ma dernière "mauvaise expérience" était en EF4 (même EF4.1 il me semble), et ça a peut-être bougé sur EF5/EF6. Je vais essayer de voir ce que ça donne.

[Kropernic]

Hello,

Je vais malheureusement continuer sur le HS :-/ (sorry Hervé ).

Intéressant le tuto sur EF-CF. Je l'utiliserai p-e pour un projet perso de petite envergure.

Mais pour mon taff, je pense en rester à ma pratique actuelle. Certes il s'agit d'un tuto de première approche et je comprends que tout n'y soit pas expliqué mais une DB, c'est bien plus que des tables avec des colonnes dont un ID comme clef primaire.

Déjà, d'après l'explication, EF-CF limite les clefs primaires de tables à être des ID (autoincrémenté ? ce n'est pas dit). Quid des clefs primaires composées ?

Mais il y a tout le reste !

Où sont les contraintes de domaine ? Les contraintes d'intégrité référentielles sont-elle bien mises en place ? Quid des triggers et des valeurs par défaut ? Dans l'exemple donné pour la classe EntiteHarley, deux colonnes sont nullable et deux ne le sont pas. Pourquoi/en fonction de quoi ? Si l'intégrité référentielle est mise en place, que se passe-t-il lors d'update/delete (rien/cascade/set null/set default) ?

Je pourrais continuer mais je crois que vous voyez où je veux en venir.

S'il faut quand même établir tout cela dans la DB, alors autant créer la DB moi-même. En plus, elle respectera mes conventions de nommage (qui ne sont pas les mêmes que pour mon code).

EF-CF propose-t-il des fonctionnalités pour réaliser/paramétrer tout cela ? Si c'est pour faire un bout d'un côté et un bout de l'autre, je préfère personnellement faire tout du même côté. Cela fera moins de risque d'oublier quelque chose et je serai sûr que ce sera bien fait (ma paranoïa refait surface).

[Immobilis]

Salut,

Quid des clefs primaires composées ?

Ce type de clef est plutôt une contrainte d'intégrité qu'une vrai clef (en général dangereusement basée sur un concept fonctionnel). Mais bon ce n'est pas le sujet du topic.

Je pourrais continuer mais je crois que vous voyez où je veux en venir.

Oui. Mais ton implémentation de DAL ne fait pas tout ça non plus.

EF-CF propose-t-il des fonctionnalités pour réaliser/paramétrer tout cela ?

Ce n'est pas le rôle d'un ORM. Un ORM ne remplace pas le travail d'un administrateur de base de données. Tu te trompes sur l'usage.

Tu sembles réfractaire... Cela m'arrive aussi. Je te suggère d'essayer

A+

[rv26t]

Je vais malheureusement continuer sur le HS :-/ (sorry Hervé ).

Pas de soucis, cela reste sur le thème de l'accés à la base de données.
Si cela permet d'avoir quelques éclaircissements ou quelques nouvelles idées. (ça fait parti du débat)

[Kropernic]

Salut,Ce type de clef est plutôt une contrainte d'intégrité qu'une vrai clef (en général dangereusement basée sur un concept fonctionnel). Mais bon ce n'est pas le sujet du topic.

Ce type de clef découle d'une modélisation respectant les règles de gestion. Je suis d'accord avec toi, ce n'est pas l'objet du topic. Néanmoins, si CodeFirst ne le permet pas, c'est pour moi déjà un point éliminatoire.

Oui. Mais ton implémentation de DAL ne fait pas tout ça non plus.
Ce n'est pas le rôle d'un ORM. Un ORM ne remplace pas le travail d'un administrateur de base de données. Tu te trompes sur l'usage.

Tu sembles réfractaire... Cela m'arrive aussi. Je te suggère d'essayer

A+

Non, ma DAL ne fait pas cela en effet. Mais elle ne crée pas la DB non plus.

Avec Code First, c'est en fait la DB qui s'adapte au code. Or je crois profondément que cela de devrait jamais être le cas. Pour tout projet impliquant de stocker de l'information, je pense que la première chose à faire est de mettre à plat toute l'information de l'univers concerné par le projet et de voir/comprendre comme elle s'organise. Une fois la DB correctement normalisée et après vérification de toutes règles de gestion par la MOA, alors seulement, il est temps de penser à la partie software du projet.

Les bases d'un projet d'information de gestion SONT les données (et par conséquent, la DB). Une DB fortement normalisée et avec les contraintes appropriées permettra la détection automatique d'une tonne de "bugs" en phase de dev/test. Il est si facile d'oublier de faire une vérification avant d'insérer une ligne dans une table qui n'aurait pas y être.

Bref, je vais m'arrêter là, je crois qu'on a compris que je place les données avant tout dans un projet en impliquant.

Je suis purement programmeur de formation mais dans la boîte où je suis, on s'occupe de tout du début à la fin. Ce qui m'a fait prendre conscience de l'importance incommensurable d'une base de données correctement modélisée/normalisée. Une fois cela établi, le développement de l'application est grandement facilité. Il suffit de suivre les rails posées par la DB.

[plume13]

Bonjour à tous, j'ai lu avec intérêt vous posts et les tutos cités. Je ne connaissais pas CodeFirst et c'est vrai que cela a l'air simple et pratique. Les développeurs n'ont plus besoin de s'y connaître en BDD. Le rêve quoi !
Sauf que j'ai du mal à croire que ce soit aussi magique... Je suis plutôt de l'avis de Kropernic sur le fait que le coeur d'un logiciel de gestion, c'est la base de données, et qu'il est préférable de garder la main dessus et que peu de personnes puissent modifier son schéma.
Cependant, j'utilise EF en Database-First avec modèle T4 d'objets POCO et j'en suis satisfaite : je garde la main tout en m'évitant l'écriture de code d'ajout/modification/etc. Par contre, je fais bien attention à ce que j'écris en linq, histoire de pas me retrouver avec des requêtes Sql de 300 lignes.
Cela dit, j'essaierai un jour pour voir ce que ça donne vraiment, je pourrais être surprise