Let's say that I want to show a form that represents 10 different objects on a combobox. For example, I want the user to pick one hamburguer from 10 different ones that contain tomatoes.

Since I want to separate UI and logic, I'd have to pass the form a string representation of the hamburguers in order to display them on the combobox. Otherwise, the UI would have to dig into the objects fields. Then the user would pick a hamburguer from the combobox, and submit it back to the controller. Now the controller would have to find again said hamburguer based on the string representation used by the form (maybe an ID?).

Isn't that incredibly inefficient? You already had the objects you wanted to pick one from. If you submited to the form the whole objects, and then returned a specific object, you wouldn't have to refind it later on since the form already returned a reference to that object.

Moreover, if I'm wrong and you actually should send the whole object to the form, how can I isolate UI from logic?

  • In which way would it be inefficient? In all case, you have to show a string representation to the user, and map his answer to the original object. Commented Dec 28, 2011 at 1:33
  • The problem is that in order to work with said object, I have to fetch it again after the user picked it.
    – Uri
    Commented Dec 28, 2011 at 1:49

2 Answers 2


First of all, the example you provided is not incredibly inefficient; its only slightly inefficient; its inefficiency is below the perceptible level. But, in any case, let's move on with the question.

The way I understand it, when we speak of separation of UI and Logic, we mean avoidance of close coupling.

Close coupling refers to the situation in which the UI knows (and invokes) the logic, and the logic knows (and invokes) the UI. To avoid close coupling one does not need to resort to abolishing coupling altogether. (That's what you seem to be aiming at by demolishing the interface between them down to a least-common-denominator string interface.) All one needs to do is to employ loose coupling.

Loose coupling means that A knows B, but B does not know A. In other words, the two parties involved play distinct client and server roles, where the client knows the server, but the server does not know the client.

In the case of UI and logic, the best way of arranging this in my opinion is by seeing the logic as a server, and the UI as a client. So, the UI is built for the logic, has knowledge of the logic, and invokes the logic, while the logic knows nothing about the UI, and simply responds to the requests that it receives. (And these requests happen to come from the UI, but the logic does not know that.)

To put it in more practical terms, nowhere within the source code files of the logic should you find any include/import/using statements that refer to UI files, while the source code files of the UI will be full of include/import/using statements that refer to Logic files.

So, to come back to your case, there is absolutely nothing wrong with the fact that the UI code which populates the combo-box knows about the hamburger class. There would be a problem if the hamburger class knew anything about combo boxes.

Incidentally, this design allows another thing which you should expect from such a system: it should be possible to plug as many different UIs as you wish to the logic, and the whole thing should still work.


You should separate each piece of the Model, View & Controller, but there's no reason why you cannot (for example) pass Model objects between the Controller and the View.

So in your case, the Hamburger objects would be part of the Model. You then use your Controller to fetch the required list of Hamburgers, and pass those objects to the View (the combobox) to display. When your user has selected which hamburger, you can then pass the Hamburger object back to the Controller again for processing.

The point is, you can still unit test the "fetch Hamburgers" logic and the "process Hamburger" logic separately from the actual display of hamburgers.

  • I understand. However then if I modify the Hamburguer class, won't I have to also modify the form's code that deals with the Hamburguer objects? Where is the UI-Logic separation then?
    – Uri
    Commented Dec 28, 2011 at 1:48
  • 2
    The hamburger is part of the model. When you modify the model, you end up modifying the view and the controller. The model is the separation between UI and logic. Touching it has a higher cost, so you should be careful when designing it. Commented Dec 28, 2011 at 1:54

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.