I have a use case where I display variables in a PDF file.  But to get there is not simple, but I could do something like this:/* * takes product model number, retrieves, processes, formats values * returns $variables, ready to plug-in to view with no further processing */$variables = $this->repository->getVariables($model);/* * View runs PDF Library code and displays variables and their values in a table */$this->sendToView($variables);Way 1 - Have Repository Do all the work to transform variablesinside getVariables I would do these:read raw data from database tables (stored expressions)run data through expression engine (it evaluates the expressions)format resulting numeric data (i.e. round to 2 decimal points)add denominations (i.e. mm or inches)adorn data (put engineering tolerances, or extra wording around variables)re-group data for consumption by the PDF API engine (the view)All the work will be done in getVariables and sendToView will then directly plug the variables as PDF API directs, no transformation neededWay 2 - Use repository to get raw data onlyOpposite extreme is have getVariables do #1 only and have separate classes do their own things .. I could end up with$expressions = $this->repository->getVariables($model);$solveExpressions = $this->expressionEngine->process($expressions);$formattedVars = $this->formatter->format($solvedExpressions);$denominatedData = $this->denom->addMarkers($formattedVars);$adornedData = $this->adorner->adorn($denominatedData);$viewReadyData = $this->viewPreparer->prep($adornedData);$this->sendToView($viewReadyData);Or I could mix and match the above and stuff the methods into various classes..My questionHow much of the data transformation, formatting, regrouping, polishing, preparation, etc goes into the repository layer?  (That will help me determine what of the data manipulation will need to be done outside of repository layer, and maybe even what of the data manipulation is to be done in the view layer - i.e. simple regrouping of data for easier way to plug into a table)P.S. What am I trying to do (data manipulation)Without focusing on code, in the context of the question, what I am doing is this -- starting with expressions stored in database:a = 5b = a + 3Then I end up with solved expressions:a = 5b = 8Then I do a series or formatting and adorning like so:8 => 8.00 => 8.00mm => 8.00mm +/-0.01where during the above is stays in a form similar toarray(    'a' => '5.00mm +/-0.01',    'b' => '8.00mm +/-0.01');For the view I transform that intoarray(    0 => array(        'description' => 'a',        'value' => '5.00mm +/-0.01'    ),    1 => array(        'description' => 'b',        'value' => '8.00mm +/-0.01'    ));And I wish to write the above into modern OOP code.
How much of the data preparation, transformation, and processing belongs in Repository layer?
design patterns;php;mvc;data;dao
Based on your comments, I would highly recommend you to not get fooled by so called best practices and other wizardry. Primarily you should choose a way to implement your solution in a way that helps: your stakeholders/boss to reach business goal using your solution - the code in place.you and your team to be able to fastly respond to the arisen problem/task, in a way that everyone understandsYou also write about anemia and business object. Please prove me wrong but I fail to percieve any behaviour or business logic in the set of method calls. They just seem to doing a series of data transformation, without any validation or so. I have a gut feeling that it's used for some sort of reporting, but the true intention is not really clear.The only useful thing I could help you with is, to examine your code, capture the technical areas and split them up to modules those have explicit boundaries. The Separation of concerns design principle can help here drawing the boundaries:Repository: held responsible for reading and writing the data in your data storeExpression engine: evaluating the dataFormatter: formatting and adorningOutput to viewing: convert/represent the above to a given output formEach of these modules should be responsible for their own set of concerns. Create classes with respective methods that does what are respectively responsible for and nothing more. Whenever you encapsulate these concerns into set of modules you are also increasing cohesion and may even help the testability of your code.