4.5 Model

1. Business Logic in Model

In ASP.NET MVC, it’s a best practice to handle business logic in the model (or a separate service layer), keeping the controller focused on routing, handling user requests, and orchestrating the flow of data between the model and the view. Here’s an example where business logic is handled in the model rather than the controller:

1.1 Model with Business Logic

Create a model that encapsulates business logic. In this case, let’s assume a simple order system where the business logic calculates the total price of an order including a discount if the customer is eligible.

public class Order
{
    public List<OrderItem> Items { get; set; }
    public Customer Customer { get; set; }

    public Order()
    {
        Items = new List<OrderItem>();
    }

    // Business logic to calculate the total price including discount
    public decimal CalculateTotalPrice()
    {
        decimal total = Items.Sum(item => item.Price * item.Quantity);

        // Apply a 10% discount if the customer is eligible
        if (Customer.IsEligibleForDiscount())
        {
            total *= 0.9m;
        }

        return total;
    }
}

public class OrderItem
{
    public string Name { get; set; }
    public decimal Price { get; set; }
    public int Quantity { get; set; }
}

public class Customer
{
    public string Name { get; set; }
    public bool IsPremium { get; set; }

    // Business logic to check if the customer is eligible for a discount
    public bool IsEligibleForDiscount()
    {
        return IsPremium;
    }
}

Controller

In the controller, there is no business logic. It simply orchestrates the flow of data by passing the model to the view.

public class OrderController : Controller
{
    public ActionResult Index()
    {
        var customer = new Customer { Name = "John Doe", IsPremium = true };

        var order = new Order
        {
            Customer = customer,
            Items = new List<OrderItem>
            {
                new OrderItem { Name = "Item 1", Price = 100, Quantity = 2 },
                new OrderItem { Name = "Item 2", Price = 50, Quantity = 1 }
            }
        };

        // Notice there's no business logic here; just calling the model's method
        decimal totalPrice = order.CalculateTotalPrice();

        ViewBag.TotalPrice = totalPrice;
        return View(order);
    }
}

View

In the view, you simply display the data:

@model Order

<h2>Order for @Model.Customer.Name</h2>
<ul>
    @foreach (var item in Model.Items)
    {
        <li>@item.Name - @item.Quantity x @item.Price</li>
    }
</ul>

<p>Total Price: @ViewBag.TotalPrice</p>

Explanation

• Business Logic in the Model: The Order model contains the logic for calculating the total price (CalculateTotalPrice) and applies a discount if the customer is eligible. The Customer model also contains the logic to determine eligibility for the discount.
• Controller Focus: The controller is lean and only responsible for instantiating models, passing data between the view and model, and returning the appropriate view. There’s no business logic here.

Benefits

• Separation of Concerns: The business logic (calculating the total price and discounts) is encapsulated within the model, making it easier to maintain, test, and reuse.
• Controller Simplicity: The controller’s role is minimal, making it easier to manage request handling and routing without embedding complex logic.

This approach keeps the system scalable, maintainable, and follows the MVC pattern correctly.

1.2 Business Logic in Controller?

In general, the model should encapsulate business logic, while the controller should focus on routing, request handling, and passing data between the model and the view. This ensures proper separation of concerns, which leads to a more maintainable and scalable codebase. However, there are cases where some logic in the controller is acceptable. Here’s a more detailed breakdown:

1. Best Practices: Business Logic in the Model

The model (or a dedicated service layer) should typically handle all business logic, including:

• Calculations (e.g., pricing, discounts, totals)
• Data validation
• Business rules (e.g., checking inventory, applying business-specific rules)
• Managing state changes (e.g., updating records)

By keeping business logic in the model:

• Reusability: The logic can be reused across different controllers or even in different applications.
• Testability: Business logic in models or service layers can be unit tested more easily.
• Maintainability: It helps in making code cleaner and ensures that business rules are centralized in one place, making future changes simpler.

2. When Can Controllers Have Business Logic?

While it is ideal to keep controllers light, there are cases where limited logic in controllers may be acceptable:

• Orchestration Logic: Controllers often contain orchestration logic—combining data from multiple models or services. This is still different from business logic (e.g., pulling data from a service, merging results, and then passing the data to the view).

• Request-Specific Logic: If the logic pertains directly to HTTP requests or responses (e.g., checking for specific query parameters, handling authentication/authorization), it can reside in the controller.

  Example:

  if (!ModelState.IsValid)
  {
      return View("Error");
  }

3. Examples of Business Logic in the Model vs. Controller

3.1 Business Logic in the Model (Recommended)

public class Order
{
    public List<OrderItem> Items { get; set; }
    public Customer Customer { get; set; }

    // Business logic to calculate total price
    public decimal CalculateTotal()
    {
        return Items.Sum(item => item.Price * item.Quantity);
    }

    public bool IsEligibleForDiscount()
    {
        return Customer.IsPremium;
    }
}

Controller (Simple Orchestration):

