I would say an adapter class is part of the controller, and it's ok for
the controller to know about the formats of both the model and the view
- it's job is to translate, and facilitate model data into generic view
data (and back), even if all it does is setup a delegate, like an adapter.
Many times that's honestly overkill - you might be able to get away with
just taking a list of some stuff from the model, creating another list
of view data, and copy the subset of data it needs (title, description,
and id for one example) in a full list. It's often easier to do it this
way. Other times, you might start from MVC, but your view isn't really
all that generic (be careful if you find yourself here a lot, you might
be spinning your wheels), so why not just pass a reference to the model,
and skip all the API wrangling, adapters, etc. I consider it like
optimizing my time, vs. optimizing the machine's time.
But other times, there will be too much data to copy around, or you just
wouldn't want to alloc all that memory just for duplicated data, cause
that's slow on some hardware (or might use up more battery life, if you
want to be kind to your users). That's where adapters comes in, to
basically stream and wrap a subset of the full list of model data to the
view as needed through an API, rather than all at once in a giant copy.
The real problem seems to be that patterns are descriptive, more than
prescriptive. So as implementations change, ideas tend to diverge, and
sometimes differing patterns might even get described by other names.
Maybe I've been describing MVA for example:
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93adapter
Use what works, and doesn't drive you mad. That's what I say. :-)
Kevin N.
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders