Discussion :

[Exsilius]

A tout ceux qui utilise une architecture en couche sous DotNet (ou qui s'y interresse...)

Je serais trés intéressé par vos retours d'expérience sur les outils actuels permettant de générer les couches basses.

De notre côté, nous avons créé notre première architecture multi-couches sans outil (utilisation des DataSets). Nous allons faire une évolution substancielle de l'architecture technique de notre projet, et nous envisageons aujourd'hui d'utiliser un générateur de code pour nous faciliter la tâche.

Succintement, nos besoins seraient :
- Génération d'une DAL (couche d'accés aux données) optimisé et modifiable
- Génération d'une couche métier idéalement composé de :
- Service gérant le CRUD et la recherche multi-critères complexes
- Objets DAO indépendants
- Objets DTO indépendants et assurant une recherche multi-critères complexes (proche de 100% de ce que propose une requête SQL...glurps...)

Etant donné que je n'ai aucune expérience sur ces outils, je m'attends à ce que vous puissiez me répondre :
- Aucun problème, ça fait 4 ans que ça existe.
Ou bien
- "Tu rêves !"

Je ne serais même pas surpris et vos réponses m'intéresseront forcément


Merci de votre partage.

[_skip]

Ca va surtout dépendre si ta boîte est d'accord de payer quelque chose ou non?

De pas mal dans le gratuit tu as .NetTiers ou nHibernate.
Et encore ça dépend si tu es d'accord de passer des entités entre tes couches et t'en servir comme business object ou pas du tout.

Mais sauf erreur, tu veux que les objets générés soient indépendants de la base de donnée pour qu ils puissent être envoyés par webservice ou remoting? Donc pas de SelfService avec des entités ayant des méthodes Save() ou Delete()?

[Exsilius]

"membre éclairé" et eclairant !! Tu m'a parfaitement compris

Remoting pour mes objets DAO donc oui indépendance nécessaire. Jusqu'à présent nous utilisons une structure de communication indépendante, mais l'idée d'avoir 2 types de classe pour représenter le même concept ne me plaît que moyennement

Je devrais pouvoir justifier l'achat d'un outil s'il répond à mes critéres d'exigences (et si le prix n'est pas trop élevé)

On est entrain d'étudier EntitySpaces...ça à l'air puissant (syntaxe permettant 100% des fonctionnalités du langage SQL), mais les DAO ne sont pas indépendants (et ça compile pas tout de suite )...working on...

Et je suis un peu dans le flou avec EntityFramework...je ne comprends même pas ou ils en sont du projet...

D'ailleurs quel est l'avis officiel de Microsoft sur le sujet ? EntitySpaces ? EntityFramework ? J'ai aussi entendu parler du rachat de SubSonic... enfin bref, je nage dans le pays d'alice au merveilles...

[tomlev]

En un mot: LINQ (introduit dans le framework 3.5)
Si tu n'en as jamais entendu parler, fais une recherche sur google

[Exsilius]

Merci, je vais regarder en détail

J'en avais entendu parler en étudiant Entity Framework.

Quel est précisément le lien entre LINQ et Entity Framework ?

[_skip]

En tout cas, je te conseille d'éviter les outils qui marchent par forward engineering comme XPO ou dataobjects. Dans lesquelles tu commences d'un modèle objet et que tu génères le relationnel car dans mon expérience, ça fait jamais ce que tu as envie et ça pose des soucis de migration entre les versions.
Essaie d'avoir les requêtes objets typées (même celles qui comportent des agrégats ), cela permet de détecter un maximum d'erreur lors de la compilation et c'est ça vraiment qui le bonheur dans un ORM, en plus avec l'intellisense en prime.

Mais ce serait pour quelle(s) base(s) de donnée?

[Exsilius]

SQL Server

J'ai pas compris "Essaie d'avoir les requêtes objets typées (même celles qui comportent des agrégats)", tu me donnes un exemple ? (fin de journée oblige...bon j'avoue c'est une excuse pour cacher mon niveau pitoyable... )

[Thomas Lebrun]

Merci, je vais regarder en détail

J'en avais entendu parler en étudiant Entity Framework.

Quel est précisément le lien entre LINQ et Entity Framework ?

LINQ To SQL est un outil de MOR allégé (si l'on peut dire) qui cible uniquement SQL Server.

Entity Framework, c'est une sorte de version plus complète de LINQ To SQL

[_skip]

Et bien que cela :
SELECT *
FROM Customers
WHERE country = 'France' AND active = true
ORDER By surname, firstName

Deviendrait

List<Customers> results = new List<Customers>();
Predicate filter = new Predicate();
filter.add( CustomerFields.Country == "France");
filter.add( CustomerFields.Active == true ) ;

SortExpression sorter = new SortExpression();
sorter.add( CustomerFields.surname | SortOrder.Ascending );
sorter.add( CustomerFields.firstName | SortOrder.Ascending );

Broker.FillCollection( list ,filter , sorter );

Bon c'est tapé a la brac, mais juste pour dire que 100% de ce code est typé, c'est à dire vérifié a la compilation. Si tu modifies le nom des colonnes de customers, ca compile plus et tu t'en rends compte. Si c'était formulé sous forme de chaine de caractères, ça planterait à l'exécution (autrement dit à la gueule du client) ce qui est pas forcément ce qu'on veut.
Ce genre de chose simplifie tellement la maintenance qu'on oublie le cout de l'ORM face aux nombreuses heures de tests économisées dans les grandes applications.

[tomlev]

LINQ To SQL est un outil de MOR allégé (si l'on peut dire) qui cible uniquement SQL Server.

Entity Framework, c'est une sorte de version plus complète de LINQ To SQL

Et on peut utiliser des requêtes LINQ avec Entity Framework ?

[Exsilius]

Merci _skip ! Oui je comprends mieux ce que tu avais dit. C'est effectivement une des raisons principales qui nous motivent...

Et merci Thomas

Donc si j'ai bien compris, LINQ n'est pas un générateur de classe. Ce sont de nouvelles fonctionnalités intégrées aux framework et permettant de requêter en utilisant un langage compilé...

Donc cela signifie, que je développe mes couches basses 'manuellement'...

J'ai bon ?

[tomlev]

Merci _skip ! Oui je comprends mieux ce que tu avais dit. C'est effectivement une des raisons principales qui nous motivent...

Et merci Thomas

Donc si j'ai bien compris, LINQ n'est pas un générateur de classe. Ce sont de nouvelles fonctionnalités intégrées aux framework et permettant de requêter en utilisant un langage compilé...

Donc cela signifie, que je développe mes couches basses 'manuellement'...

J'ai bon ?

En fait il y a un générateur de classes fourni avec VS2008 (SQLMetal). Il est bien intégré dans l'IDE, mais peut aussi s'utiliser en ligne de commande. Par contre ça ne fonctionne qu'avec SQL Server

[Exsilius]

Merci tomlev

Nous allons étudier la question