8

What is a way to log messages or errors from an Entity or Repository class in the symfony2 architecture? In symfony1 you could use the singleton to kill puppies by doing something like this to get the logger from anywhere:

sfContext::getInstance()->getLogger()

Symfony2's container model is stricter, which is great, but how should one go about logging from non-container-aware classes? For repos, I guess you can define them (all) as services, with a dependency on the logger, and go from there. But what about when you just have an instance of an Entity class?

Historically I'd want to put the log message inside class methods, but now? Should I pass the logger (as a parameter) into every class method that wants to write a log message? This seems like a bit of overkill but perhaps it's best practice?

Or am I looking at this wrong and Entities or Repos shouldn't be writing log messages but passing them back to the controller to handle?

k0pernikus
  • 60,309
  • 67
  • 216
  • 347
caponica
  • 3,788
  • 4
  • 32
  • 48

1 Answers1

2

You should probably avoid putting business logic (even logging) inside entity model.

As for the repositories, the way you described is the right one.

Jovan Perovic
  • 19,846
  • 5
  • 44
  • 85
  • 3
    Isn't the Entity exactly where all business logic is meant to go? I'm very confused now! You have an MVC architecture... so V is for the views (twig, no business logic there), C is for the controllers - keep them thin and the logic is just about routing and handing off heavy lifting to the M for model. Which is the Entity classes, right? – caponica Oct 06 '13 at 19:14
  • Symfony2 is not actually MVC par se, but it's close. You're right about **V** and **C** but **M**-odel should describe data structure and nothing else. Check out this: http://knpuniversity.com/screencast/question-answer-day/model-organization – Jovan Perovic Oct 06 '13 at 19:25
  • Hmm... I'll have to think about that for a bit! Spent 2 days training at Sensio and they spent the whole first day banging on about how Sf2 projects should be MVC :) However, the more I get into it, the more that moving code to services rather than entities makes sense. Makes porting an old (MVC) project to Sf2 even more complex than I thought, though! – caponica Oct 06 '13 at 19:59
  • OK, 10 mins is enough thinking to realise the wisdom of this! Are there any more links you can share suggesting best ways to lay out code and what should go where (config/services/controllers/entities/repositories/templates/etc)? – caponica Oct 06 '13 at 20:10
  • Are you looking for this? http://symfony.com/doc/current/quick_tour/the_architecture.html – Jovan Perovic Oct 07 '13 at 11:24
  • 1
    Not quite - I know where the files live! The question was one of best-practice/design/code architecture: "what should go into each file?" E.g. in sf1 you put the logic to do with retrieving things (from the database) into FooTable.class.php and business logic related to manipulating Foos into Foo.class.php. This doesn't seem to map to FooRepository.php and Foo.php in Sf2... should services replace the old model class files? I've spoken to several sf1 veterans who've got in knots trying to make Entity files get access to containers, parameters, etc - how *should* coding be approached now? – caponica Oct 07 '13 at 13:46