This is a hard question to answer as many have pointed out via comments, but I guess I will weight in.
My first thought is to do what is best for your application. We can get deep into theory of DDD and the like where I might have a different opinion(and I will, if you bear with me).
If it makes the most sense to you to simply load a
show via your ORM and call some method like
getPublishedEpisodes() than do it! If you subscribe to an agile approach or you refactor often, you can always change it later. It is possible (and likely) that your first attempt at a pattern or architecture will be wrong... Sometimes we just don't know what we need until we try.
If you ORM is rather unintrusive and does not impose a direct dependency on the
Show class, then you are probably fine to go that route. Aspect Oriented Programming is something you may want to look into and it works well with your ideas. It may not be possible in PHP or with your ORM, though.
Anyway, I would find it cleaner to use your models to encapsulate business logic, and in that sense I would imagine your
Episodes would be children of the
Show. If that is so, I would probably have a
ShowRepository to load the
Show where the repository is a dependency of the
ShowService would manage linking up your entities and would handle the coordination of business logic.
In my version of this app, just from a 1000ft view, when I loaded the
Show I would pretty much always load all of the
Episodes with it. When I needed to get just the
Episodes for a particular view I may use some form of a Query Object to execute a more custom query. The only reason I would do this, however, is if my app was really underperforming using the original idea of just fetching the
Show with the
Using the Query Object idea leads into CQRS which is a rather advanced topic and may not even be worth the trouble in your application.
To reiterate, do what feels easiest to understand and maintain for you and your team. We can only give so much advice on the internet, especially without seeing and understanding the application and its domain.
That being said--and I would take the rest of this with a grain of salt--if I were writing this application I would favor a different approach, probably closer to that of your
When you say "entity" I think of DDD. This may or may not be accurate. Many ORM Providers call their models "entities"--ahem Entity Framework ahem--which is sort of a misnomer. Entity Framework "entities" are really just Data Transfer Objects. In my opinion, "entities" are entities as they relate to Domain Driven Design. Entities, as seen here, are defined by their identity. They are the core models that represent the strategically important concepts of a domain or business.
If we subscribe to DDD and DDD-like patterns, our entities will never have dependencies like a service would. Think about an order and its corresponding order lines. Can the order lines exist in isolation without an order? Can you have a rouge order line? No. A major portion of the order line identity is the order itself. The order is the aggregate entity.
So, in this instance, the
Show seems like it is your aggregate while the
Episodes seem like child entities. If this is the case, you would not even have a means of loading the
Episodes from the database directly. They would always come with the
Show. This is why you may feel like the
ShowService is the "correct" way to solve your problem. You have probably heard something along these lines somewhere down the road. Maybe you are already very familiar with DDD and everything I am saying is for naught. Either way, I figured I would share.
DDD is great, and offers a lot of clarity into how you should think about your app and where particular logic belongs, but DDD is hard. If your app is a simple CRUD app with little logic about it, I would avoid DDD altogether. It is just a lot of work and very difficult to do well.
That was a tangent, but hopefully it helps.