Mvc: Where to Put Business Logic

MVC: Where to put business logic?

I prefer to put domain logic in the model for a couple of reasons.

1. The model should have no UI code in it and thus be easier to test. Whenever possible, I like to have a fully working (meaning complete test coverage) model before writing any UI code. The controller can trust that the model is doing the right thing and just deal with UI concerns.

2. If you put domain logic in a controller, it's not as easy to share between different apps, or even between different controllers.

Where to put business logic in spring mvc framework?

@Controller classes serve as C from MVC. Note that the real controller in Spring MVC is DispatcherServlet that will use the specific @Controller class to handle the URL request.

@Service classes should serve for your service layer. Here you should put your business logic.

@Repository classes should serve for your data access layer. Here you should put CRUD logic: insert, update, delete, select.

@Service, @Repository and your entity classes will be M from MVC. JSP and other view technologies(e.g. JSP, Thymeleaf etc.) will conform V from MVC.

@Controller classes should only have access to @Service classes through interfaces. Similar, @Service classes should only have access to other @Service classes and for a specific set of @Repository classes through interfaces.

Where to put Business Logic classes in an Entity Framework - ASP.NET MVC 4 Solution?

You can create different projects according to core functionality.

1. Data Access Layer(DB context and repository etc.) you can make Project.DataAccess, it will have only db context class and repository.

2. Business Logic Layer(Project.Business) it will have business logic and make call to data access layer.

3. UI Layer(Project.WebUi) it is mvc project.
   and so on.

for detail info you can see this http://prodinner.codeplex.com/ code

Business logic layer in ASP.NET MVC - Architecture

Arsen's answer already explained very well, but I just wanted to post my own experiences (and that's too long for a comment.)

Your idea of separating Business logic and DataAcess is good. Most projects I worked on are organized in a similar manner.

What I would do in your case is:

1 - Create a project for DataAcess: MVCProj.DataAcess

2 - Create another project only to contain your database Entities: MVCProj.Entities

3 - Add a reference of MVCProj.Entities in your MVCProj.DataAcessproject

4 - Create a project for your business layer: MVCProj.Business:

5 - Add a reference of MVCProj.Entities and MVCProj.DataAcess in your MVCProj.Business project (I'm assuming business layer will call database)

6 - Add a reference of MVCProj.Entities and MVCProj.Business to your MVC project.

See the logic? Each layer is responsible for doing "its job". Now MVC controllers may call business, wich call the database to save the records. All projects share the same Entities.

The "Models" folder on the MVC project is just an example the team provided. In most examples in the web you see people calling the database (Mainly using Entity Framework) directly inside the controllers. This works, but in the long run is very bad to maintain.

Another thing most people do is: You usually don't want to return your database entities in your controllers. Perhaps they include more properties than you will need and etc. In this case you can create what is called a ViewModel. Think of a ViewModel of something like a copy of your Entity class but only with fields relevant to the View. The ViewModels are specific to the MVC project, so they will stay in a folder inside the MVC project. You may call it Models, or ViewModels, your choice.

Not going much further, but with the separation of projects I showed above you can definetly look for a Dependency Injection framework to handle all the creation of instances of the classes for you. :)

Note: It was implied but all projects except the MVC one are just plain old class libraries.

Hope this helps clarify your ideas.

Where does the business logic go in MVC?

I think you pretty much answered your own question, in a separate project.

Not in the controllers and absolutely not in the models.

Edit: Notice that the controller is highly coupled with the httpcontext so it will be a very smart thing to move the logic layer to a different dll-layer.

Where should I put my controller business logic in MVC3

The recommended place to put business logic is into a service layer. So you could define an interface which will represent the business operation:

public interface IMyService
{
    DomainModel SomeOperation(string input);
}

and then have an implementation of this service. Finally the controller will use it:

public class MyController: Controller
{
    private readonly IMyService _service;
    public class MyController(IMyService service)
    {
        _service = service;
    }

    public ActionResult Create(string input)
    {
        var model = _service.SomeOperation(input);
        var viewModel = Mapper.Map<DomainModel, ViewModel>(model);
        return View(viewModel);
    }
}

and configure your DI framework to pass the proper implementation of the service into the controller.

Remark: In the example I provided I used AutoMapper to convert between a domain model into a view model which is passed to the view.

Where to put business logic when using Entity Framework and ASP.NET

This question is likely to attract opinionated answers. My take on is - yes I would force everything to go through the business library.

To have consistency more than anything else really, this way you can be sure:

• A new member of your team is not trying to understand why some of the DB operations are happening through a different layer compared to other ones.
• When you (or some other developer) are adding / removing functionality that belongs to interacting with DB, the location of it is well known.
• When there's a problem regarding the DB layer / access / queries - simpler to locate the problem.
• If you are testing that layer / methods - we find it to be more convenient to have everything in the same place. (Testability definitely increases) We still split the stuff across files.
• We use Dependency Injection - so if you need DB access, you just inject the interface which sets up the connection for you and you're done.
• Depending on how your setup is, if you're logging DB related stuff separately (monitoring the QoS of queries separately as an example) this also ensures that you don't end up adding that custom logging all over the code for those simple lookups.
• Makes the dependency chain more manageable.

Now - this is not to say that it doesn't get complicated, it does. However there are further ways which you can split things, you don't necessarily need to have a gigantic DBContext class which is handling N number of different queries, depending on our design, we might end up splitting it with partial classes so different functionalities end up on different files, their tests also map to different files; we think this improves overall maintainability.

Business logic in MVC

Business rules go in the model.

Say you were displaying emails for a mailing list. The user clicks the "delete" button next to one of the emails, the controller notifies the model to delete entry N, then notifies the view the model has changed.

Perhaps the admin's email should never be removed from the list. That's a business rule, that knowledge belongs in the model. The view may ultimately represent this rule somehow -- perhaps the model exposes an "IsDeletable" property which is a function of the business rule, so that the delete button in the view is disabled for certain entries - but the rule itself isn't contained in the view.

The model is ultimately gatekeeper for your data. You should be able to test your business logic without touching the UI at all.

Where to write Database and Business logic in MVC?

Business logic should be in the Model.

Data Access can either be its own later your Controllers call, or automated in an ORM that your Controller will call through repositories.

A walk-through covering this can be found in Nerd Dinner, look for the free download section.

---

Related Topics