Separation of concerns

[JoeBengalen]

I've been looking at some separation as I feel the App class is a bit of a mixup of several methods that do not have anything to do with each other.

App now acts as:

• container
• part of the router (adding routes)
• is the core/kernel middleware layer
• contains the application runner method
• handles outputting the final response
• contains several 'helper' method like halt() and subRequest()

I think it would do good to separate some of this functionality.

There is a WIP pull request that handles the contains part. To separate some more functions I tried some things.

As spoken of in another pull request separating the outputting from the app: https://github.com/slimphp/Slim/compare/develop...JoeBengalen:feature-separate-core?expand=1

Also I tried separated the core/kernel middleware layer: https://github.com/slimphp/Slim/compare/develop...JoeBengalen:feature-separate-core?expand=1 Note this compare also contains the changes from the above one. I know passing the container as a dependency may not be ideal, but you get the idea.

Let me know how you think about separating some functionality from the App class.

@codeguy

[lalop]

Maybe we can split this concerns into trait like for the middleware stack and the callable resolver.

[geggleto]

I agree with this idea in principle, and would like to see this as a long term goal. I think this should be tagged for a 4.0 release as it is a major structural change and we really need to push out 3.0 sooner than later.

[r3wt]

Disagree. (not that my opinion matters)

[JoeBengalen]

@r3wt Mind explaining why?

@geggleto I'm okay with putting this up for 4.0.

@lalop Not sure about traits. They can be handy is some cases, but in this case the object would still be tightly coupled. One reason to separate can be so you can use the functionality optional and separately.