Controllers handle application flow, so where does my business logic go?

Question

I will begin this question by admitting I am very new to MVC. The design pattern makes sense to me at a high level, but now that I'm exploring ASP.NET MVC, some of the architectural pieces are challenging my preconceived notions. Learning is a good thing.

I've been working with Oxite lately as a learning tool written by people at the company that created ASP.NET MVC and thus, an ostensible reference application for ASP.NET MVC.

But today I saw a blog post about Oxite by Rob Conery that says:

One of the things that the Oxite team decided to do was to separate the Controllers and Views into another Project for what I can only assume is the separation of business logic from view logic. This can lead to some confusion since Controllers are meant to handle application flow - not necessarily business logic.

This has thrown me for a loop. Is this separation a tenet of MVC and thus a mistake by the Oxite developers, or is it Rob's opinion? If the business logic belongs in the model, why did the Oxite team put it in the controller? How do I execute an action that is business logic if not in the controller?

Further to that, am I making a mistake using Oxite as a learning benchmark considering comments like Rob's?

Answer 1

Your business logic goes in your business layer. The controllers use the business layer to create a model for your views to render. A good example is the MVC Storefront application that Rob Conery has produced. Oxite is currently getting lots of bad press as it apparently does not make good use of the MVC framework.

The reason that you want a business layer that is separate from your controllers is you may want to reuse the business layer across multiple controllers, or even multiple applications. An example of this would be normal user functions for displaying data, and administrative function for updating and adding data. You may make use of the same BL components in both cases but have different controllers and views to render to the data. Model objects would be the same.

Answer 2

You could implement your business layer (i.e. the Model) with your entities, aggregates, repositories, and services. The services call the repositories, which pull data from your DAL in the form of entities.

This can be set in a single, seperate project which is nothing more than a DLL.

Next, have your MVC App, which is really your Presentation layer, and have it utilize your business layer project. the controllers will work with your Services, and pump the data those Services generate into ViewData which is then pumped into your Views.

The controllers should only deal with routing concerns, such as which views to display, based upon user input from forms, querystrings, cookies, sessions, etc.

there has been an uproar from the "MVC purists" community about the validity of Oxite being used an a good MVC example. The bottom line is, business logic should not be contained in controllers, which I am sure you will see as Oxite gets refactored over the coming months.