The relationship between Model, View and Controller make me confused.

This topic shows an arrow form View to Controller, an arrow from Controller to Model and an arrow from Model to View: http://www.codeproject.com/Tips/31292/MVC-v-s-MVP-How-Common-and-How-Different

However, this topic shows a dual-arrow between Model and View; a dual-arrow between View and Controller ; and an arrow from Controller to Model: http://www.codeproject.com/Articles/288928/Differences-between-MVC-and-MVP-for-Beginners

Finally, this topic shows an arrow from View to Model, an arrow from Controller to Model and an arrow from Controller to View: http://www.w3schools.com/aspnet/mvc_intro.asp

I have some questions:

1. Which relationships are correct?
2. Business Logic should be handled in Controller or Model? I've read somewhere that the business logic shouldn't be placed in Controller (ASP.Net MVC)
3. In case the controller pass an object to a view, is this object belonged to Model?
4. How does the view retrieve data directly from model? Does it have the reference directly to model or it interact with the model coming from Controller?

I find all of the images you're linking to confusing. This image (taken from Wikipedia) explaines it best.

How It Works

MVC considers three roles. The model is an object that represents some information about the domain. It's a nonvisual object containing all the data and behavior other than used for the UI.

The view respresents the display of the model in the UI. Thus, if our model is a customer object our view might be a frame full of UI widget or an HTML page rendered with information from the model. The view is only about display of information; any changes to the information are handled by the third member of the MVC trinity: the controller. The controller takes user input, manipulates the model, and causes the view to update appropriately. In this way UI is a combination of the view and the controller.

-- Quoted from Patterns of Enterprise Application Architecture by Martin Fowler

Your questions

1. MVC is about separation of concerns, not about relationships.
2. Business Logic should be in the model. The controller is only for interacting with the user.
3. Yes (most likely)

4. Typically the view fetches the necessary information from the model. When using passive views, objects (from the model) are passed from the controller. Important is that the view only reads from the model and never writes/updates it.

   The View observes and responds to changes in model. The model is the Domain Model rather than an individual recordset or entity.

Errata

How MVC is commonly used in the present time differs from the original MVC pattern as it was coined by Martin Fowler. He based this pattern in Smalltalk.

At the heart of MVC, and the idea that was the most influential to later frameworks, is what I call Separated Presentation.

Another part of MVC is how the model, view and controller interact.

In this case all the views and controllers observe the model. When the model changes, the views react.

This is very different from MVC as made popular by Ruby on Rails, where the controller is responsible for preparing and loading the view.

class ArticlesController < ApplicationController
  def create
    @article = Article.new(article_params)

    if @article.save
      redirect_to @article
    else
      render 'new'
    end
  end

Martin Fowler condenses MVC down to this

• Make a strong separation between presentation (view & controller) and domain (model) - Separated Presentation.
• Divide GUI widgets into a controller (for reacting to user stimulus) and view (for displaying the state of the model). Controller and view should (mostly) not communicate directly but through the model.
• Have views (and controllers) observe the model to allow multiple widgets to update without needed to communicate directly - Observer Synchronization.

-- Quoted from GUI Architectures by Martin Fowler