[Databinding]DAO NHibernate et Gridview

Version imprimable

17/04/2007, 18h28
del-dongo

[Databinding]DAO NHibernate et Gridview
Bonjour,
j'ai plusieurs soucis avec mes DAO et le databinding avec la gridview Asp .Net2.
Je m'explique : mes DAOs ont tous la même architecture, ils savent effectuer les operations CRUD sur les entites de mon domaine, ils se basent sur nhibernate pour cela.
Code:

1 2 3 4 5 6 public T SaveOrUpdate(T entity) { NHibernateSession.SaveOrUpdate(entity); return entity; }
1. Lors du binding avec ma gridview, je dépose en design mon objectdatasource, je le lie à mon dao (CustomerDAO par exemple), je désigne les méthodes select, save, insert, delete.

Je lie ma gridview à mon objectdatasource, Visual studio me créé l'ensemble de mes colonnes, j'enlève celles qui ne m'intéresse pas, j'active l'édition sur la gridview et hop on éxécute.

Et la c'est le drame, le databinding insère des valeures nulles dans les propriétés de mon objet métier qui n'ont pas de colonnes dans la gridview.(pas de colonne birthday = birthday null).

Savez comment configurer correctement l'objectdatasource ou la gridview pour ne pas avoir ce comportement ??

2. Deuxième problème, je veux utiliser Spring .net ou Castle Windsor pour l'injection de dépendance. C'est donc ces outils qui créeront mes DAOs pour moi, or ce gentil :roll: objectdatasource m'instancie lui meme mes daos, je n'ai pas la main sur cette instanciation. Quelqu'un à t'il déja réussi à concilier ces 2 technos ? Si ou comment...?

Merci d'avance à tous !
18/04/2007, 10h01
djflex68

Citation:

Et la c'est le drame, le databinding insère des valeures nulles dans les propriétés de mon objet métier qui n'ont pas de colonnes dans la gridview.(pas de colonne birthday = birthday null).

ça me semble normal étant donné qu'il n'a pas de valeur par défaut, il utilise null. Par contre si tu veux forcer une valeur particulière plutôt que null, tu peux utiliser l'évènement Inserting de l'object DataSource pour modifier l'objet métier qui va être envoyé au DAO. Il y a un paramètre qui est e.InputParameter ou qq chose comme ça qui est en fait ton objet métier juste avant qu'il soit envoyé à ton DAO.

Citation:

Deuxième problème, je veux utiliser Spring .net ou Castle Windsor pour l'injection de dépendance. C'est donc ces outils qui créeront mes DAOs pour moi, or ce gentil objectdatasource m'instancie lui meme mes daos, je n'ai pas la main sur cette instanciation. Quelqu'un à t'il déja réussi à concilier ces 2 technos ? Si ou comment...?

Alors ça mon cher ami je peux te dire que ça me gonfle aussi assez sérieusement. J'ai exactement le même problème que toi, je ne peux pas contrôler l'instanciation de mes services dont certains sont des singletons, ce qui signifie qu'ils ne peuvent tout simplement pas être instanciés par voie classique (constructeurs). J'ai déjà cherché longuement sur le sujet mais j'ai rien trouvé. Si tu trouves qq chose préviens moi ça m'intéresse aussi :)
20/04/2007, 09h49
del-dongo

Merci pour ces réponses djflex68, ca fait du bien de voir que ses problématiques sont partagées.

Je pense que ce n'est pas normal. Mon objet métier est correctement chargé (toutes ces propriétés sont chargées depuis la base). Le databinding semble mettre les propriétés non bindées à null, pourquoi ne pas laissé la valeur initiale ? Je ne vais pas m'amuser à identifier toutes les propriétés que je n'ai pas bindées, pour penser à affecter je ne sais quelles valeurs d'ailleurs, dans l'évènement Inserting.

Les commandes et dataset générées par Visual studio lors d'un glissé déposé d'une table de base ne posent pas ce genre de problème. Cela est surement du au fait que l'update généré est du type

Code:

Save(string toto, int tutu, Datetime tata,...)

alors qu'avec mes DAO et POCO, il est du type

Code:

Save(POCO monPoco)

Quelqu'un a t'il déja réussi à faire fonctionner correctement le databinding avec ses DAO et POCO maison ...?
23/04/2008, 09h11
djflex68

Je ne sais pas si ça peut encore te servir après tout ce temps mais pour tes problèmes c'est assez facile à résoudre :

Citation:

Je pense que ce n'est pas normal. Mon objet métier est correctement chargé (toutes ces propriétés sont chargées depuis la base). Le databinding semble mettre les propriétés non bindées à null, pourquoi ne pas laissé la valeur initiale ?

Il y a un moyen très simple qui consiste à rajouter toutes les propriétés que tu veux passer entre les appels dans la propriété DataKeyNames du GridView (disponible en design). Généralement on ne met que la propriété qui sert d'identifiant de l'objet métier dans le DataKeyNames, mais on peut également rajouter toutes les propriétés que l'on souhaite voir transiter entre les appels (ex : les propriétés qui ne sont pas bindées à une colonne du gridview)

Citation:

or ce gentil objectdatasource m'instancie lui meme mes daos, je n'ai pas la main sur cette instanciation

Tu peux gérer l'instanciation de ton objet d'accès aux données par l'évènement ObjectCreating de ton ObjectDataSource.

@+ 8-)