Προσπαθώ να κατανοήσω την λογική του μοντέλου - προτύπου. Για αυτό θα ήθελα να ρωτήσω τους γνώστες η λειτουργία του Controller είναι να ζητά πληροφορίες απο το Model δηλαδή να καλεί τις συναρτήσης του Model με τα sql ερωτήματα που αυτές περιέχουν ? Έπειτα τα δεδομένα που αποκτά ο Controller τα προωθεί στο View για προβολή ? 

Η περιγραφή που έδωσες πλησιάζει πιο πολύ το MVP αντί το MVC. Μία από τις κύριες διαφορές τους είναι ότι στο MVC το View ενημερώνεται με events από το Model, ενώ στο MVP ο Presenter ενημερώνει τις αλλαγές στο View από το Model, όπως δηλαδή έχεις περιγράψει. Για την ακρίβεια η ενημέρωσει του View από τον Presenter είναι μία έκδοση του MVP που λέγεται MVP (Passive View). Υπάρχει και η έκδοση όπου στο MVP το View μπορεί να ενημερώνεται με events από το Model αλλά και από τον Presenter, το λεγόμενο MVP (Supervising Controller).

Η δεύτερη εκδοχή που ανέφερα πλησιάζει ή σχεδόν είναι ίδια με το MVC.

Μία βαθύτερη κατανοήση του MVC θα μας εμφανίσει δύο Patterns επάνω στα οποία στηρίχτηκε η δημιουργία του MVC. Είναι μεταξύ View & Controller και είναι το λεγόμενο Strategy Pattern και μεταξύ του View & Model το λεγόμενο Observer Pattern.

Όλα αυτά όμως σε έναν κόσμο διαφορετικό από τον δικό μας όπου Events, Delegates IoC δεν υπήρχαν οπότε το Observer έπαιζε τον ρόλο των events και τα σημερινά IoC ή Delegates τον ρόλο του Strategy. Για αυτό και δεν θα δεις συνήθως να αναφέρονται σε αυτά τα δύο Patterns σήμερα, χωρίς τα οποία όμως δεν θα υπήρχε MVC. Απλά το αναφέρω για την ιστορία.

Στο Internet θα βρεις πολλές πληροφορίες για MVP & MVC για τις ομοιότητες και διαφορές τους. Από βιβλία δεν ξέρω να σου προτείνω κάτι.

Τέλος το MVC χρησιμοποιείται συνήθως για Web Projects και το MVP για Winforms. Για WPF υπάρχει το νεότερο MVVM το οποίο είναι εκτός θέματος απλά το αναφέρω για να έχεις μία γενικότερη εικόνα.

Αν κατάλαβα καλά μιλάς για το Model View Controller pattern και πως αυτό υλοποιείται στα ASP.Net MVC Web applications.

Το καλύτερο σημείο στο web για να μάθεις το ASP.Net MVC είναι εδώ

Αν θες μπορείς να ρίξεις μια ματιά σε ένα blog post μου όπου έχω ένα αναλυτικό παράδειγμα για μια απλή ASP.Net MVC application. Εκεί εξηγώ αναλυτικά τι κάνει το Μοdel, το View, o Controller.

Το μοντέλο αυτό ευνοεί αυτό το οποίο ονομάζουμε separation of concerns. Δεν υποκαθιστά τα web forms και βασίζεται στο ASP.Net framework. Υποστηρίζει caching,sessions,master pages.

Για να το πούμε απλά o Controller είναι ο ενορχηστρωτής. Όταν έχουμε ένα HTTP request που το λαμβάνει η ASP.Net MVC application μας,  αυτό το request μέσω routing μηχανισμού το κάνει handle ο Controller. O Controller μιλάει με το filesystem,database για να χτιστεί το Model. O Controller θα επιλέξει το View που θα "δείξει" τα δεδομένα του Model στον client. Ο Contoller δεν "μιλάει" με το UI (είναι δουλειά του View) και δεν αποθηκεύει state ή data. Αυτό είναι δουλειά του Μodel.

Το View είναι υπεύθυνο για το UI και μόνο. Το View μιλάει με το Model. Tο Model έχει τα δεδομένα που το View θα "δείξει" στον τελικό χρήστη. Το View δεν πρέπει έχει καθόλου application/business logic.

