Just began researching mvc, and am not sure I grasp it yet. From what I gather it seems like an implementation of a 3 tier solution ie Model corresponds to DAL, Controller to business logic layer, and View as Presentation layer.
Am I way off base here?
Sort of. It looks like this:
The pattern most commonly used today is:
Database -> DAL -> BLL -> Controller -> View Model -> UI
Where
DAL == Data Access Layer (aka ORM, Object-Relational mapper)
BLL == Business Logic Layer
Note that you don't always need every layer. The BLL and View Model, for example, can be optional if the app is small enough.
You should check out the NerdDinner tutorial. It describes all of these concepts in a single reference.
Some great explanations here if you're new to MVC:
http://stackoverflow.com/questions/390693/does-anyone-beside-me-just-not-get-asp-net-mvc
A short note, you are correct when you say the Controller can (doesn't have to) be the business layer, and the view is the presentation layer.
However the model are the objects (depending on implementation) that contain the data, whereas a data layer is a layer that retrieves/manipulates data.
I caution against treating the Model as simply a data access layer. That's oversimplifying, and it results in you putting too much code into the Controller Layer. It's better if you put more of that code in the Model, and make database persistence only a part of the Model's internal code. I like to think of MVC like this:
This is basically the Page Controller pattern.
Another way to think about it is this: suppose you had to port your web app to another platform, such as a command-line app or a desktop GUI app. What parts of the application logic should you reuse? The Controller and View would change as you port your app to another platform, because the implementation of both input and output would need to change. The code that doesn't need to change should be implemented in your Model.
If you've done the separation of concerns right, then the Model, View, and Controller would be minimally coupled, and you could change the implementation of one without affecting the others too much. If you change the Model and you find yourself rewriting a lot of code in the Controller or the View, you probably haven't separated these layers adequately. And vice versa.
Read about Martin Fowler's Anemic Domain Model antipattern or Domain Driven Design Quickly to get some other perspectives.
Also see my blog from 2008 that I wrote in response to people decrying the Active Record pattern. It got some good comments and discussion.