Discussion :

[Immobilis]

Salut,

J'avoue je suis plus "multicouche" que "MVC". Comme on parle beaucoup de ce dernier je me renseigne et m'interroge.

MVC a été inventé en 1979 bien avant donc l'apparition du net, des histoires de routage d'url etc.. MVC permet de développer une application (client lourd, léger) en distribuant des rôles. Dans ce contexte, l’UI se contente d’afficher et la logique est déportée dans les contrôleurs.

"ASP.Net MVC" est une des réponses à la question:

How do you modularize the user interface functionality of a Web application so that you can easily modify the individual parts?

Que je traduirai par: Dans une interface utilisateur web, comment rendre les fonctionnalités modulaires afin de les modifier facilement?

Si MVC peut cohabiter avec d’autres modèles, avec "ASP.Net MVC" on est clairement orienté web. Toutefois, il se pourrait que votre client vous dise: « Je veux réaliser les mêmes opérations de gestion sur mon Windows Phone ». Ou bien vous pouvez avoir besoin de développer une application console pour réaliser certaines opérations avec un batch.




Mes questions :

1. Quelles précautions prenez-vous pour être certain que votre logique métier est indépendante de l’interface?
2. Est-ce que le controleur n'est pas à la vue ce que le code behind est à la page?

Immobilis

[rad_hass]

J'avoue je suis plus "multicouche" que "MVC".

L'un n'empêche pas l'autre

MVC n'est qu'un pattern de Présentation, il ne dis pas comment il faut structurer ton domaine. Libre à toi d'utiliser une archi multicouche, DDD ou autre... Le comment construire le modèle que tu utilise dans ta structure MVC, le pattern ne le dit pas ^^

1. Ben c'est simple la logique métier n'est pas dans mon application de présentation

Pour te donner une idée voici une architecture DDD où la UI applique le pattern MVC.

http://blogs.businesssoftwareengineering.com/?p=28

2. le pattern MVC sert à séparer la présentation, les traitements et les données, donc si tes traitements étaient dans le code-behind le controller le remplace en ça

[Immobilis]

Tu ne mets pas de logique métier dans tes contrôleurs?

[rad_hass]

Tu ne mets pas de logique métier dans tes contrôleurs?

Non par définition du pattern non, voici la définition Wikipedia de MVC :

The pattern isolates "domain logic" (the application logic for the user) from the user interface (input and presentation), permitting independent development, testing and maintenance of each (separation of concerns).

Il n y a aucune raison pour que de la logique métier soit présente dans le controller ce n'est pas son rôle, son rôle est :

The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate.

Tirer de : http://msdn.microsoft.com/en-us/library/ff649643.aspx

[Immobilis]

L'un n'empêche pas l'autre

Dans une architecture multicouche, UI n'est pas sensé s'adresser directement au fournisseur de données (model du MVC). A moins qu'on considère que le model est une sorte de BLL + DAL. Sinon, cela parait difficile.

Non par définition du pattern non, voici la définition Wikipedia de MVC :

Je trouve pas que l'article de Wikipedia soit génial. De plus, ASP.Net MVC implémente le modèle Front Controller (http://dotnet.developpez.com/mvc/ape...overview/#LC-A). Ca ne change pas forcement le fond, mais cela peut complexifier le modèle. Sinon,

You have decided to use the Model-View-Controller(MVC) pattern to separate the user interface logic from the business logic of your dynamic Web application. You have reviewed the Page Controller pattern, but your page controller classes have complicated logic, are part of a deep inheritance hierarchy, or your application determines the navigation between pages dynamically based on configurable rules.

Je serai quand même curieux de voir combien de projets intègrent la logique métier dans les contrôleurs.

Il n y a aucune raison pour que de la logique métier soit présente dans le controller ce n'est pas son rôle, son rôle est

On est d'accord. Simplement, ce n'est pas super explicite dans la doc ni dans le modèles "out of the box" de VS.

Si je comprend ce que tu dis, il faut créer des projets en plus du projet web pour implémenter la partie métier.

[mermich]

Si je comprend ce que tu dis, il faut créer des projets en plus du projet web pour implémenter la partie métier.

Exactement, pour une appli 3-tiers, mvc ne représente que la couche présentations.

Je serai quand même curieux de voir combien de projets intègrent la logique métier dans les contrôleurs.

Comme toujours entre la théorie/best practices et les fait , il y souvent un gros écart.

En résumé aspnet.mvc ne sert qu'à faciliter le traitement des formulaires web, ne pas avoir de postbacks ou de viewState à gérer. De plus en aspmvc on écrit directement le html généré, ce qui facilite grandement le javascript ensuite.

Si tu veux intégrer ta logique métier dans le controlleur ou dans le modèle, rien ne t'en empêche, comme en aspnet ou rien ne t'empêche de définir tes requêtes directement sur la page.