Interesting thought and I'd be happy to have a good discussion on it. I've always felt uploading files in an OO manner (especially with an MVC framework) wasn't as elegant as it could be.
DW On Fri, Oct 16, 2009 at 10:47 AM, Bob Silverberg <[email protected]>wrote: > I was just having an interesting conversation with John Whish about where > we think file uploads should occur in an OO application. We are both > processing our file uploads using a Filesystem object (FSO), which we both > agree should be responsible for doing the actual uploads, and simply > returning data about the upload to the caller (e.g., success, filename, > etc). > > We are also both currently call that FSO from a Service. We were > discussing whether to move that logic into the Business Objects (BOs) > themselves. I tend to try to keep my services dumb, and to push logic into > the BOs whenever possible, so this seemed like a candidate, but then we > discussed the fact that the BO shouldn't need to know that a file upload has > to occur at all. Maybe one day the file won't be uploaded, maybe it will > come from another source altogether. So we decided that the BO shouldn't > know about the file upload, and therefore shouldn't be responsible for > asking the FSO to do the upload, so that brings us back to the service. > > But then we discussed the fact that the file upload isn't really a model > concern at all. That the model should be independent of the client that's > calling it. So really the service shouldn't need to know that a file has to > be uploaded either. So that leaves the controller. Again, we try to keep > our controllers reasonably dumb and lean, so although this seemed to be the > place to do it in theory, we didn't like the idea of having to add a bunch > of code into each controller method that involved a file upload. > > So, by now you're probably wondering, why the heck is he writing this to > the Model-Glue group. Well, we figured that the job of uploading files > really belongs in the controller, and the controller is an extension of the > MVC framework, so maybe this really should be the job of the MVC framework. > The implementation that we imagine would involve convention, and would > basically be something along the lines of: > > 1. Framework receives request. > 2. Framework takes input data (i.e., form and url scope) and puts them into > event object. > 3. Framework looks for files to be uploaded - could be done via a > convention on naming of form fields (or maybe it's possible to look at the > content of a form field to determine if it contains a file?) > 4. Framework attempts to upload said files and places metadata about the > uploads (e.g., success, filename, etc) into the event object > 5. Framework then passes control to the controller for the event, which now > has access to all of the data, and the files are already uploaded. > > Of course this isn't a simple matter. What happens, for example, if one of > the uploads fails? Also, it might be nice if this could somehow be a > separate component that could be injected into the request lifecycle, rather > than adding it to the core of the framework itself. > > So this discussion raises a few questions for John and I: > > 1. Is it possible to do something like this without touching the core files > of MG? Is there a plugin point for something like this? > 2. Is this even a good idea at all? What thoughts do people have about > where this upload should occur? > 3. If it is a good idea, what ideas do people have about how to implement > it? Currently our thinking is to base it on convention, so it would happen > automatically. > > Thanks for taking the time to read this, and thanks for any thoughts you > may have. Perhaps I'll see some of you tonight/tomorrow in Raleigh. > > Cheers, > Bob > > -- > Bob Silverberg > www.silverwareconsulting.com > > > > -- “Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew.” Guillaume Apollinaire quotes --~--~---------~--~----~------------~-------~--~----~ Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en -~----------~----~----~----~------~----~------~--~---
