Discussion :

[rad_hass]

Bonjour,

Je travaille sur un projet ASP.NET ayant une architecture n-tiers (DAL, BLL, Pres et mes BusinessObject). Je vais poser ma question sous la forme d'exemple, pour que ça soit plus explicite.

Selon l'architecture décrite ci-dessous, pour une action de diffusion, j'ai une classe Diffusion.aspx, Diffusion.cs (objet métier), DiffusionManager, DiffusionDAO ...
Supposant que l'action de diffusion se découpe en deux partie la diffusion et l'archivage de la liste de diffusion dans la bd ... Le diffuseur et le récepteur ont leur objet récupérer de la bd en mémoire lors de la diffusion.

Les deux actions de diffusion et d'archivage sont exécuté dans le manager, mais est il possible de les appeler séparément dans le code behind de diffusion.aspx ? Ou ce n'est pas la meilleur utilisation de cette architecture ?

Est ce logique de faire dans Diffusion.aspx.cs

Code :

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

1
2
3
4
5
6
 
    protected void Diffusion_Click(object sender, EventArgs e)
    {
        DiffusionManager.Instance.Diffuser(Recepteur, message);
        DiffusionManager.Instance.ArchiverDiffusion(Diffusion);
    }

Ou est ce que le processus de diffusion et d'archivage doivent être un processus unique dans la couche présentation ?

D'avance merci.

[rad_hass]

Une âme charitable qui aurait un point de vue sur ma chtite quechtion ?

[mlebreton]

Je ne suis pas certain d'avoir bien saisi la question, mais d'une manière générale, un des grands principes de la séparation des couches pourait se résumer par un petit proverbe : "que ta main gauche ne sache pas ce que fait ta main droite".

Ainsi, aucun process ne doit être codé au niveau de l'interface. Imaginons que demain, le process que vous décriviez change et nécessite l'indroduction d'une étape supplémentaire ! Il ne faudrait pas que cela oblige à intervenir au niveau de l'interface. Imaginons que demain vous ayez à développer un nouveau portail (en Web mobile par exemple), il ne faudrait pas que vous soyez obligé de recoder votre process dans cette nouvelle interface.

Pensez toujours que même si vous déployez toute votre application sur un même serveur, il faut qu'il soit possible de déployer chaque couche sur un serveur différent. Même si vous n'avez qu'un seul portail, pensez toujours comme si vous en aviez plusieurs. Cette vision des choses aide souvent à savoir où coder telle ou telle chose.

Bon maintenant, on n'est pas des extremistes, il ne s'agit apparamement que de deux lignes de code... Mais bon, les petites choses batissent les grandes habitutes.

[rad_hass]

D'abord merci beaucoup pour ta réponse

Bon maintenant, on n'est pas des extremistes, il ne s'agit apparamement que de deux lignes de code... Mais bon, les petites choses batissent les grandes habitutes.

Tout à fait et c'est exactement pour cette raison que je pose cette question.

Je ne suis pas certain d'avoir bien saisi la question, mais d'une manière générale, un des grands principes de la séparation des couches pourait se résumer par un petit proverbe : "que ta main gauche ne sache pas ce que fait ta main droite".

En fait, à une action j'ai deux processus distinct (et je ne fais que les appelé dans la couche présentation), je le fais actuellement en deux appel (en partie car les deux process prennent des arguments différent). Mais si on considère que faire ces appels comme déjà une logique, j'ai certainement fais alors une erreur

Ainsi, aucun process ne doit être codé au niveau de l'interface. Imaginons que demain, le process que vous décriviez change et nécessite l'indroduction d'une étape supplémentaire ! Il ne faudrait pas que cela oblige à intervenir au niveau de l'interface. Imaginons que demain vous ayez à développer un nouveau portail (en Web mobile par exemple), il ne faudrait pas que vous soyez obligé de recoder votre process dans cette nouvelle interface.

Je suis tout à fais d'accord avec cela, mais si le nouveau processus fais intervenir des nouveaux arguments (qui n'étaient pas transmis dans le processus initial) on est obligé de retravaillé au niveau couche présentation. Alors faut-il dans ce cas modifié le processus initial et notamment les paramètres d'entrée ou crée un nouveau processus qu'on appel au niveau présentation ?

J'espère que j'ai été un peu plus claire, même si vers la fin je dérive un peu

Encore merci.

[mlebreton]

Je suis tout à fais d'accord avec cela, mais si le nouveau processus fais intervenir des nouveaux arguments (qui n'étaient pas transmis dans le processus initial) on est obligé de retravaillé au niveau couche présentation. Alors faut-il dans ce cas modifié le processus initial et notamment les paramètres d'entrée ou crée un nouveau processus qu'on appel au niveau présentation ?

Bien sur, tout ne peut pas être parfait. L'introduction de nouveaux paramètres concerne l'interface. Il est donc logique d'avoir à la modifier.

Par contre, faut-il modifier le code existant ou implémenter un nouveau code utilisant le nouveau paramètre ? C'est une bonne question. Mais là, il pourrait y avoir un grand débat.

Moi qui travail sur la création de Framework d'entreprise qui sont utilisés ensuite par de nombreuses applications qui persistent dans des version différentes, j'ai tendance à dire : "il faut toujours préserver la compatibilité des versions". Donc, j'opte bien souvent pour le codage parallèle d'une version lambda du process. Dans la pratique, cela donne des méthodes de même nom mais avec des paramètres différents.

Mais cela va bien parce que je travail beaucoup sur des Frameworks. Quand il s'agit de process métier les choses peuvent parfois être différentes. Imaginons par exemple que la règle de calcul de la TVA change (je tape dans le simple), il n'est pas question qu'il persiste une version précédente du process au risque de voir certaines parties de l'application ou des applications l'utiliser.

Je crois donc qu'il faut juste se donner le temps de bien réfléchir avant de décider. Se projeter dans le futur et essayer de peser les implications. D'une manière générale, si l'ancien code est périmé, il ne faut pas le conserver et donc le modifier. Si l'ancien code est toujours d'actualité, on code en parallèle.