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.

[Nathanael Marchand]

Il y a aussi ce qui se passe dans les tutos/démos et la réalité. Bien souvent pour faire les démos de MVC, l'accès base se fait dans les controleurs et les vues sont des scaffoldings des entités EF. Par conséquent, on a pas le n-tiers
Dans un vrai projet, ca ne se passe pas tout à fait comme ca (enfin j'espère).

[Immobilis]

Il y a aussi ce qui se passe dans les tutos/démos et la réalité. Bien souvent pour faire les démos de MVC, l'accès base se fait dans les controleurs et les vues sont des scaffoldings des entités EF. Par conséquent, on a pas le n-tiers
Dans un vrai projet, ca ne se passe pas tout à fait comme ca (enfin j'espère).

Vu que je n'ai pas d'apriori sur MVC, j'essaye justement d'appliquer ce qu'on voit dans les tutos et démo. Du coup, je cerne mal l'intérêt de "ASP.Net MVC" face à un multicouche, des webforms avec un code behind ne faisant que de la mise en page.

Le lien de rad_hass est intéressant et montre quelque chose de totalement différent de ce qu'on peut trouver ailleurs à propos de MVC

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

D'ailleurs, les relations entre les trois parties du pattern montrées dans ce schéma ne correspondent pas trop au modèle originel.

Sur http://baptiste-wicht.developpez.com...onception/mvc/

Sur http://folk.uio.no/trygver/themes/mvc/mvc-index.html par Trygve M. H. Reenskaug lui-même.

Je suis perplexe...

[rad_hass]

Je suis perplexe...

Non tu devrais pas

D'ailleurs, les relations entre les trois parties du pattern montrées dans ce schéma ne correspondent pas trop au modèle originel.

Car elle correspondent, cf cette image :



Views et Controllers (en vert) sont dans le projet Web UI et ont les relations classiques du pattern MVC.

Modèle en vert représente la troisième partie du pattern MVC et on voit qu'on retrouve les échanges classiques entre les trois parties Model View Controller

[Immobilis]

Modèle en vert représente la troisième partie du pattern MVC et on voit qu'on retrouve les échanges classiques entre les trois parties Model View Controller

Dans ce schéma les liens ne sont pas très explicites.
Il me semble que son architecture coupe les ponts entre la vue, le contrôleur et le model. En effet, ses objets CommandRequest et CommandResponse ne correspondent pas au objets réels de sont model. C'est la couche Service qui s'occupe du maping. Peut-on d'ailleurs assimiler cette couche à une BLL? Toujours est-il que je ne retrouve pas les échanges entre la vue et le modèle comme indiqué dans le schéma ci-dessous:

Ai-je raté un truc?

Merci

A+

[Immobilis]

Je viens de lire ce document: http://msdn.microsoft.com/en-us/library/ff647462.aspx

Il explique comment implémenter MVC sur un projet WebForm. Je n'y vois qu'un projet mutlicouche standard. Etes vous d'accord avec cette implémentation et mon interprétation?

Merci d'avance.