How to structure an enterprise MVC app, and where does Business Logic go?

Model View Controller sounds like it addresses your 3 tiers, but that's not the case. It really organizes how your UI is put together. The Controller is at the middle, and typically (A) does stuff using Business objects and (B) from Business objects gets the Model objects to pass to the View. The MVC part of your system (the UI functionality) has no idea what's happening on the other side of the business layer. DB? Service calls? Disk IO? Firing lasers? So, MVC-B-? would be an acronym that describes MVC and how it hooks up.

Think of the Controller at the center, with a line going down to the Business objects. The controller will typically get the Model from the Business objects to pass off to the View, but the Model is just data. That's key. The Controller is now the smartest part of the system in a sense, but the Business objects are still the most powerful.

So, the Model objects are a large part of the communication between the Controller and the Business objects. Further, every view has a VM (View Model) object that it takes, that might be a Model, but might be something constructed by the Controller to pass more complicated sets of information to the View.

So, a controller (1) takes data from the client and does stuff with the business objects (if necessary), communicating using model object perhaps, and then (2) get's Model object(s) from a Business object(s), constructs a VM, and gives it to a view (possible several) to render.

At first it really will seems like layers and tiers all over the place, especially since getting into MVC is a good time to increase your use of interfaces (see last 3 or 4 Solid principals) and unit testing. You'll have probably many more files in your project than you otherwise would. Very quickly though you see that is in fact a great way of organizing things.

As this "top" part of the system, the MVC part, we just do not care how the Model objects were constructed or what the Business objects do with them. Don't be surprised of course if your Customer model object happens to look a lot like your Customers db table! This is normal and common. However, your customer Model object and your customer Business object will really have separate lives. It's a good time to consider the Repository Pattern.

Fight temptation to be lazy and put lots of logic into the Controller. Strive at every moment to put concerns in the place where they below. The Controller is just for wiring things up. If a lot of code there is necessary in order to construct an adequate VM for the view to use, this is okay, because this is the controllers job. Too often you see business logic or rendering logic in the controller. Put it where it belongs!

I tried to balance comprehensiveness with brevity, but you asked a huge question!

MVC is not a complete architecture for your needs, it covers only the presentation layer. Your controllers should talk to a business layer an get back Model objects. The business layer can talk to other layers, like database-access, web services, file system, etc.

In my apps, I usually create a "Core" project separate from the web project.

Core project contains:

1. Business objects, such as entities and such
2. Data access
3. Anything that is not specifically designed for web

Web project contains:

1. Controllers, which route requests from the UI to the core logic
2. Views, which focus on presenting data in HTML
3. View Models, which flatten/transform core business objects into simpler structures designed to support specific views

The key point here is that the web-based Models folder/namespace is ONLY used for presentation-specific models that document the specific variables needed for a given view. As much "business logic" as possible goes into the core project.