2009-11-18 10 views
5

J'ai tout juste commencé à faire des recherches sur mvc, et je ne suis pas sûr de l'avoir compris. D'après ce que je comprends, il semble que la mise en œuvre d'une solution à trois niveaux, c'est-à-dire que le modèle corresponde à la couche DAL, Controller to business logic et View as Presentation layer.MVC - est-ce juste un modèle à 3 niveaux?

Suis-je loin de la base ici?

Répondre

8

Je déconseille de traiter le modèle comme une simple couche d'accès aux données. C'est trop simplifié, et cela vous oblige à mettre trop de code dans la couche Controller. Il est préférable d'ajouter davantage de code dans le modèle et de ne faire de la persistance de la base de données qu'une partie du code interne du modèle. Je me plais à penser de MVC comme ceci:

  • Controller: poignée d'entrée, déterminer quel modèle et qui Voir instancier
  • Vue: présentation des données d'application
  • Modèle: toute autre logique pour l'application, y compris mais non limité à DAL

Il s'agit essentiellement du modèle Page Controller.

Une autre façon d'y penser est la suivante: supposons que vous deviez porter votre application Web sur une autre plateforme, telle qu'une application de ligne de commande ou une application graphique de bureau. Quelles parties de la logique d'application devez-vous réutiliser? Le contrôleur et la vue changeraient au fur et à mesure que vous porteriez votre application sur une autre plateforme, car l'implémentation des entrées et des sorties devrait changer. Le code qui n'a pas besoin d'être modifié doit être implémenté dans votre modèle. Si vous avez bien fait la séparation des préoccupations, alors le modèle, la vue et le contrôleur seront couplés de manière minimale, et vous pourrez en modifier l'implémentation sans trop affecter les autres. Si vous modifiez le modèle et que vous vous retrouvez à réécrire beaucoup de code dans le contrôleur ou la vue, vous n'avez probablement pas séparé ces couches de manière adéquate. Et vice versa.

Lisez à propos de l'antipattern Anemic Domain Model de Martin Fowler ou Domain Driven Design Quickly pour avoir d'autres perspectives.

Également voir mon blog from 2008 que j'ai écrit en réponse à des personnes décriant le modèle Active Record. Il a eu de bons commentaires et discussions.

+1

Je suis d'accord. Les contrôleurs maigres et les gros modèles me facilitent la vie. –

3

Trier par. Il ressemble à ceci:

alt text

Le modèle le plus couramment utilisé aujourd'hui est:

Database -> DAL -> BLL -> Controller -> View Model -> UI 

DAL == Data Access Layer (aka ORM, Object-Relational mapper) 
BLL == Business Logic Layer 

Notez que vous n'avez pas toujours besoin de toutes les couches. Le modèle BLL et View Model, par exemple, peut être facultatif si l'application est suffisamment petite. Vous devriez consulter le NerdDinner tutorial. Il décrit tous ces concepts dans une seule référence.

0

Une courte note, vous avez raison quand vous dites que le contrôleur peut (ne doit pas) être la couche d'affaires, et la vue est la couche de présentation. Cependant, les modèles sont les objets (en fonction de l'implémentation) qui contiennent les données, tandis qu'une couche de données est une couche qui récupère/manipule les données.