Νομίζω μπορείς να δεις το seperation of concerns paradigm από τα παραπάνω.

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Προγραμματιζω σε PHP και προσπαθώ να εφαρμόσω κάτι απλό για να αφομιώσω την λογική του MVC. 

Να ξέρεις βασικά ότι δεν υπάρχει ένας μόνο κανόνας για το πως θα υλοποιηθεί ένα Pattern. Πολλές φορές άλλα λέει η θεωρία και άλλο γίνεται στην πραγματικότητα και αυτό συμβαίνει για αρκετούς λόγους. Είτε γιατί η τεχνολογία μας έδωσε μία καινούρια δυνατότητα είτε γιατί θέλουμε να αυξήσουμε την παραγωγηκότητά μας είτε γιατί η υλοποίηση ενός Pattern σε ένα συγκεκριμένο πρόβλημα απαιτεί να γραφεί αρκετός κώδικας. Οπότε κάπου εκεί έρχεται το νερό στο κρασί και παραβιάζουμε κάποιες αρχές σχεδίασης.

Το βασικό που θα πρέπει να κρατάς από κάθε pattern είναι η θεωρητική του προσέγγιση και ο στόχος του. Το συγκεκριμένο θέλει να σου τονίσει το Separation Of Concerns. Να βάζεις τον κάθε κώδικα εκεί που θα πρέπει να μπει. Το αν το View ενημερώνεται από το Model ή από τον Controller έρχεται δεύτερο. Το να βάλεις όμως κώδικα μέσα στο View που να κάνει την δουλειά του Model είναι λάθος. Πρόσεξε δεν είπα να καλέσεις μία μέθοδο από το Model αλλά να βάλεις αυτούσιο κώδικα που να γεμίζει δεδομένα στο Model.

Το να καλέσεις μέθοδο από το View στο Model είναι ένα debate άλλοι θα πουν σωστό και άλλοι λάθος. Δεν γνωρίζω τι κάνουν στην ASP.Net γιατί ποτέ δεν έχω ασχοληθεί. Αν κρατήσουμε δεδομένο πως η πηγή πληροφοριών μίας εφαρμογής μπορεί να είναι είτε μία βάση, είτε ένα αρχείο είτε ένα Web Service ή ότι άλλο έχει ο κάθε ένας στο μυαλό του τότε θεωρώ λάθος το View να βλέπει το Model και να καλεί μεθόδους από αυτό γιατί τότε παραβιάζουμε και μία άλλη αρχή σχεδιασμού. Αν όμως έχουμε 'κρύψει' το Model πίσω από ένα Interface δεν βρίσκω κάτι λάθος.

Προσωπικά είμαι τις άποψεις οι κλήσεις για το Model να περνάνε μέσα σπό τον Controller όπως επίσης και η επιστροφή των δεδομένων μέσα από αυτόν. Αν το view ενημερώνεται από το Model τότε πως θα μπορέσω να αλλάξω συμπεριφορά ανάλογα με τα δεδομένα που μου έρχονται. Αν για παράδειγμα ζητήσω τις συναλλαγές ενός πελάτη και από τα δεδομένα που έρχονται προκύπτει πως ο πελάτης έχει υπόλοιπο πως θα το δείξω αυτό στην εφαρμογή; Αν δεν είχε υπόλοιπο θα ήθελα να εμφανίσει τις συναλλαγές. Αν έχει να του εμφανίσει το υπόλοιπό του και όχι τις συναλλαγές. Ποιος θα έπαιρνε την απόφαση αυτή αν το View ενημερώνεται από το Model; Είναι καθαρά δουλειά του Controller να το κάνει αυτό.

Βάζοντας λοιπόν τέτοια σενάρια στο μυαλό σου και κρατώντας την βασική αρχή του Pattern θα δεις ότι υπάρχουν πολλοί τρόποι να το υλοποιήσεις χωρίς να παραβιάζεις τον κανόνα του. Όλοι οι τρόποι είναι σωστή αρκεί ο κανόνας του pattern να μην παραβιάζεται και στο συγκεκριμένο είναι το Separation Of Concerns.

Τώρα το αν λέγεται MVC MVP ή και εγώ δεν ξέρω πως, πιο πολύ φιλοσοφική συζήτηση είναι.