You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Saimon Moore <sa...@yahoo.co.uk> on 2001/11/18 14:06:16 UTC

design overkill??

Hi all...

Be warned I ramble on a lot here!!!

I'm designing a web app to handle company logistics for a friend and I'm 
basing it on Turbine 2.x ( I know a good thing when I see one).

This is sort of an experiment for me becuase it'll be my first turbine-based 
web app and also the first app I would have completely designed myself 
(Domain designer, App architect, developer and template designer all rolled 
into one big mess ;) ).

I've read up lot on oop design, best practices, avoiding coupling, the use of 
design patterns to allow flexibility...

Basically I want to create a well designed app following best practice oop 
principles that is modularised, can be easily extended, promotes reuse, 
handles complexity well and scales well. (i.e. I want design paradise .. ;) )

At the moment, the experimental app is only a very small scale but I'd like 
it to be able to scale well should it need to. 
For the moment, I don't want it to be distributed and no EJB's either, I'm 
trying out a web-centric approach first off, and if need be will use 
load-balancing to provide scale-up. 

After this web-centric app is out, I plan to re-design with distribution in 
mind with or without EJB's (maybe using Jini services and Java Spaces....I'll 
cross that bridge when I come to it...) and compare it too the previous 
approach.

I've come up with a preliminary design but I'm a bit confused about the whole 
thing...

I'd really appreciate any input here (pros and cons), because I'm having 
doubts about wether it's overkill or not or wether basic Turbine without my 
extentions would do the job nicely. 

Basically my system, involves turbine 2.x at the core, using it's services, 
but in order to handle application complexity, I decided to introduce extra 
infrastructure (I've been quite influenced by what I've been reading).

Here goes...

Didaxe Example:
<begin-example>
1. We have a template for Course Management with three buttons (Create, 
Update,Cancel)!
 
2. On clicking the Create button, causes a doCreate() method to be executed 
in the Turbine Course Action to be executed.
 
3. In this method, the appropriate EventFactory for the current Module is 
provided by the Module Manager Service (A Turbine Service) which generates a 
CourseEvent object setting it's action index to 1 (just as an example, it 
corresponds to Create_Course)

4. The StateMachine (Also a Turbine service) is then called passing in the 
Event object, the RunData and Context object.
 
5. The StateMachine (SM) then looks up the event handler for this event, and 
delegates to it. (Actually it first searches for the handler in the Turbine 
Pool Service and if it doesn't find it instantiates a new one and sticks it 
in the pool. Then it calls the handlers init()- (there will be no efect on 
this if it has already been instantiated), doStart(), execute() and doEnd() 
methods). 

6. I've now come up with two possibilities ( actually I can think of a few 
more):
  A.) The eventhandler follows the Mediator pattern in combination with the 
Command pattern. It uses the Event object's getAction() method (which defines 
what type of action has been called in this case Create_Course) and the 
FlowMapping object for the event (which defines where flow should go to if 
successfull or not and is graciously donated by the FlowManagerService ) to 
create the appropriate Command objects (passing in RunData, Context ). Then 
it executes the Command objects execute(data, context) method for all the 
Command objects defined in the FlowMapping object for this handler which 
causes the appropriate domain/peer object to do it's stuff, populates the 
context using pull tools. Depending on the result of the Commands it set's 
the next template...This way I could have the possibility of introducing an 
Undo ability for the web app. 
 
B.) The handler does everything itself according to what action 
the event is (getAction()) to perform whatever is necesary,passing in 
RunData, Context to update the Domain, handle business logic, using pull 
tools to populate the context accordingly and set the next Template.
 
In either case, any 'State' change in the application is set using the 
StateMachine (this holds a record of the application state during run-time).
When the handler has finished the SM uses the ModelNotifier to take care of 
notifying any registered listeners for this event (This could perhaps just 
queue the notifications and they will be executed at intervals by the Turbine 
Scheduler service.)
 
7. State for the app has been changed (or not), listeners have been notified 
, the context has now been populated , the next Template has been set and 
control can now be returned to theTurbine action doXXX() method and back into 
normal Turbine control....

</end of example>

Those of you who have had a look at the Java Petshop, will notice that I've 
taken a few ideas from there and also a few ideas from various articles I've 
read...It is probably immediately obvious that I've not got a good deal of 
experience

and finally...

My doubts....is all of this necessary...

Why don't I just handle business logic in the action doXXX() methods directly 
like scarab does... 

I'm using a Flow Mapping system to be able to define where to go next 
depending upon the results of the handling of a particular event, thus not 
hardcoding the flow directly in the code. Is this so important or could I get 
away with hard-coding...?

By using this event handling system am I just adding extra objects into the 
system, just postponing something that could have easily been done a few 
method calls before or is it a good way to provide flexibility into the 
system. I look at what I've come up with and I keep finding parallels within 
Turbine current design that makes me think that I'm just designing for 
design's sake with no real idea of what I need to do...

Does an app need a StateMachine to encapsulate application state during run 
time or can that be left implicitly within the Domain models state as 
reflected in the DB?

( I think I've got what is known as 'analysis paralysis' or is it 'design 
paralysis'.. ;) )

Please feel free to crititcise at will! I'd just like a few brief comments 
about wether I'm going off on a tangent or not. 

I'd love to hear a few opinions, criticisms and hopefully decide for myself 
what would be the best thing to do...or what the heck should I perhaps just  
try it (i.e. go ahead and implement it ) and then see...

Yours truly,

Saimon Moore

P.S. A bit brain numb ;) I was up quite early this morning and I'm riding a 
caffeine high...that probably explains all of the above...)

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>