Discussion :

[Seth77]

Salut

Que conseilleriez vous comme OR Mapper gratuit ?

[oyigit]

Nhibernate

[Seth77]

Nhibernate

Connais ... un peu "complique" non ?

[oyigit]

La première fois c'est peut être pas évident, mais ça reste largement accessible. En plus y'a pas mal de documentation sur le Web, et l'équivalent en JAVA existe. Et pour finir, ça doit être certainement l'un des outils de mapping objet relationnel les plus répandu...

[_skip]

La gratuité est vraiment une nécessité absolue?

[Seth77]

Pour des trucs perso oui ...
sinon je suis egalement currieux sur les or payant ....

[maa]

J'utilise aussi nhibernate et j'en suis assez satisfait.

Je regrette que l'on ne puisse pas utiliser directement des collections BindingList<T>. Il faut faire sa propre implémentation, c'est faisable mais c'est un peu galère...

J'attends de voir ce que donnera linq to entities...

[anthyme]

Sinon si tu veux du simple(iste) il y a Castle ActiveRecord, il s'agit d'une surcouche de nhibernate qui permet de faire des mapping de maniere vraiment aisé (une approche dans le style de ruby on rail)

voici le site : http://www.castleproject.org/

[Seth77]

Up !

[_skip]

Tu t'es décidé à payer pour une solution commerciale entre temps?

[Seth77]

Faut voir ... eventuellement ...

[_skip]

Dans ce cas, laisse-moi t'assurer que cet outil est l'une des plus grosses merveilles que le monde dotnet a à t'offir.
Personnellement je trouve qu'il est des kilomètres devant tout ce qui se fait ailleurs.

http://www.llblgen.com/defaultgeneric.aspx

[rad_hass]

As tu regardé du côté d'Entity Framework ?

Il faut connaitre cette technos, car c'est la solution actuel et future proposé par MS, quitte par la suite faire un choix différent ... La version 2 est prévu pour la fin de l'année ...

[Papy214]

As tu regardé du côté d'Entity Framework ?

ça ne supporte toujours que SQL Server ?

[rad_hass]

ça ne supporte toujours que SQL Server ?

Ah non, on trouve actuellement des providers pour toutes les bases des grands acteurs du marché (DB2, Oracle, PostgreSQL, MySql ...)

[maa]

Dans ce cas, laisse-moi t'assurer que cet outil est l'une des plus grosses merveilles que le monde dotnet a à t'offir.
Personnellement je trouve qu'il est des kilomètres devant tout ce qui se fait ailleurs.

Pourquoi ?

[_skip]

1) Ca s'appuie sur du code généré, pas de reflection

2) Tu formes des requêtes à partir de code c# avec autocomplétion et vérification à la compilation. Des requêtes de n'importe quelle compexité (aggrégat, sous-requêtes dans where, requête corréléé etc...). Pas de pseudo-SQL façon hibernate.
Donc 100% de ton code est checké en compile time.

3) Toutes les entités générées disposent de leur propre algo de sérialisation qui est 3/4 fois plus rapide que le standard. Idéal pour le remoting.

4) Support des requêtes linq, des units of work, et possibilités exhaustives de gestion de transaction.

5) Tu as le support des développeurs de l'outil en personne sur le forum, ils répondent dans les 3 heures.

Et encore, je mentionne que le minimum, y'a aussi de l'injection de dépendance, de la sécurité... etc...

[maa]

Je devrais essayer...
mais quand tu dis que ça génère du code, tu veux dire que les entités métiers sont générées en fonction de ce que tu as en base de données (un peu à la manière Linq to entities) ou alors il crée du code "intermédiaire" entre les classes métiers existante et la bdd? (ce qui me plairait beaucoup plus...)

[B.AF]

Dans ce cas, laisse-moi t'assurer que cet outil est l'une des plus grosses merveilles que le monde dotnet a à t'offir.
Personnellement je trouve qu'il est des kilomètres devant tout ce qui se fait ailleurs.

http://www.llblgen.com/defaultgeneric.aspx

Mouai.....C'est pas totalement vrai non plus.
C'est un bon soft, très bon même, mais Frans a les idée trop arrêtées sur plein de choses. Nous on l'a acheté et on a arrêté parce que sur certains sujets, impossible d'avoir satisfaction.

Enfin bon, c'est le principe d'acheter le composant : A moins d'avoir les sources (et là souvent ils ne garantissent pas le résultat), un composant open source n'est pas biaisé par le discours marketing.

En gros avec WCF, on a souffert mais BIG TIME, et le moteur de requête est horrible. Alors oui il y a le support Linq depuis la derniére version, mais c'est pareil, en distribué, passé l'aspect sex du langage, on se heurte comme avec les autres aux questions de graph.

[B.AF]

ResultsetFields fields = new ResultsetFields(2);
fields.DefineField(CustomerFields.ContactName, 0);
fields.DefineField(new EntityField2("Total",
(OrderDetailsFields.Quantity * OrderDetailsFields.UnitPrice), AggregateFunction.Sum), 1);
RelationPredicateBucket filter = new RelationPredicateBucket();
filter.Relations.Add(CustomerEntity.Relations.OrderEntityUsingCustomerId);
filter.Relations.Add(OrderEntity.Relations.OrderDetailsEntityUsingOrderId);
GroupByCollection groupBy = new GroupByCollection();
groupBy.Add(fields[0]);
DataTable table = new DataTable();
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
adapter.FetchTypedList(fields, table, filter, 0, null, true, groupBy);
}

pour obtenir :
[QUOTE}
SELECT c.contactname, SUM(quantity * unitprice) AS TotalOrders
FROM customers c INNER JOIN orders o
ON c.customerid = o.customerid
INNER JOIN [ORDER details] od
ON o.orderid = od.orderid
GROUP BY c.contactname
[/QUOTE]

Je suis d'accord, le moteur de requêtes est super pratique...

Ton problème de fond est peut être plutôt que si le principe de Nhib, donc d'hibernate, donc fondamentalement du principe d'ORM (bah oui quand même), c'est que peut être un ORM n'est pas l'outil que tu cherches.