MVC Architecture and Enterprise Patterns

# CHAPTER 18

MVC Architecture and Enterprise Patterns #

1. Introduction #

2. Learning Objectives #

• Define the specific responsibilities of the Model, View, and Controller.

• Architect an HTTP request lifecycle through the MVC layers.

• Identify the "Fat Controller" anti-pattern and its dangers.

• Implement a Service Layer to encapsulate core business logic.

• Utilize Data Transfer Objects (DTOs) to safely pass data between boundaries.

3. The MVC Architecture #

• The Model (Data & Logic): Represents the data and the rules that govern access to it. It communicates with the database (often utilizing the Repository pattern). It knows *nothing* about the UI.

• The View (UI/Presentation): The visual representation of the data (HTML/CSS/JSON). It requests data from the Model and displays it. It contains zero business logic.

• The Controller (The Traffic Cop): Receives the user's input (an HTTP request), processes it, commands the Model to update the data, and finally commands the View to render the response.

4. The Request Lifecycle #

1. 1. User requests GET /profile/5.

1. 2. The Router sends the request to the UserController.

1. 3. The Controller asks the UserModel for data: Model->find(5).

1. 4. The Model queries the database and returns the User object.

1. 5. The Controller passes the User object to the profile.html View.

1. 6. The View renders the HTML and sends it to the user's browser.

5. The "Fat Controller" Anti-Pattern and The Service Layer #

• The Problem: A CheckoutController contains 500 lines of code to validate a credit card, calculate tax, deduct inventory, and send emails. This logic is trapped in the controller. If you want to trigger a checkout from a CLI script or a cron job, you cannot reuse it.

• The Solution (The Service Layer): You extract the business logic into a dedicated CheckoutService class. The Controller shrinks to 3 lines of code: it receives the HTTP request, passes it to the Service, and returns the View. The Service handles the heavy lifting, becoming fully reusable and testable.

6. Data Transfer Objects (DTO) #

• The Problem: If the Controller passes raw $_POST array data to the Service, the Service has no idea what variables are actually in the array. This causes errors and makes the code unreadable.

• The Solution (DTO): A DTO is a dumb, simple object containing only properties (no logic). The Controller maps the raw HTTP request into a strongly typed UserRegistrationDTO(name, email, password). It passes the DTO to the Service. The Service now has a predictable, secure object to work with.

7. Diagrams/Visual Suggestions #

[ HTTP Request ] 
       |
       v
[ Router / Controller ]  <-- (Creates DTO from Request)
       |
  (Passes DTO)
       v
[ Service Layer ]        <-- (Core Business Logic)
       |
  (Uses Interfaces)
       v
[ Repository (Model) ]   <-- (Database Abstraction)
       |
       v
[ Actual Database ]

8. Code Example (PHP) #

<?php
// --- 1. The DTO (Data Transfer Object) ---
class RegistrationDTO {
    public $email;
    public $password;
    
    public function __construct($email, $password) {
        $this->email = $email;
        $this->password = $password;
    }
}

// --- 2. The Service Layer (Business Logic) ---
class RegistrationService {
    private $userRepo;

    public function __construct(UserRepository $repo) {
        $this->userRepo = $repo;
    }

    public function execute(RegistrationDTO $dto) {
        // Business rule validation
        if (strlen($dto->password) < 8) {
            throw new Exception("Password too short.");
        }
        // Save using repository
        $this->userRepo->save($dto->email, hash(&#039;sha256', $dto->password));
        return true;
    }
}

// --- 3. The Controller (The Traffic Cop) ---
class UserController {
    private $registrationService;

    // Inject the service
    public function __construct(RegistrationService $service) {
        $this->registrationService = $service;
    }

    // Handles the HTTP POST request
    public function registerAction($requestData) {
        try {
            // 1. Map raw request to a safe DTO
            $dto = new RegistrationDTO($requestData[&#039;email'], $requestData['password']);
            
            // 2. Pass DTO to the Service Layer
            $this->registrationService->execute($dto);
            
            // 3. Return the View (Success)
            echo "View: Registration Successful Page HTML\n";
        } catch (Exception $e) {
            // 3. Return the View (Error)
            echo "View: Error Page - " . $e->getMessage() . "\n";
        }
    }
}

// --- Mock Execution ---
$service = new RegistrationService(new MockUserRepository());
$controller = new UserController($service);

// Simulating an incoming HTTP POST request
$fakeHttpRequest = [&#039;email' => 'test@test.com', 'password' => 'secure_pass123'];
$controller->registerAction($fakeHttpRequest);
?>

9. Best Practices #

• Clean Architecture (Onion Architecture): The ultimate goal of adding Repositories, Services, and DTOs to MVC is to achieve "Clean Architecture." The dependency arrows must only point *inward*. The core Business Logic (Services) must not depend on the Database, the UI, or the HTTP framework. The UI and the Database depend on the core.

10. Common Mistakes #

• Leaking Models into Views: Never pass a heavy, database-connected Active Record Model directly into a View template. If the View accidentally calls $model->save(), the UI layer has just altered the database, completely violating the Separation of Concerns. Always pass DTOs or simple arrays to Views.

11. Practice Exercises #

1. 1. Define the specific, isolated responsibilities of the Model, the View, and the Controller in a standard MVC application.

1. 2. Explain the "Fat Controller" anti-pattern. Why is extracting business logic from the Controller into a dedicated "Service Layer" essential for enterprise code reusability?

12. MCQs with Answers #

13. Interview Questions #

• Q: Explain the life cycle of a standard HTTP Request as it travels through an Enterprise MVC architecture (Router -> Controller -> Service -> Repository -> View).

• Q: Walk me through the concept of a Data Transfer Object (DTO). Why is it dangerous to pass raw HTTP Request objects or associative arrays directly into your core domain logic?

• Q: Define "Clean Architecture." How do the Repository Pattern and the Service Layer work together to ensure that the core business logic is completely isolated from the specific database technology (e.g., MySQL) and the specific UI delivery mechanism (e.g., HTTP APIs)?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #