Discussion :

[Faiche]

Bonjour,

Désolé pour le titre pas clair, mais je ne voyais pas comment résumer le truc.

Je connais le SE mais pas le EE, et je suis sur un projet d'appli EJB/JPA. Donc je découvre tout ça, dans l'ordre, JPA d'abord, et EJB après.

Pour faire les actions de type CRUD, sans connaitre les EJB, je me suis fait des fonctions statiques paramétrées du style :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
	public static <T> T create(T elt)
	{
		EntityManager em = PersistenceManager.getEntityManager();
		EntityTransaction tx = em.getTransaction();
 
		tx.begin();
		try
		{
			em.persist(elt);
			tx.commit();
		}
		catch (Exception e)
		{
			e.printStackTrace();
			if (tx != null)
			{
				tx.rollback();
			}
		}
 
		return elt;
	}

Du coup, il suffit d'appeller CrudUtils.create(elt); et ça marche.

Aujourd'hui, je suis tombé sur l'article d'un blog qui faisait plus ou moins la même chose, mais en parametrant la classe, et en indiquant qu'il fallait étendre cette classe pour chaque DAO.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
@Stateless
public class CRUDBean<T> implements CRUDLocal<T> {
 
    @PersistenceContext
    EntityManager em;
 
    public T add(T entity) {
        em.persist(entity);
        return entity;
    }
...
}

Sachant que je ne connais pas du tout les EJB, est ce que qqun pourrait me dire si la méthode par héritage est la seule correcte, et m'expliquer un peu pourquoi ?

Merci d'avance

[lunatix]

hum, comme souvent, question de gout, de contexte..

disons que le gros problème de ton approche statique, est que si tu veux modifier le comportement du create (par exemple) pour un bean particulier, tu vas devoir bidouiller, alors que si tu a un beanDao qui etends un abstractDao, tu peux jouer sur l'héritage pour modifier le comportement.

maintenant, si tu sais que tu n'auras jamais besoins de ca (parce que petit programme, ou alors base de données tres simple), ton choix peut etre le bon.

[Faiche]

Non, tu as raison, je n'avais pas pensé à un éventuel cas spécifique.

Merci

[Faiche]

Je rouvre la discussion car j'ai toujours des problemes avec cette conception :

Si j'ai bien compris, le serveur d'application charge les ejb qui ont une interface. Il faut que l'interface soit taguée local ou remote.

Pour charger mes classes, j'ai fait une interface du CrudBean générique, et pour chaque DAO, j'étends le CrudBean, et l'interface de ce DAO étend l'interface du CrudBean.

Je pensais que c'était une bonne idée, mais ça ne marche pas. La seule classe chargée est le CrudBean qui est au sommet de la chaine.

Le problème, c'est que je ne sais pas dans quel sens aller, et du coup j'avance à tatons, par bout de code repris etc, ce qui est la mauvaise méthode.

Tant que j'aurai pas compris, je ferais des trucs moches, mais tant que j'ai pas réussi a faire marcher un truc, je comprends pas.

Donc si qqun, en voyant les bouts de code que je vais mettre, pouvait me dire ce que je fais de mal, ça m'aiderai beaucoup :

interface de base

Code :

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

1
2
3
4
5
@Remote
public interface AbstractDAS<T>
{
 // Méthodes CRUD
}

classe de base

Code :

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

1
2
3
4
5
6
7
8
9
10
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public abstract class AbstractDAO<T> implements AbstractDAS<T>
{
	@PersistenceContext(unitName = "testmaven")
	protected EntityManager em;
 
        // Méthodes CRUD Implémentées
 
}

Interface de mon premier DAO

Code :

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

1
2
3
4
public interface PersonDAS extends AbstractDAS<Person>
{
	public Person getByName(String name);
}

Mon premier DAO

Code :

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

1
2
3
4
5
6
7
public class PersonDAO extends AbstractDAO<Person> implements PersonDAS
{
	public Person getByName(String name)
	{
		return (Person) em.createQuery("Select p from Person p where p.nom = '" + name + "'").getSingleResult();
	}
}

Voila.

- Faut il remettre le @Remote sur l'interface PersonDAS ?
- Faut il remettre @Stateless et @Transactionattributes sur la classe PersonDAO ?
- Cette conception par héritage est elle mauvaise ?

Je suis désolé d'être aussi vague, une fois qu'une appli de base marchera, tout ira mieux.

Merci d'avance

[Faiche]

En testant, j'ai rajouté @remote sur personDAS et @stateless etc sur personDAO et ça charge. Mais je ne sais toujours pas ce qu'il aurait fallu faire, pour faire bien.

Enfin bon.

[lunatix]

bon.

alors en théorie (et je dis bien en théorie), la couche DAO n'est pas amenée a etre mise a disposition.

en général on fait une couche service qui utilise la couche DAO. c'est dans cette couche service que tu vas coller ton code métier, et faire appel aux dao pour accéder aux données.

(maintenant, si tu penses que cette couche service n'est pas necessaire, tu peux la virer. (enfin, c'est ce que je pense, ce n'est pas forcement partagé par tout le monde ))

ensuite, il faut annoter les implémentations il me semble. (je verifierai)

Edit : il faut le @remote sur l'interface remote, et pas d'annotation sur ton abstractDAO. par contre il faut les remettre sur les implementations

[hocdz]

Bonjour, dans mon application j'utilise des dao pour l'accès aux données et packages de ma db. Jutilise donc en gros struts des jsp et des actions qui appellent les méthodes de mes dao pour traiter les données. ces dao sont de simples classes java implémentant le design pattern dao (pas d'ejb). A ce sujet, n'ayant pas vraiment travaillé avec des ejb, pouvez vous m'expliquer ce que des ejb auraient pu apporter de plus par rapport à une telle implémentation? Merci.