sliderhouserules:

I'm not super-purist but I would contend that mixing application logic and domain logic violates the defining principles of MVC.

Where did I say I was mixing them?

sliderhouserules:

Using the concepts of Domain Logic and Application Logic, and *not* using the term Business Logic is just something I'm putting forward as a way to help end the confusion that is very prevalent between MVC and typical 3-tier. I find it very effective in helping people understand the "new way of thinking" that MVC brings/requires. I also find it easy to look at any given piece of logic and determine if it is Application or Domain Logic. If someone is involved in design deep enough that they need to know where any given logic is going to reside (they're a developer or an analyst) then they should be able to make that leap of no longer using the term Business Logic. What terminology you use when talking to customers or management or someone who shouldn't concern themselves with implementation is unimportant. You can continue to call things Business Logic all you want when talking to them. I don't see how that should be what drives your design and implementation.

Again, I'm just offering this as a different way of talking about things that aids in putting things where they belong in MVC.

got it.  but you're missing my point.  what I'm saying is that you defined "Application Logic" as "the application, with routing, making decisions about where to direct the user, what (control) objects to create and correspond with", and "Domain Logic" as "has to do with state, with persistence, with validation, with the domain".  In complicated applications, there is logic outside of these bounds.  Take my billing example.  Would you call that "Application" or "Domain" logic?  Or rather, where would you put it in an MVC model?

Cepheus:

I moved my controllers into the business logic assembly where they belong. But to get my MVC running I had to make a little trick: I changed the namespace from my cntrollers to the namespace of the Web Project, otherwise the Views didn't find my controllers. Is there a more elegant way of telling the views where theere controllers are?

Hi Rainer,

I actually like that it is required to be the same namespace.  It makes it that much more apparent that the Controllers are for a specific thing, such as the ASP.NET MVC Framework.  However you can always create your own IController or RouteHandler to accomplish your goal of a different namespace.
 

davethieben:

Take my billing example.  Would you call that "Application" or "Domain" logic?  Or rather, where would you put it in an MVC model?

I would need some more details about your system to be able to answer that in any constructive way. Are you building MVC systems with your "lump of business rules" or are you building 3-tier systems? Cause they're not the same. 3-tier has been overly prevalent for a long time. MVC has only made a recent comeback (in the mainstream that is... I know lots of people have been building MVC stuff the whole time). Business rules/logic is, in my opinion, specific to 3-tier. Or it has at least been morphed by 3-tier to have a meaning that doesn't really fit MVC anymore (I don't have my GoF book handy to make a quick perusal to see if they used that term when defining MVC back then). Semantics are semantics, but MVC has some very clear guidelines on what C really means, and what M really means. I have my labels for that, and others may like them or not (that's semantics) but I'm just applying my labels to what this application design pattern says to do. I can change my terminology to Controller Logic and Model Logic, but they will still have the same attending definitions.

Controllers control your application.

The Model maintains state.

Everything else is just elaborations on what those simple (maybe overly simplified) points really mean, or how to apply them. 

The semantics discussion has thoroughly derailed this thread . To try to get it back on track:

nberardi:

I actually like that it is required to be the same namespace.  It makes it that much more apparent that the Controllers are for a specific thing, such as the ASP.NET MVC Framework.  However you can always create your own IController or RouteHandler to accomplish your goal of a different namespace.

1. Create a new MVC application
   
2. Add a new Class Library project called Controllers
   
3. Copy the HomeController.cs file to the Controllers project (VS2008 automatically changed the namespace of the file for me when I did this, open the file to verify)
   
4. Delete the HomeControllers.cs file from the Web project
5. Add a reference to System.Web.Extensions.dll in the Controllers project
6. Add a project reference to the Controllers project in the Web project
7. Set the Web project as the Startup Project
8. Set Default.aspx as the Start Page
9. Hit F5

It works just fine.