I am working on writing a service layer for an order system in php. It's the typical scenario, you have an Order that can have multiple Line Items. So lets say a request is received to store a line item with pictures and comments. I might receive a json request such as

    'type': 'Bike',
    'color': 'Red',
    'commentIds': [3193,3194]
    'attachmentIds': [123,413]

My idea was to have a Service_LineItem_Bike class that knows how to take the json data and store an entity for a bike.

My question is, the Service_LineItem class now needs to fetch comments and file attachments, and store the relationships. Service_LineItem seems like it should interact with a Service_Comment and a Service_FileUpload. Should instances of these two other services be instantiated and passed to the Service_LineItem constructor,or set by getters and setters? Dependency injection seems like the right solution, allowing a service access to a 'service fetching helper' seems wrong, and this should stay at the application level.

I am using Doctrine 2 as a ORM, and I can technically write a dql query inside Service_LineItem to fetch the comments and file uploads necessary for the association, but this seems like it would have a tighter coupling, rather then leaving this up to the right service object.


1 Answer 1


When one is concerned with tight coupling, it is useful to remember the SOLID principles. In this case, you have a single command that has too many responsibilities: creating a bike, adding comments to it, and attaching pictures to it. Let's break it down:

  1. Create (red) bike line item.
  2. Comment on line item.
  3. Attach picture to line item.

Create a separate method for each of these behaviors and forget all those abstractions (this is php after all ;). Call the appropriate method from the UI via Ajax when the user does something.

I'm guessing comments and attachments are wholly optional, so doing it this way would therefore not put your data into an invalid state.

  • In my scenario having the service layer is important. I plan on using the same service layer by multiple consumers (ex, processing of normal form submissions, and a RESTful api so resources can be modified programmatically). That being said, I'm not sure how much knowledge the controller should know about incoming data, IMO it should just more or less be a router passing the data to the appropriate service...no? I was hoping by creating data interpret classes I can map the input data coming form a normal MVC application or REST request to a common data type.
    – Justin
    Nov 7, 2013 at 20:50
  • 1
    Then your service layer's methods should be CreateLineItem, CommentOnLineItem, AttachPictureToLineItem, etc, and yes your controller should merely be passing data through. Nov 7, 2013 at 21:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.