@bpaluzzi okay, I can understand what you're saying about persistant storage being "part" of business logic...but are you also saying that business logic includes both data and controller code? I thought business logic was referring to logic that manipulates data. Am I mistaken in this? What's the deals @bpaluzzi? I'm open to learning something new. School me oh wise one
MVC is a bit weird, because there are a bunch of ways to break it down -- they can all pretty much be reduced down to two main types: thin controller / fat model, and fat controller / thick model. The "thickness" of the controller determines how much logical code is in there:
in a thin controller schema, the controller tends to be very "functional", for example:
-handling requests from the view (via GET or POST, in a web application, for example) which are then converted into calls to the business logic layer in the model
-the "brains" behind view-specific functionality (for example, setting up meta data for a webpage)
in this type of a setup, all of the business logic is contained within your model classes - for example, you'd have a Widget class, with a "processOrder()" function. the view draws a button, which is clicked + initiates a POST back to the server. the controller interprets the POST request, creates your Widget object, and calls Widget->processOrder(). All of the logic for what "process order" is can be abstracted away within the model class -- the controller just acts as the wiring, without any specific domain knowledge.
In a "thick controller" setup, your model acts simply as the data store. It's the business logic in so far as the schema for the database determines the relationships present within your data -- a Blog contains many Posts, which each contain zero or many Articles, which are related to an Author, etc. The controller handles all of the manipulation of this data. This type of set-up generally works where the business logic is simple CRUD operations -- the HTTP request types map almost exactly to operations on your model (POST->UPDATE, GET->SELECT, etc.), so there's not much point to wire the view's request to a full class/object backend. The controller class can just pass that right along to the backend. A straightforward blog / CMS can be a great example where this type of pattern works well.
There is, of course, a whole degree of gray in between these extremes. Martin Fowler brings up the point that in a lot of cases, the separation between view and controller is unnecessary (this would be more for a fat model set-up, where you're fundamentally separating two big chunks: business logic and presentation logic). In a lot of cases, this is what you see in medium-sized PHP projects -- the controller logic lives in the actual PHP files being loaded via .htaccess, while the "view" is reduced to a template by something like Smarty or Zend.
MVC is such a nebulous term that you'd be hard pressed to find a "wrong" way to do it -- there are certainly anti-patterns out there, or ways that will make it more difficult, but in general, any logical treatment given to separation of concerns is going to help make your code better.
Back to your original point -- I was perhaps too harsh on calling it "incorrect" -- it's a valid way to set up an MVC project, but not the only way. It's an implementation, instead of the whole view of the theory.
Wow, this is REALLY scattershot and confusing, so sorry if I opened up more questions than answers here. I'm cooking dinner and waiting for my oven to pre-heat, so I banged out something quickly.
For some more references, the Krasner + Pope is fantastic -- that's the first rigorous academic treatment of the MVC framework that had been kicking around XEROX PARC since the 70s. "Patterns of Enterprise Application Architecture" by Fowler is also good.
