Where to write Database and Business logic in MVC?

As I am learning and working on Asp.Net MVC application, I want to know that what i开发者_如何转开发s the better place to write Business Logic and Data Access logic in MVC.

Where should I write DataAccess and Business Logic among three layers (Model, View and Controller) ??

Could anybody please tell me the correct way to write the code for this.

Scenario: I want to retrieve all the employees where employee name like 'Mi%' ( I have SQL procedure to execute and retrieve the data.)

PS: Want to know that where I should create instance of Business Logic class and where I should create instance of Data Access layers class?

Thanks in advance.

Business logic (BL) and data access (DAO) should be in separate layers. Models should only keep data and contain no logic. Controller should only receive data from view and send it to BL layer (or send from BL to view).
It's not a strict rules, but most recently used approach

Business logic should be in the Model.

Data Access can either be its own later your Controllers call, or automated in an ORM that your Controller will call through repositories.

A walk-through covering this can be found in Nerd Dinner, look for the free download section.

The view is where you put your interface code.

The Controller is the place that connects the view with the model.

The model stores business logic and possibly database access. (Some ORM Layer can be used aswell)

You could skip the three tier thinking completely and go for another way of thinking;

User Acts; that sends Command or Event to Background Service. Background Service you can run in process, for starters. Background Service publishes events, again, in memory. You create multiple Views that subscribe the Event from the Background Service. Each View has a 'last seen' Event; it's an integer. Each Start it reads all later Events from the "global log".

Views are throw-away, because you have a global log of Event/Command from GUI and from Background Service, and they'll read up all missed events when you start, anyhow.

This is the equivalent of "do something and I expect to see that 'change' in this other view". You also have:

An Interaction is when you have a single or multiple Events from either GUI or Background Service and you let some actor, most likely a Saga, perform some action, possibly with compensations based on other Events, should the action fail.

Also, I can recommend browsing this presentation