Where to write Database and Business logic in MVC?

Question

As I am learning and working on Asp.Net MVC application, I want to know that what is the better place to write Business Logic and Data Access logic

Answer 1

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

Answer 2

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)

Answer 3

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.

Answer 4

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