5

Lets say I'm displaying a bunch of data (model) using a View class for rendering. However, a lot of the data has sub-data (models) complicated enough to require separate rendering classes.

In my design, a View class has a model which it is rendering, and has many children Views which display the sub-data. In some cases, A View, while containing a model, may not have anything to render and serves more as a wrapper for it children.

However, if you have very complex data and your sub-views have subviews,this design results in deeply nested method calls. Some methods are simply passing information to view classes who may do nothing with it except pass it to their children. This seems inefficient, so I figured there might to be a pattern or something that solves this more elegantly.

Improve this question
4
  • 1
    Please, give an example. Actually, in the current form, I don't understand your problem. Lets say you have data like an invoice, and subdata like "invoice-address". Now you pass an "invoice" object to your "invoice-view", this calls "GetInvoiceAddress" and passes the resulting object to the "invoice-address-view". The latter then calls the "Get" methods of the invoice-address-object. So no deep-method call at all - where is the problem? Commented Jan 14, 2013 at 8:26
  • 1
    Can't each child be responsible of it's own rendering? Supported in many different frameworks, but you don't give any examples or tell us what kind of application it is it's hard to give an answer. Commented Jan 14, 2013 at 9:11
  • -1, you were here, read my comment, had a chance to improve your question, but missed it. If you want other people to invest their time for you, please invest some of your time to make your questions clearer. I will remove the downvote if you clarify your question. Commented Jan 15, 2013 at 9:08
  • @DocBrown Apologies, but I was doing some research in trying to see how I could restructure with more clarity in general. But I think Shivan's answer best answers my question. EDIT: fixed error Commented Jan 16, 2013 at 1:11

3 Answers 3

Reset to default
1

Looks to me like you're not really separating the model and the view, while being in a situation where such a separation is exactly what you need.

If "a View class has a model which it is rendering" then there's really no separation between them, you can just make one class for that. I'm not saying that there's anything inherently wrong with that, for example the Spring (Web) MVC framework has a ModelAndView class which can contain references to a (composite) model and a view. I'm just thinking that in your case it would be better if you'd externalize the relation between model and view: have your Model classes completely separated from your View classes, and then have some sort of manager that decides what View is used to display what Model at a given time.

Then make each of these as granular as needed to be able to reuse them, i.e. if you have some piece of model and a certain way to display it which is repeated as part of multiple views (but at the same time that piece of Model is also needed to be displayed differently in other views) then make Model and View classes for each of these situations, and have a manager decide with what view that model should go depending on the current context (parent view, request, etc).

Improve this answer
2
  • This is what I was looking for. So essentially, I need to decouple the model and view further with a controller (basically implementing a MVC pattern). Do I have this correct? Commented Jan 16, 2013 at 1:14
  • Yes, pretty much, though you can also see it as a "View Resolver" - some entity that knows which view to fetch best on different traits of the current context. At any rate, the main idea is to have good clean separation between model and view, and also to make model and view objects granular enough to be reusable in various composite views. Commented Jan 16, 2013 at 7:38
2

On the one hand we teach ourselves to use design patterns and common sense design techniques, from which emerges the ideal of designing close to conceptual models, and, on the other hand, we're concerned when our resulting models become deep. And we shouldn't be.

If, conceptually, your views are aggregations of other views, then I see no problem with nested structures and the resulting delegation model. I see no problem with views delegating as part of fulfilling their role, as long as their interface is consistent with their purpose and speaks at a consistent level of abstraction.

Let me restate this. If you were to explain your view to colleagues, and the explanation best describes the view in terms of other views, then that is what your code should be like.

In fact, views that delegate may be simply working to realize the Law of Demeter (not something to go fanatic about, but definitely something nice to recognize in your designs).

I should say that I apply the above principles in my user interface code with good results. Event handling can become verbose, but you have EventBus to the rescue.

Improve this answer
0

Assuming you have a sufficient templating language that allows for mixing and matching your templates, you should break out each relevant piece of your model into its own template which can be used to make a composite view.

For instance, you may have a Book model, which in turn has data for Bookmarks, perhaps some Highlights, and maybe PageNotes. Now each of these should have their own template that renders the content in a meaningful way, and this should be achieved by passed in only the relevant data into the template.

Why would one want to take this approach? It allows you to separate your concerns. You model should be used to marshal your data and move it from point A to point B, and your view should simply render it for consumption.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.