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

Question

I am an MVC newbie. As far as I can tell:

• Controller: deals with routing requests
• View: deals with presentation of data
• Model: looks a whole lot like a Data Access layer

Where does the Business Logic go?

Take a large enterprise application with:

• Several different sources of data (WCF, WebServices and ADO) tied together in a data access layer (useing multiple different DTOs).
• A lot business logic segmented over several dlls.

What is an appropriate way for an MVC web application to sit on top of this (in terms of code and project structure)?

The example I have seen where everything just goes in the Model folder don't seem like they are appropriate for very large applications.

Thanks for any advice!

Answer 1

I tend to put my business logic in services, and call them from the controller, which marshalls data and sends it to the appropriate service.

To have an MVC application sitting on top of this, I would use a facade pattern or something similar, to proxy calls to your existing business logic. So your services are essentially facades just passing data to the existing business logic.

That way, there is a clean break between the existing business logic and your new MVC-based code.

Answer 2

"It Depends" :)

Requests are routed to controllers, which handle them appropriately. Controllers are the "glue" that holds everything else (Models, Views, etc) together. So it is natural that "business logic" would be either processed directly or offloaded to another component by a controller.

Where you actually put the logic depends on your needs. If logic is only needed by a single controller then putting it directly inside of one is fine. Of course, logic might also go into a single model if it is required for data consistency.

Alternatively you can put logic in helper classes/functions, or (as others have mentioned), you can create a services layer for the business logic.

Answer 3

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.

Answer 4

Perhaps this link will help you better understand the Model. They can play the role of a Data Transfer Object or be more in depth as the link describes. However, they shouldn't be your DAL in my opinion. Many examples I see handle the Business logic & DAL with the service & repository patterns.

Check the MVC Contrib Project and the code camp sample to get an example of this.

I also found Rob Conery's eCommerce Storefront and the Northwind MVC starter kit to help.

Answer 5

[M]odel [V]iew [C]ontroller 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 [B]usiness objects and (B) from [B]usiness objects gets the [M]odel objects to pass to the [V]iew. 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 [C]ontroller at the center, with a line going down to the [B]usiness objects. The controller will typically get the [M]odel from the [B]usiness objects to pass off to the [V]iew, but the [M]odel is just data. That's key. The [C]ontroller is now the smartest part of the system in a sense, but the [B]usiness objects are still the most powerful.

So, the [M]odel objects are a large part of the communication between the [C]ontroller and the [B]usiness objects. Further, every view has a VM ([V]iew [M]odel) object that it takes, that might be a [M]odel, but might be something constructed by the [C]ontroller to pass more complicated sets of information to the [V]iew.

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 [M]odel object(s) from a [B]usiness 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 [M]odel objects were constructed or what the [B]usiness 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 [M]odel object and your customer [B]usiness 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 [C]ontroller. Strive at every moment to put concerns in the place where they below. The [C]ontroller 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!

Answer 6

You can use S#arp Architecture to structure your application properly using best practices. There is a comprehensive sample application available at: Who Can Help Me?

Answer 7

IMO this scenario is more suited to something like you'd use in WPF. ViewModel View Controller.

Your controller talks to the business services that perform functions on domain objects. The controller converts data returned from the business services (combining several if needed) into View Models (the "M" in MVC). The View Model is then passed to the View.

The same in reverse to take VM's from the view and sending the data back to the business services

Answer 8

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.