When using SOC & SRP should I be concerned about too much parameter passing between code blocks?

Question

How far do I break down individual tasks within a typical scenario of "Web application reacts to user input"?

For example, in the case below, say a scenario is "User submits a form, causing user data to be turned into an Object (technical detail) and then saved into the database" .

I am using various services to get, filter, object-ify, and save data. Specifically, for example, in my $domainObject = ... line below solely copies data from array into an object (similar to this What is a name for a pattern where it receives data or asks for data and returns back an object?)

I am asking, if by continuing to separate individual concerns I come across, into various classes, services, and methods, am I making things harder for myself or future maintainers in the long run?

class Controller
{
    //saves a domain object acquired from an HTML form & other sources
    function saveAction()
    {
        // acquire data from GET, POST, COOKIE, SESSION, database, et
        $inputData = $this->inputService->acquireData();

        // clean data
        $filteredData = $this->filterService->filter($inputData);

        // marshall data into an object
        $domainObject = $this->objectService->createObject($filteredData);

        //save object into a database
        $id = $this->repository->save($domainObject);

        // Send $id to View
        return new ViewModel(array(
            'id' => $id
        );
    }

For Clarity

Let's call "parameter passing" as "wiring".

• So, first, my wire is $inputData, which I receive from inputService.
• I take that wire and feed it into filterService, which returns the other end of the wire called $filteredData.
• I take that end of wire and feed it into objectService.
• In return I get $domainObject end of the wire.
• I take that end and feed it into repository, and receive back ID
• I take the $id end of wire and run it into my ViewModel, and that's the endpoint.

^^^^ The above is all the wiring that I do and that needs to happen when I use Separation of Concern to separate my code into various code constructs of inputService, filterService, objectService, repository, ViewModel.

The wiring connects them together.

I can "cheat" and merge some code constructs together to minimize on passing the wire. (minimize passing the parameters everywhere).

And that is what my question is about.

Question

Is wiring up of the individual code constructs (parameter passing between various services) a good thing? Should I do more? Should I do less? Is there a technique I'm not aware of that makes this a non-issue?

Answer 1

I would say that it depends of the business logic and the domain of the problem you're trying to solve. If you see frameworks like Ruby On Rails, or Laravel, they try to use MVC to tackle common web app problems. However, these frameworks start to get fat (for example, you can find controllers or models with more than 2000 lines of code, i.e the famous User model with a lot of business logic).

This has popularized two approachs.

1. The use of microservices in different technologies instead of monolithic applications.
2. The use of OOP concepts like concerns (traits in PHP), composition, mixins for behaviors, engines for splitting logic and more.

So I would say that if you have a simple app, with no future intentions of making it grow with hundreds of features, a simple mvc flow with helpers can be enough. If your app is planning to grow a lot, you should consider an alternative as mentioned before.

This is a very debated topic, and there are several articles of great programmers, like this one from David Heinemeier Hansson. Also this is pure gold from Sandy Metz in railsconf. And other nice resource is this question.