I kinda disagree with the idea that a service shouldn't know what kind
of request it's responding to. That's an awfully broad notion. I do
agree that file uploads aren't the concern of the business objects
themselves, which leaves us with 2 options: putting the functionality
in the framework itself or building a portion of the service layer to
handle it.
Personally I think that things like file uploads, unit conversion
(i.e. Fahrenheit to Celsius), validation and other things that aren't
model concerns, but are still required by the application, belong in
the service layer. In fact I would go so far as to say that this is
the ideal situation for a SERVICE to actually fit its description. The
term "service" implies action, something that provides functionality
that you don't have yourself. A diaper service, an auto repair
service, a file upload handling service, a shipping service... things
that don't help describe the business rules of the domain but are
required for the full functionality of the application to come to
fruition.
This becomes especially obvious if you think of CF tags as services,
especially the ones with action="" attributes that have several
options, as services themselves. An FTP service makes sense because it
handles all the FTP operations for an application. A mail service
makes a great deal of sense and analogizes 1:1 to real-world
"services" (i.e. USPS and FedEx) that we use every day. Yet another
example is the ColdFuson indexing and search service which even gets
installed separately and runs _as a service_ on a machine that
processes requests _for that service_. I don't think you could
possibly find more appropriate examples of what a "service layer"
should do.
Consider also the fact that the file upload itself is purely a
function of the webserver and CF and that you're not really processing
an "upload" but, essentially, a copy operation from the temp directory
to a permanent location. The server takes care of receiving the data
from the HTTP header and turning it into a file on disk. I don't see
this being a framework-level operation any more than logging a user
into a website is. There is, however, a solution to this problem
that's been part of MG for years and would pretty much satisfy the
needs and objections of everyone.
I wouldn't mind seeing an actionpack to do this, but adding it into
the framework is pretty much a complete departure from the charter of
Model-Glue (which is to provide a connection between HTML pages and a
model). Even more so when you start talking about convention-based
operations. Model-Glue has, and I hope always will be, configuration-
based (seriously, if you want a convention-based framework, there are
2 really good ones out there). Adding in an actionpack allows this
functionality to be provided so that you could do something like this:
<event-handler name="files.upload">
<broadcasts>
<message name="uploadFile">
<value name="formField" value="someFooFile" />
<value name="destination" value="c:\someFooPath" />
<!-- add in the other cffile attributes if you want -->
</message>
</broadcasts>
<results>
<result name="success" do="files.goodJob" />
<result name="fail" do="files.youSuck" />
<result name="epicFail" do="files.omgDoYouSuck" />
</results>
</event-handler>
Then again, you don't really need an actionpack to make that work, and
you could, if you wanted, stuff all that crap in the controller. Or
you could build a nice, abstracted FileService that any OO app could
use and have the controller lean on that to do the heavy lifting
(which is the relationship that controllers and services are supposed
to have in the first place). Either way, it would work.
And, as always, keep in mind that it's all opinion and nobody is ever
right, they're just less wrong sometimes. ;)
J
On Oct 16, 2009, at 9:47 AM 10/16/09, Bob Silverberg 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). ...
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