public ActionResult Checkout()
{
    var order = new Order { Items = GetOrderItems(), Customer = GetCustomer() };
    var total = order.CalculateTotal();

    if (order.IsEligibleForDiscount())
    {
        // Apply discount logic in the model
        total *= 0.9m;
    }

    ViewBag.Total = total;
    return View(order);
}

3.2 Small Amount of Logic in Controller (Not Ideal, but Acceptable)

For request-specific tasks, you might occasionally place some logic in the controller:

public ActionResult PlaceOrder()
{
    var order = new Order { Items = GetOrderItems(), Customer = GetCustomer() };

    // Minor request-specific logic
    if (order.Items.Count == 0)
    {
        return RedirectToAction("Cart");  // Edge case handled in controller
    }

    var total = order.CalculateTotal();

    if (Request.QueryString["promo"] == "DISCOUNT10")
    {
        // Simple logic like this could be in the controller
        total *= 0.9m;
    }

    ViewBag.Total = total;
    return View(order);
}

When Business Logic in the Controller Is a Bad Idea

If your controller starts handling too much business logic (like price calculations, data validation, or applying discounts), it leads to:

• Code duplication: If you need the same logic elsewhere (e.g., another controller), you’ll have to duplicate it.
• Difficulties in unit testing: Business logic in controllers can be harder to test in isolation.
• Tightly coupled logic: This reduces the flexibility of your application, making it harder to evolve.

Service Layer: A Middle Ground

A common approach is to introduce a service layer that sits between the controller and the model. The service layer handles the business logic, and the controller uses the service to interact with the model.

Example: Service Layer for Business Logic

public class OrderService
{
    public decimal CalculateOrderTotal(Order order)
    {
        decimal total = order.Items.Sum(item => item.Price * item.Quantity);

        if (order.Customer.IsPremium)
        {
            total *= 0.9m; // Apply 10% discount for premium customers
        }

        return total;
    }
}

Controller using the Service Layer:

public ActionResult Checkout()
{
    var order = new Order { Items = GetOrderItems(), Customer = GetCustomer() };
    var orderService = new OrderService();

    var total = orderService.CalculateOrderTotal(order);
    ViewBag.Total = total;

    return View(order);
}

Tip

• Model: Encapsulates business logic like calculations, state changes, or business rules.
• Controller: Handles request/response logic, routing, and uses the model (or a service) to process business logic.
• Service Layer: For complex applications, a service layer can handle business logic and keep both models and controllers simpler.

In general, strive to keep business logic out of controllers whenever possible for maintainability, scalability, and testability reasons.

2. Using Multiple Models in View

In ASP.NET MVC, you can pass multiple models to a view in several ways. Here are three common approaches:

1. ViewModel Approach

Create a new class that acts as a ViewModel, which holds all the data you need from multiple models.

public class MyViewModel
{
    public Model1 Model1Data { get; set; }
    public Model2 Model2Data { get; set; }
}

Then in the controller:

public ActionResult MyAction()
{
    var viewModel = new MyViewModel
    {
        Model1Data = db.Model1Data,
        Model2Data = db.Model2Data
    };
    return View(viewModel);
}

In the view:

@model MyViewModel

<h2>Model 1</h2>
@Html.DisplayFor(m => m.Model1Data.Property)

<h2>Model 2</h2>
@Html.DisplayFor(m => m.Model2Data.Property)

2. Tuple Approach

You can use a Tuple to pass multiple models to a view.

In the controller:

public ActionResult MyAction()
{
    var model1 = db.Model1Data;
    var model2 = db.Model2Data;
    var tuple = Tuple.Create(model1, model2);

    return View(tuple);
}

In the view:

@model Tuple<Model1, Model2>

<h2>Model 1</h2>
@Html.DisplayFor(m => m.Item1.Property)

<h2>Model 2</h2>
@Html.DisplayFor(m => m.Item2.Property)

3. ViewData or ViewBag Approach

Use ViewData or ViewBag to pass multiple models.

In the controller:

public ActionResult MyAction()
{
    ViewBag.Model1 = db.Model1Data;
    ViewBag.Model2 = db.Model2Data;

    return View();
}

In the view:

<h2>Model 1</h2>
@Html.DisplayFor(model => ((Model1)ViewBag.Model1).Property)

<h2>Model 2</h2>
@Html.DisplayFor(model => ((Model2)ViewBag.Model2).Property)

Tip

Each approach has its use cases, but the ViewModel approach is generally preferred for better maintainability and type safety.

3. Simple Example

To pass a list of numbers as the model to a view in ASP.NET MVC, you can simply create a list in your controller and pass it to the view. Here’s how you can do it:

1. Controller

In your controller action, create a List<int> (or any other numeric type) and pass it to the view.

public ActionResult MyAction()
{
    List<int> numbers = new List<int> { 1, 2, 3, 4, 5 };
    return View(numbers);
}

2. View

In the view, set the model to List<int>, then you can loop through the list and display the numbers.

@model List<int>

<h2>Numbers List</h2>
<ul>
    @foreach (var number in Model)
    {
        <li>@number</li>
    }
</ul>

This will render a list of numbers in the view as an unordered list.

Output Example

Numbers List
- 1
- 2
- 3
- 4
- 5