Though MVC comes in different flavors, control flow is generally as follows:

1. The user interacts with the user interface in some way (for example, presses a mouse button).
2. The controller handles the input event from the user interface, often via a registered handler or callback and converts the event into appropriate user action, understandable for the model.
3. The controller notifies the model of the user action, possibly resulting in a change in the model's state. (For example, the controller updates the user's shopping cart.)[6]
4. A view queries the model in order to generate an appropriate user interface (for example, the view lists the shopping cart's contents). The view gets its own data from the model. In some implementations, the controller may issue a general instruction to the view to render itself. In others, the view is automatically notified by the model of changes in state (Observer) which require a screen update.
5. The user interface waits for further user interactions, which restarts the cycle.

4. A view queries the model in order to generate an appropriate user interface (for example, the view lists the shopping cart's contents)

General principle that we must consider if want to build N-tier application:

• Every layer must be independent physically. It doesn't mean every layer have to exist in separated computer. But, every layer can be distributed every where (separated computer or not).
• Each layer must transfer information only to/from previous/next layer.
• You can change technology used in every layer without change entire system. Example, - you want to change database layer- from mySql to PostgreSQL.

Following sample architecture design use 5-tier:

• Presentation GUI, do parse HTML, XHTML, WML.
• Presentation Logic do rendering process HTML, XHTML to send using HTTP to browser. It accepts data from business logic and tie to HTML. This process run at php at web server.
• Business Logic, manipulate and transform data. Simple, task of this layer is fetch data from data access tier and prepare before send to presentation logic. This process run at server that utilize XML.
• Data access tier have task to connect and retrieve data from database.
• Data tier is aplication database such as mySQL, PostGreSQL, and others.

mmix:
Postoji konceptualna razlika, u nlayer/tier modelu nema preskakanja layer/tiera

mmix:
ono sto ti zoves POCO objektom iz domain modela je BL (logical) objekat u n-tier modelu

mmix:
presentation layer nikad ni pod kojim uslovima ne komunicira direktno sa data layerom

mmix:
3. Business Logic - Controller, a dodatno može imati više slojev

klasicna greska. Controler NIJE zamena za business layer, izgleda primamljivo i ljudi trpaju gluposti tamo ali controller nije mesto gde se smesta ta logika.

3) komunikacija se vrši samo između susednih slojeva

mmix:
E jbg, ne znam kako da ti dalje pojednostavim, imas sendvic sa sunkom i kad stavis sunku izmedju dva parceta hleba hlebovi se ne dodiruju, jedan cak ni ne zna da drugi postoji. Model, View i Controller svi znaju jedan za drugi, da je View takav da nikad ne poziva model direktno vec da koristi model KROZ controller onda bi bio layered/tiered

mmix:
(ali onda bi ceo MVC bio bezvredan i observer patern bio bio prakticno nemoguc).

mmix:
MVC NIJE layered/tiered arhitektura.

mmix:
Bice da te mozda ovo zbunjuje. To je potreban ali ne i dovoljan uslov, pored ovoga potrebno je da dva layera koja komuniciraju kroz treci (ili lanac trecih) NEMAJU direktnu komunikaciju. Potpuna i kompletna separacija.

Pa to i jeste problem. Ako je meni model poseban assembly, koji nema nikakvu predstavu o View-u (referencu, interfejs, bilo šta...), kako on može direktno da komunicira sa View-om? Nikako. Samo preko kontrolera. Šta više, model kao takav mogu da koristim bilo u desktop, bilo u web aplikacijama.

Valerij Zajcev:
Radio sam na projekatu gde je bila n-tier aplikacija apli je je GUI odradjen kao MVC. Sto je krivicno delo silovanja programera koji to mroa da cita :)

Citat:
Valerij Zajcev:
Radio sam na projekatu gde je bila n-tier aplikacija apli je je GUI odradjen kao MVC. Sto je krivicno delo silovanja programera koji to mroa da cita :)


Ako je time postignut anti-pattern, tako što u aplikaciji nije bilo potrebe za tim - onda je to pogreška arhitekte; ali u mome mišljenju bilo šta srednje i više komplikovano ima ogromne benificije ako se uradi kao neka MVC varijacija (zavisno od tehnologije u upotrebi). Čak i za najjednostavnije stvari meni je logično da pravim Mediator i Strategy objekte, te generičke forme sa form generatorima.
Što se MVC-a tiče, ne vidim zašto bi to bilo teško za čitanje - osim nekome ko ne shvata ni svrhu pattern-a?