Hey Dave, I'll reply inline, seems easiest...
> In the MVC app structure I'm thinking about, passing a reference to the > model into the view is probably the most natural thing to do. There's no > thrash creating it, no other var created, simple. What made me stop and ask > these questions were two things: a) I thought the controller should have > references to the model and view, but they shouldn't know about each other, > and b) thinking about how the view would access the model's instance data. > > Re b), I wouldn't want model data to be in public vars just for this > purpose, so the view (say a cfml template at bottom) would need to contain a > bunch of getter calls. That struck me as tying it somewhat to the model. Yep, in this case, the view has knowledge of the model's interface. It doesn't have knowledge of the implementation, so we're still good - many MVC diagrams show the view querying the model for its data: http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/introduction/summary/ > Passing in a dumb data struct, or a typed object that really is just the > contents of that dumb struct as public vars, seems to assume much less > external context. "I need this data, and it gets passed to me, end of > story.", as opposed to "I need this data, and I get passed a complex object > with a bunch of methods that allow me to access it." I agree - but it depends on if you need it. Will that view ever really be reused with a different model, or different portion of the same model? If so, can you account for it by having it rely on a TO interface that both models will pass back? In that case, abstracting the response with a TO is definitely a way to go about things. > Re a), it is true that the view wouldn't exactly be knowing about the model, > just about "some object with the access methods I need". That it happens to > be the actual model object in some cases is an implementation convenience > only; none of its behaviors beyond the needed getters matter. Still, it just > seemed cleaner and tighter that the view sees only an object with the > relevant data, nothing fancier. Again, I agree, but I think this making this abstraction relies on the actual need to do so. If your model is basically a bean to begin with (no logic, just get/set), we're already talking about a clean, tight object with only relative data. If it's a business object, and there's methods on it that really do things that the view should have no business mucking about with, then passing a bean/to to the view like you describe is a good option. Overall, I think the refactoring / iterative approach is a good one to take - you factor/refactor as you need, rather than getting paralyzed looking for the 'ideal' design. -Joe > Thoughts? > > Dave Merrill > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
