Structure du Model dans une architecture MVC

Bonjour!

Ayant pour objectif de passer la certification .NET ASP.NET MVC, on a monté une petite équipe au boulot où on se forme mutuellement avec des livres officiels etc.
Et par rapport à ce qu'on a vu, je me posais une question, qui à mon avis est au niveau de la sensibilité du programmeur :)

J'ai remarqué que dans certains livres, la couche Model était composé de plusieurs types de modèles :

- Un Data Model, donc le modèle classique avec Entity Framework par exemple
- Un Business Model, qui contiendra toutes la logique, spécifique au modèle, fera les accès BDD pour récupérer les données etc (plutôt que dans le contrôleur)
- Un View Model, qui fera le lien entre la vue et le DataModel, et qui contiendra tout ce qui est DataAnnotations, ou encore des propriétés non prévues dans la base de données (puisque le Data Model est généré par la base)

Mais dans d'autres on ne parle pas du tout de cette notion là, ou à la rigueur juste de la partie Data/Business.

Comment gérer vous la partie Model dans vos projets MVC? Quelle(s) méthode(s) vous semble la plus propre?
De mon côté j'ai bien tendance à privilégier Data/Business/View, mais je suis conscient que sur de petits projets ça peut être lourd...

Voilà, merci pour votre partage d'expertise :)

Salut,

Je commence a m'auto former a l'ASP MVC, et je viens de voir ton sujet. Je n'avais pas encore entendu parler des différents modèles Data/Business/View , mais cela me semble très interressant.

Aurais tu des liens qui expliquent ce principe? Si possible en VB, car je ne comprend rien au C# :aie: sinon tant pis, je me débrouillerais avec du C# ^^

Pour répondre à la première question, j'utilise les trois que tu as cité.

J'utilise entity framework pour générer mes classes métiers depuis la BDD et pour faire les requetes sur la base sans prise de tête.

Pour la couche business, je suis pas sur qu'on parle de la même chose mais pour moi il s'agit d'une couche intermediaire entre tes controlleurs et ton data access (Entity Framework). C'est dans cette couche que j'applique mes regles métiers.

J'utilise les view models pour créer des objets contenant toutes les propriétés de mes vues car je trouve cela plus pratique pour le binding.

Pour le modèle multi-couche, je te conseil ce lien.

Bonjour, (j'espère que ce n'est pas un trop gros déterrage...) , pour ma part même travaillant sur un petit projet j'utilise exactement l'architecture décrite :

- classes de modèles entity framework (appelées POCO il me semble)

- couche DAL pour uniquement certaines requêtes métier complexes dans des méthodes statiques (que je souhaite donc partager entre tous mes contrôleurs).

- un viewModel pour pratiquement toutes mes vues (celles-ci étant plutôt complexes, je bénéficie du binding de modèle lors d'un Post ce qui est plutôt agréable...). Lorsque la vue est simple, j'envoie directement le modèle EF.

Avez vous trouvé plus d'informations sur les best practices à utiliser ??

Merci.