I still think batch command pattern is what you need. Java Report (no longer
published) October 2001(may be, if you want i can try to find it in my
literature) described it as it was also described on TSS
(http://www.theserverside.com/patterns/thread.jsp?thread_id=12949).
The applications don't need to know you busines layer interface so you can
change the business layer any way you want. What you need to provide to the
client apps is a list of commands and their parameters. BTW, Struts is a
perfect example of a command pattern implementation and quite successful.
The commands can be executed atomically or in a batch. So in very short
pseudo Java code, you's have something like this.
interface Command{
void execute();
void addParameter(String name, Object value);
}
interface AddUserCommand extends Command{
static final String USER_NAME = "username";
static final String PASSWORD = "password";
}
interface SendEmailCommand extends Command{
static final String TO= "to";
static final String FROM = "from";
static final String SUBJECT= "subject";
static final String BODY= "body";
}
interface BatchCommmand extends Command{
add(Command);
}
class CommandFactory{
static final int BATCH_COMMAND = 0;
static final int ADD_USER_COMMAND = 1;
static final int SEND_EMAIL_COMMAND = 2;
...
}
I would reccomend using a Factory pattern to generate the commands so your
client Applications deal with interfaces and not implementations which makes
it easier to change the implementations later on.
skipping the factory and command implementations your client application
would look like this
BatchCommand batch = CommandFactory.create(BATCH_COMMAND);
AddUserCommand addUser = CommandFactory.create(ADD_USER_COMMAND);
addUser.addParameter(AddUserCommand.USER_NAME,"jdoe" );
addUser.addParameter(AddUserCommand.PASSWORD,"neverland" );
SendEmailCommand sendEmail = CommandFactory.create(SEND_EMAIL_COMMAND);
sendEmail .addParameter(SendEmailCommand .TO,"jdoe@ jdoe.com" );
sendEmail .addParameter(SendEmailCommand .FROM,"processor@ xyz.com" );
sendEmail .addParameter(SendEmailCommand .SUBJECT,"registration" );
sendEmail .addParameter(SendEmailCommand .BODY,"You registration was
completed successfully." );
batch.add(addUser );
batch.add(sendEmail );
CommandProcessor cmdProcessor = ...
cmdProcessor.submit(batch)
or
batch.execute()
The above depends whether you want the commands themselves to be executable
by something else or execute on their own.
The sequence of the commands may reflect on their execution for example if
addUser fails don't do sendEmail but it is up to your requirements and
implementation.
Well thats enough for now.
----- Original Message -----
From: "Neil Stevens" <[EMAIL PROTECTED]>
To: "JDJList" <[EMAIL PROTECTED]>
Sent: Friday, May 10, 2002 10:56 AM
Subject: [jdjlist] Re: Business Layer Instantiation
> I don't think this answers my question, probably because I haven't
> explained myself very well.
>
> I want layers as follows :-
>
> App 1 , App 2, App 3, .......App N
> ----------Business Layer-----------------
> ---------Data Access Layer -----------
>
> I want to write the Business Layer now. But applications 1..n, are written
> by other people at other sites in the future. I want to minimise changes
to
> the Business Layer in the future. Obviously if new methods are required,
> they will have to be added.
>
> But if the same methods are called, but in a different order, and this
> performs badly, as in my two original examples, then I want the Business
> Layer to be configurable to solve this.
>
> I don't want to write a new Business Layer for each new Application.
> I don't want the Applications to have any knowledge of the data access
> layer, but they could perhaps choose a 'configuration' to run with.
>
> Maybe I could create a DataAccessConfiguration class, with a method for
> each access. Then create subclasses that override particular methods. Then
> maybe the clients could say something like :-
>
> myModel = BusinessModel.getInstance(
BusinessModel.ACCOUNTS_BROWSING_CONFIG );
>
> I could even provide a list of configurations that could be displayed to
> the user.
>
> Application developers could create new configurations if required, by
> subclassing an existing one.
>
> Any designers out there, with an opinion on this?
>
> Neil
>
> At 09:19 09/05/2002 -0400, you wrote:
> >I'd try a command pattern approach. This way you can create a batch of
> >commands executed by the server and the client gets to decide what
commands
> >to add to the batch thus giving you the required modularity. Sorry for
such
> >a short on details answer, let me know if yoou want a detailed
explanation.
> >
> >----- Original Message -----
> >From: "Neil Stevens" <[EMAIL PROTECTED]>
> >To: "JDJList" <[EMAIL PROTECTED]>
> >Sent: Thursday, May 09, 2002 9:19 AM
> >Subject: [jdjlist] Business Layer Instantiation
> >
> >
> > > Dear List,
> > >
> > > I am designing a business layer that will be accessed by a number of
> > > applications.
> > >
> > > By default I expect the model to instantiate objects on demand,
accessing
> > > the data layer as required.
> > >
> > > In Application A, a GUI tree is used to show part of the model. It
starts
> > > off collapsed, and the user opens up the branches that interest them.
The
> > > first time a node is expanded, it leads to a data access. If a node
isn't
> > > expanded, then the corresponding Business Object is not fully
constructed.
> > > This is fine.
> > >
> > > In Application B, a similar tree is used, but this time it starts of
fully
> > > expanded. There are several hundred leafs. This gives rise to dozens
of
> > > data accesses, which will be inefficient. I could write some code to
do a
> > > large query and construct the necessary Business Objects in one go.
But
> >how
> > > does the Business Model know when to use which style of construction?
> > > Should I pollute the Business Layer API with data access specific
> >parameters?
> > >
> > > I assume this type of problem will keep recurring, so I need a
> > > flexible/extendable approach.
> > >
> > > Any ideas ?
> > >
> > >
> > > To change your membership options, refer to:
> > > http://www.sys-con.com/java/list.cfm
> > >
> >
> >To change your membership options, refer to:
> >http://www.sys-con.com/java/list.cfm
>
>
> To change your membership options, refer to:
> http://www.sys-con.com/java/list.cfm
>
To change your membership options, refer to:
http://www.sys-con.com/java/list.cfm
