Laravelhez illő megvalósítás

Idiomatic Laravel Development

Architecture and responsibilities

• Keep controllers focused on HTTP orchestration: receive a validated Form Request, authorize the action, delegate non-trivial business rules to the layer the project uses (domain methods, Action classes or Services), and return a response, View, Redirect or JsonResource.
• Separate input validation, authorization and business rules so each has one clear home and can run in HTTP, CLI and queue contexts.
• Do not introduce repositories, service layers or interfaces with a single implementation unless the project already uses that pattern or the complexity warrants it.
• Generate scaffolding with php artisan make:* (--no-interaction) so namespaces and stubs match the app. Never edit files in vendor/.

Container, config and environment

• Prefer constructor dependency injection and typed contracts over app() service location in application code. Register bindings and singletons in Service Providers.
• Call env() ONLY inside config/*.php; in application code always read config('service.key') because env() returns null when config is cached. Document new environment variables in .env.example.

Routing, errors and PHP style

• Use named routes (route('orders.show', $order)), route model binding, and Route::resource / Route::apiResource where CRUD fits.
• Use custom domain exceptions (report() / render() or centralized exception handling in bootstrap/app.php / Handler.php) instead of catching generic \Exception and returning ad-hoc error arrays.
• Add explicit parameter and return types, constructor property promotion, and PHP BackedEnums (string or int) for status/type sets. Format with vendor/bin/pint --dirty when Pint is present.