Slim 3服务层与模型依赖注入选型及架构设计咨询

Hey there! Let me share how I'm structuring my Slim 3 application right now, since I landed on a service-layer focused setup after some research.

Context #

I'm building an app where the core features are:

• Dynamically generating a set of dropdown select boxes
• Generating calculated data tables based on the user's selections from those dropdowns

At first, I was planning to stick with a standard MVC architecture. But I wanted to enforce a strict separation in the data access layer—where each model only handles a single data item. After reading Dependency Injection Slim Framework 3, I decided to shift my business logic into a dedicated service layer instead.

Architecture Breakdown #

Here's the structure I've implemented:

1. Routes Layer #

• This is the entry point for all HTTP requests. It maps incoming requests to specific controller actions.
• Example route definition in Slim 3:

  $app->post('/calculate-table', 'App\Controllers\CalculationController:handleTableGeneration')->setName('table.generate');
  

2. Controllers Layer #

• Controllers act as coordinators—they receive request data, call the appropriate service methods, and prepare the response to send back to the user.
• No business logic lives here; their only job is to pass data between routes and services, and handle view rendering if needed.

3. Services Layer #

• This is where all the business logic lives: calculations for the data tables, logic to populate dynamic dropdowns, and any rules around user selections.
• I use Slim 3's dependency injection container to inject the necessary models/repositories into each service, keeping things decoupled.
• Example snippet from a calculation service:

  public function buildCalculatedTable(array $userChoices): array
  {
      // Fetch raw data using dedicated models
      $sourceData = $this->productModel->getByFilters($userChoices);
      // Apply business rules to compute final table values
      return $this->applyCalculations($sourceData);
  }
  

4. Models/Repositories Layer #

• Each model adheres strictly to the single responsibility principle—only handling one data entity (e.g., a ProductModel only interacts with product data, a CategoryModel only with category data).
• Their sole purpose is data access: running database queries, persisting data, and mapping database results to entities. No business logic here.

5. Views Layer #

• I use Twig (Slim's default view renderer) to render the dynamic dropdowns and calculated tables.
• Views receive processed data from controllers and turn it into user-facing HTML.

Why This Works for Me #

• Clear Separation of Concerns: Each layer has a distinct job, making the code easier to test, debug, and maintain.
• Flexibility: If I need to add a new calculation rule or dropdown type, I just extend the service layer without touching controllers or models.
• Dependency Injection: Slim 3's DI container makes it simple to swap out implementations (e.g., switching from a MySQL model to a PostgreSQL one) without rewriting core logic.

内容的提问来源于stack exchange，提问作者GothicAnatomist