K
Kirk Haines
It's really no different with a web project than with any other project.
The web portion is nothing more than the interface between your software and
the user. So if you would use some sort of an object model for a GUI app,
you will do so for a web based app. If you would build some custom classes
for handling your data or performing specific business tasks for a GUI app,
you'll do the same for a web app. About the only difference is going to
show up when dealing with the actual user interface, and that difference is
going to boil down to how well whatever code library or templating system
you are using to handle your interface bits. Do they let you use OO design
paradigms? Can you define reusable components?
Rails definitely takes a person down this direction.
I'm trying to think of frameworks for Ruby that actually take the approach
of saying that your components are themselves objects. The only two for
sure that I can think of right now (and appologies if I am forgetting any)
are my Iowa framework (http://enigo.com/projects/iowa) and Borges
(http://borges.rubyforge.org). Maybe SWS? I forget the URL for it, though.
David can certainly give you examples of how he uses OO design ideas with
web apps using Rails, so I'll just lay out, generally, how I approach it
with Iowa.
I use an object-relational modeling package for all of my database
interactions. In my case, I use Kansas. There are so many advantages to an
ORM tool in terms of reducing lines of code and making applications faster
and simpler to write and to read later that using a tool like this for your
model data is usually a huge win.
If I have common sorts of back end data manipulation or business logic tasks
that are going to be performed at multiple different points in the
application, I abstract those capabilities out to their own classes.
Then for the user interface I break it down to find the areas where there
are going to be commonly repeated elements and I put each of those into its
own class (component). So, for example, a standard page header and footer
each get their own component. A standard navigation bar would get its own
component. If there is some reporting tool or table that will be used in
multiple places, I can write it as a seperate component. Whatever. Once I
have all of the multiuse pieces abstracted into their own classes, I then
code the components that describe how the app ties together and that use the
header and footer and report tool and whatever other multiuse components I
have created.
Back to front, it is all objects and everywhere that I can I refactor and
reuse.
Kirk Haines