XF 2.0 Difference between Repository, Service and stand-alone class?

[DragonByte Tech]

I think I asked something similar back on the XF2 demo board, but I can't seem to find the thread right now.

TL;DR: What is the distinct use-case difference between these three methods of creating application logic?

Details:
I've had a look at the Abstract classes for Repository and Service, as well as the method of instantiating a Repository and a Service in the \XF and \XF\App classes. From what I can tell, the only difference is that a Service allows you to pass arguments to the constructor whereas a Repository does not.

So you could do $service = \XF::service('MyAddon:SomeService', $foo, $bar); for a Service, but for a Repository you would have to do

$repository = \XF::repository('MyAddon:SomeRepo');
$repository->setFoo($foo);
$repository->setBar($bar);

The difference doesn't appear to be in terms of read vs write either, as I'm seeing "update" operations in public functions (e.g. public function updateTrophiesForUser(\XF\Entity\User $user, $userTrophies = null, $trophies = null)), so the notion that a Repository was only the equivalent of "complex to construct, but frequently executed, database reads" portion of the old XF1 Model system appears to be out the window.

Maybe I'm taking this way too seriously but when I'm writing XF2-only applications, I want to do it right, so I want to learn this and all the other intricacies of XF2


Fillip

 

[Chris D]

Services are more about a certain pattern of the logic. We consider them to be a "set up and go" type of approach for a specific action. It segregates the object into its own class with a very distinct purpose. It provides much clearer extension points and greater control of each step of the process.

You can do a similar thing with a stand alone class, though there is of course a QoL aspect to Services in that they automatically have a bunch of stuff available via its abstract class. Generally we reserve stand alone classes for special stuff. Things like the custom field classes, as an example. They wouldn't be appropriate as a service as aside from not really fitting into the "set up and go" pattern and the custom field stuff is actually 3 separate components which all closely interact with each other.

Stand alone classes would also be used for more low level stuff or where there's a need for stuff like ArrayAccess and other built in PHP interfaces. That kind of wrapper class wouldn't really fit into the service pattern either.

Repositories are sort of equivalent to models, though most of the stuff that was in models is now handled in distinct steps inside Service classes, or made redundant by the Finder system. These are really just general purpose functions for performing specific tasks or fetching data which don't need a full Service class to implement them. I suppose, on reflection, there could be some things in Repos which could be considered as being better in a Service but that shouldn't be too common.

Hopefully that answers your question but if you have any specific queries about an approach to take then feel free to ask.

 

[DragonByte Tech]

Hopefully that answers your question but if you have any specific queries about an approach to take then feel free to ask.

Makes sense, thank you for your time


Fillip

 

[sledov]

Services are more about a certain pattern of the logic. We consider them to be a "set up and go" type of approach for a specific action. It segregates the object into its own class with a very distinct purpose. It provides much clearer extension points and greater control of each step of the process.

Hi Chris D,

Are you following some established software design pattern here? Or is it something that you decided on specifically for Xenforo?

Thank you,