Slim 4 MVC Skeleton

Show and Tell
1

Hi,

I just want to share a skeleton I made for my company.

The skeleton use:

  • PHP-DI
  • Slim-Psr7
  • Doctrine
  • Twig
  • Flash messages
  • Monolog
  • Synfony console.

I want your feedback (especially to optimize the Readme).

Thanks,

3 Likes
2

This is great, I feel like we should add these on the Slim 4 readme and include them on the website to give more options to users!

1 Like
3

Thanks a lot to the author for the Slim 4 MVC Skeleton.

However, in my opinion, it turned out quite confusing, and difficult for a beginner.
If this is presented as a starter pack - it is probably difficult.

My opinion is subjective ā€¦ maybe I lack understanding due to the lack of a lot of experience ā€¦

ps this is not criticism, this is the opinion of a beginner

4

I agree, my skeleton is not really for beginner.
I tried to create a root for a project, Iā€™ve made a more complex skeleton for Slim 3 and I used it as a start for 2 professional project.

Maybe I canā€™t try to make a simplier skeleton just with Twig and Monolog (like a MVC ā€œhello worldā€) or maybe https://github.com/odan/slim4-skeleton is already a good one ?

6

Thanks @semhoun, always super useful to see how other people are actually doing stuff.

One thing I wanted to bring up for discussion is how youā€™re injecting the container into your BaseController. I had avoided doing something similar to this in trying to stick with the whole ā€˜your app should not know about the containerā€™ notion, but by injecting a ContainerInterface you are side stepping the major issue there (coupling your code to a specific di container implementation). In doing this, I think you end up with a cleaner way of interfacing with your controllersā€™ dependencies, but Iā€™m curious how others who adhere to keeping ā€˜knowledgeā€™ of the container out of the app view this approach.

Is it OK that the app knows that it relies on a container, so long as the implementation is abstracted away behind an interface?

7

Injecting the container and then fetching dependencies from it is a so called service locator anti-pattern.

A service locator hides the real dependencies and makes it harder to write tests. This pattern is only useful within a container definition closure, but should not be used in the application itself. The core application should be unaware of the container. The default approach should be to apply Constructor Injection (IMHO).

2 Likes