The idea of static utility methods is attractive, but leads to big classes that know too much and that too many actors have to know. It doesn't encourage the loose coupling that we strive for with OOP.
What you're seeing is a muddling of business and domain logic. From the Best Practices doc:
Commands house the Business Logic of our application; the technical implementation of the use cases our application is expected to carry out against the Domain Model. This involves coordination of the Model and View states.
The Model maintains its integrity through the use of Proxies, which house Domain Logic, and expose an API for manipulation of Data Objects. They encapsulate all access to the data model whether it is in the client or the server, so that to the rest of the application all that is relevant is whether the data can be accessed synchronously or asynchronously.
What this breaks down to is that you may simply want to move more of the logic that has to do with model relationships into the proxies themselves. It is perfectly fine for one Proxy to retrieve and collaborate with another. So if you're doing a lot of laborious assembly of stuff from various related Proxies in Commands, you may instead do that assembly inside your Proxies. The Proxies should encapsulate complex relationships between the data and make it easier for the actors that collaborate with them (Mediators and Commands), obviating the need for the utility methods.
-=Cliff>