Model-Controller cyclic reference/design problem

Question

I have a CoreData entity X, and controllers for this entity, XController. Now there's another entity, XGroup, containing a collection of X entities, and a XGroupController.

Now the problem is that XGroupController needs to interact with XController, and it would be nice to just pass XGroupController a XGroup to observe, and then get the XControllers from the X entities.

So the question is: is it a good idea to store a (weak, to avoid retain cycles) reference to a controller in an entity? It just feels a bit "wrong". Is there another design pattern for this?

[Edit] Some more information: XController/XGroupController are view controllers; and the reason why it felt "wrong" is that the view layer shouldn't be in the model layer. So @TechZen is right with his first paragraph.

However, how would I do that if I don't have that reference? The way I see is to pass XGroupController all existing XControllers (plus update them when they change), and then when the items in the XGroup change, find the corresponding controllers (by checking if the XControllers property for it's X entity is in the XGroup) and finally talk to the XControllers.

I have to do work again for stuff the model already handles very nicely. Doesn't it make the model layer kind of pointless if I have to handle groups in the controller layer another time?

The difference that makes in terms of Loc/complexity is just so significant, am I missing something? (Perhaps I should add that in my scenario it doesn't make sense to store the information XGroupController needs to give to XController via the model).

Answer 1

If by "controller" you mean a MVC view/interface controller then yes it is wrong because it breaks encapsulation. The data model should be completely unconcerned with how it's data is displayed.

If your "controller" is just an entity with that name then you probably want to use a fetched relationship to get the two controllers to talk to each other. That prevents circular relationships in the object graph.