Entirely separate business logic layer from MVC

Question

We are currently refactoring our controller methods in ASP.NET MVC application.

At the beginning we've separated data access layer (our goal was to remove LINQ from controllers entirely). Now we are thinking about another step - how to create a business logic layer to reduce number of lines and logic in controller. Currently we have something like this:

public ActionResult CustomerProjects(some parameters)
{
    var collectionOfSomeType = this.CustomerRepository.GetSomeData();
    var anothercollection = this.ProjectsRepository.GetAnotherData(collectionOfSomeType);

    var viewModel = CreateSomeViewModel(anotherCollection);

    return View("Index", viewModel);
}

Of course it's just an example with four lines of code. We have some methods which are bigger (but still IMO not so bad). We injected our helper classes through IoC container, more complex logic sits there. But now we'd like to remove even that parts.

Is it worth our time to create another layer which would be our 'last gate' before controllers? The final result would be:

public ActionResult CustomerProjects(some parameters)
{
    var viewModel = someSource.PrepareCustomerProjectsViewModel(params);

    return View("Index", viewModel);
}

What do you think?

Answer 1

For me there is no question to be answered here, you should always strive to separate out your components as much as possible.

At a bare minimum, for every new project I create I do the exact following steps:

• 1) Create a blank visual studio solution
• 2) Add an MVC project to it
• 3) Add a class library to it called the Business layer
• 4) Add a class library to it called the Data layer

By doing this your following the good principles of n-Tier design. Add into this some form of AOP (For example post-sharp or MVC Attributes) to handle any elements that are cross-cutting the layers, and you have a good solid architecture to work from.

NO RAW Data from your data layer should ever make it into your presentation layer (The MVC App) everything should be combined and flattened in your business layer.

The business layer should only ever handle DTO objects between itself and presentation, with raw data that it brings in from the data layer and then applies various rules too that are specific to your application domain.

With EF code first, and Nu-get packages such as auto-mapper, all of this is incredibly easy these days.

Use EF in your DAL to get your data using Linq, ADO or whatever you need.

Use auto-mapper to transform that data into DTO's to be passed to the business layer, then do any work you need before finally using auto-mapper to pass the resulting DTO up to your presentation.

Even if your NOT using MVC, adopting this strategy is win/win , even for WPF, Webforms, Winforms and much more.

If you do it correctly then the MVC portion essentially becomes a brain dead display of what the business layer is doing, and the ease with which you can remove your MVC app and put another UI on in it's place is frighteningly simple.

Update 14/11/2014

After reading the most recent comment added to this thread, I felt that adding this additional part to my answer was well warranted.

Good Architecture is about much more than just "Pretty Code".

If you get your architecture wrong it can be the difference between crashing and burning and flying high in a blaze of glory.

I've been doing I.T & Software development in one form or another now since about 1979, and believe me I've seen my fair share of failures and successes in that time.

When I first started, and I was still wet behind the ears, Object Oriented Programming wasn't even a thing, you lumped EVERYTHING into one source file, then you ran it through a compiler, then a linker with no kind of GUI stuff to help you.

Some of the code I wrote during these times, was incredibly messy, inefficient and completely horrible. As I grew, and learned however, I began to understand why this kind of code caused the problems it did, and while writing nice easy to read code is certainly an important skill, it's also very important to make sure that your surface area is also minimal and follows good standards.

I've seen so many great projects fail (or at the very least struggle greatly) over the years, and each time it's been because of bad choices made at the architecture design level, I can't stress just how important it is to get the design and the plans right before you even touch a single line of code.

And while I'm on the subject, code generators are just as dangerous. If your code generator creates code from templates that YOU control, then great guns, but IF you depend on templates, where you have no control over how the output is generated, then your asking for trouble. Visual Studio is a great tool, and amazing for creating fast solutions, but please make sure you know EXACTLY what it's creating behind the scenes when you click that button to do something.

If I get a library to develop against, the last thing I want to do, is to have to delve into the sources to tell me how it works, I depend on the architect who designed it, to guide me, by making logical choices, that are formed from a knowledge of great solid software craftsmanship practices.

I simply wouldn't trust anything that passed strings and discreet values around as though they where candy at a Christmas party, because... well how can I be sure what the type and responsibility of the variable/property/method actually is.

Who would you trust more to buy a house off? A professional company who hired an Architect to survey, plan and design a complete set of plans, which a professional team of Builders, Roofers, Plasterers etc then worked as a team to implement, or the guy that lives at the end of your street who works in the building trade and knows a thing or two about building houses?

I know which my choice would be.

Answer 2

It is old thread, but I would like to add following in favor to add BusinessLogic or Management Layer:

• It will help you remove redundant code like object transformation, and required rules checking.
• It will make code reusable and will help you over situations like: you have to provide same data in Web API and Action Method with View or other application.
• It will be very helpful if you like to apply data caching in future.
• It will make your code easy to test.

Answer 3

My preferred responsibility by object:

Controller handles the building of the viewmodel/viewbag.

Logic unrelated to the rendering of the page gets shipped off to the BL.

Thus personally I would compose the viewmodel within the controller, and not create a separate layer. The layer that you would create to compose the viewmodel, what would you call it? The Controller layer?

Answer 4

It doesn't seem to me these layers are really separate unless they are different applications entirely.

Though the idea of separate classes like BL and DAL etc sounds good, I rather think the UI should only handle UI functions and receive from the BL only strings and numbers in an expected order to be passed into the appropriate controls.

The BL can receive petitions from the UI, but I think those could be passed straight to the DAL if they are only retrievals and upon editing the UI can send just the edited strings and numbers back to the BL for reinsertion to the DAL. Working that way the DAL would be data only and its language only transaction language.
The BL can then work with the requested information to validate and format it as new strings with the appropriate data typing etc. for example the phone number from the DAL goes to the BL as a string of numbers and the BL re-formats it to the (areaCode)sector-number.
Any further formatting as in color, fonts and the like happens in the UI. The BL would be the only app dealing with logical classes and the UI app would only need presentation classes and objects. The DAL only needs to transact.

This makes it possible to make truly modular programs where UI, BL, and DAL are independent. It is a way to give customers options to buy apps from developers like buying custom car parts. You can buy the performance parts (BL) from one company and the body dress ups from another company and they will all bolt together.