I grew up on the web during the heady days of server side MVC. Server side MVC is still heavily used in the way that steam engines were used into the 1900. Still, I find it very challenging to create a useful feed and a useful browser side view all in one go.
It's easier, for me, if I do everything server side in a controller - both the data and the view. Then refactor into a controller.feed method, then have the view be served up empty and consume the controller.feed. I can't tell if this is years of training and preference or a more natural way to discover both view and feed structure. It's not like they are independent in an MVC world.
I'm not talking about the source data structure here. The purpose of the feed is as a view feed or some other alternate construction built from the original data sources. The original data source is most likely a naturally occurring server side entity and not in question. What I'm talking about is often a mashed-up feed, possibly some source feed augmented with data from multiple independent sources. A very common pattern.
The combo of a view and the data that feeds it, straddles both the model and the view and thus the server and the client.
I would be more convinced that this process of "building it once with an architecture I don't want and then refactoring to an architecture I do want" was inefficient if I looked around and saw my colleagues doing a lot better, but I don't. When I look around I don't see the purely client side developers doing any of this - they are what I refer to as "consumer developers." They don't build many feeds at all.
And there are plenty of people building data sources. They go straight to a complete model. Ok, that's understandable.
But my question is, what's the most efficient way to get to a view model? I have to build it once, refine it, then refactor it. I started noticing that all my refactorings are:
- Separate the data from the View.
- Have the view consume the new feed.
Thoughts?
No comments:
Post a Comment