monday morning theory question

[Adam Hardy <ah...@cyberspaceroad.com>]

Here's a question to all you theorists out there about division of a 
use-case between model and controller.

I have a use case where my struts app receives a http post from PayPal 
detailing a transaction which it has just processed for me, taking 
payment from a customer I sent there from my website.

The app has to verify various parameters and then if correct, update the 
database to reflect the purchase, by doing the following steps:

(1) check the value of various parameters
(2) use java.net.HttpURLConnect to do an http post back to PayPal
(3) check the response to the post says 'verified'
(4) update the user's records in the database to reflect the confirmed 
purchase
(5) send an email to user thanking them & confirming purchase

What I am trying to work out is which bits belong to the controller, 
i.e. in my Action class, and which bits I should write new Factory 
classes for.

I am thinking of doing (1) in my Action, and writing different methods 
in a 'PaymentFactory' class: checkPayPal() for (2) & (3), 
updatePayment() for (4) and sendReceipt() for (5).

Any advice welcome,
thanks
Adam
-- 
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: monday morning theory question

[HG <st...@nospam.websolver.dk>]

Hi Adam

As I read your post you are doing business logic here.

I used a design somehow similar to the Business Delegate pattern.
The business delegate takes care of the whole purchase-workflow, except
"simple" field validations on the values coming along with the ActionForm
instance in progress.

- You can argue that it is "business logic" that you must verify against
PayPal
- You can argue that it is "business logic" that you must send a email
confirming the purchase

My advice is to put them in a business delgate and have the action call one
method on the delgate, which takes care of the workflow.

Pseudo-code

Class PurchaseDelgate (POJO)

public void doPurchase(whatever params your need)
{
    // 1. Do more complex business logiv validation
    // 2. Verify against PayPal
    // 3. Save to DB
    // 4. Confirm by E-mail
}

Your Struts action class:

execute(.....)
{
    doPurchase(bla bla params)
}

I even use a Session Facade "behind" my business delgates so the flow is
Action->Business delegate->Session Facade
I do not know if that approach would be overkill for your solution...?

Anyone has other hints, ideas, anything...?

Regards

Henrik





----- Original Message ----- 
From: "Adam Hardy" <ah...@cyberspaceroad.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Monday, January 26, 2004 11:16 AM
Subject: monday morning theory question


> Here's a question to all you theorists out there about division of a
> use-case between model and controller.
>
> I have a use case where my struts app receives a http post from PayPal
> detailing a transaction which it has just processed for me, taking
> payment from a customer I sent there from my website.
>
> The app has to verify various parameters and then if correct, update the
> database to reflect the purchase, by doing the following steps:
>
> (1) check the value of various parameters
> (2) use java.net.HttpURLConnect to do an http post back to PayPal
> (3) check the response to the post says 'verified'
> (4) update the user's records in the database to reflect the confirmed
> purchase
> (5) send an email to user thanking them & confirming purchase
>
> What I am trying to work out is which bits belong to the controller,
> i.e. in my Action class, and which bits I should write new Factory
> classes for.
>
> I am thinking of doing (1) in my Action, and writing different methods
> in a 'PaymentFactory' class: checkPayPal() for (2) & (3),
> updatePayment() for (4) and sendReceipt() for (5).
>
> Any advice welcome,
> thanks
> Adam
> -- 
> struts 1.1 + tomcat 5.0.16 + java 1.4.2
> Linux 2.4.20 Debian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org