Mirko,
As John Kirby & Justin Wells have very well indicated, I think the basic
point is: partition, partition, partition. (Oh, yes, and encapsulate
properly at the same time.)
You could think of partitioning and encapsulation as two sides of the same
coin: you want to represent in the same class only properties and methods
that are "essential" to the kind of thing defined by that class;
partitioning involves separating out "inessential" properties and methods,
and defining them in other classes. Partitioning comes down to involving at
most a 3-partition scheme, which is commonly referred to as MVC (Model, View
& Controller, following Adele Goldberg's presentation of it in her SmallTalk
books; once again, the Xerox PARC people had thought all of this through
before the rest of us had ever heard about it (or, for some of us, were even
born)). The partitions can be thought of as very general categories of use,
actually partitioning objects according to which maximizes reuse and
minimizes maintenance (e.g. contains propagation of changes). However,
MVC - in so far as the connotations of its partition names are adhered to -
is really just a special case of a universal 3-partition scheme (which
doesn't have any very good name in its full abstraction). Really, at most a
3-partition scheme is needed, because such a scheme achieves independence in
both aspects of definition - declaration and implementation - of Model
objects and View objects; Controller objects effectively encapsulate any
relationship between Model & View objects that depends on certain specific
declarations (so changes to Model object, for example, propagate at most to
Controller, but not to View, objects). Sometimes, people forego Controller
objects when the relationship can be based on extremely generic interfaces -
for example, the interfaces in the new Java Collections API (see java.util).
Sometimes, people are extra-careful and rely as much as possible only on
generic interfaces between Model & Controller or View & Controller, or both
(i.e. generic controllers, which servlets can be).
Justin's web page presents all of this in a clear, concise, practical as
well as theoretically-grounded way (along with free software!). (I haven't
tried it, but the description looks great.)
Just to put in another 2 cents, here is how I am writing my "generic"
servlets, treating the servlet as a kind of controller that hooks up model
and view objects. My top-level "model" objects are generally (possibly
nested) collection objects (e.g. "tables") that can (eventually) contain any
kind of "user-defined" model object, e.g. an Employee object. My view
objects generally include (reference) a template, and render by looping (for
an appropriate part of the template) over the collection objects, in turn
getting a view object for each Model object in the collection, and asking
these "nested" view objects to render (a ViewManager handles any pooling of
view objects). At the "bottom" level, I am using "row" objects or "row
types", which "wrap" a Model object and support a generic style of access to
its properties as columns. These "row" objects can be implemented using
BeanDescriptors and related classes, or using generic reflection as in the
Reflection API (I believe Justin does something like this), or specifically
for any of the pickier Model objects. These "row" objects are also
collections, with iterators over their columns, so I am relying at this
point only an extremely generic interface (and the "row" in any case is like
a controller between a View object and a Model object).
Anyway, here's the "generic" servlet - roughly, at least for its semantics
(RequestManager, RequestFormat, DataRequest & ViewRequest are my own
classes; login stuff and other real-life nastiness is omitted):
doPost ( ServletRequest request, ServletResponse response ) {
RequestFormat = requestManager.getRequestFormat ( this.getServletContext
( ) );
DataRequest dataRequest = requestFormat.getDataRequest ( request );
ViewRequest viewRequest = requestFormat.getViewRequest ( request );
View view = viewManager.get ( viewRequest );
Object data = dataManager.get ( dataRequest );
HTML.append ( view.render ( data ) );
}
Hope all of this helps somewhat.
Best,
Carl
Carl R. Castro
[EMAIL PROTECTED]
(415) 351-CARL
-----Original Message-----
From: Mirko Wolf <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, April 09, 1999 8:20 AM
Subject: a design question
>Hi there,
>
>Here is another question how to design functions for a servlet.
>IMHO for every request made to a servlet the service function is called
again.
>But what happens, when a critical function is called by two or more
service functions at the same time?
>For instance a function which handles a database connection and the
belonging queries.
>What happens, when a second service function call this method while it
handle's a database querie for the first one?
>The first one will have no chance to complete the request, right?
>Should the database function synchronized or is it better to implement the
SingleThreadModel?
>I think it is easier to implement the SingleThreadModel, because i've a lot
of functions the must be synchronized and
>then i'am afraid to have a deadlock in the system.
>Any comments or suggestions?
>
> Mirko
>
>___________________________________________________________________________
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff SERVLET-INTEREST".
>
>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>Resources: http://java.sun.com/products/servlet/external-resources.html
>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
