Separate frontend from core code

Discussions

General J2EE: Separate frontend from core code

  1. Separate frontend from core code (2 messages)

    Hi there,

    I am trying to build a sort of API in java. It contains a core set of logic and data that I want to be able to run anywhere - web, GUI, mobile, servlet, command-line, etc.

    The prototype needs a GUI frontend as a standalone app.

    I want the core code to work even from the command line, so it has to work as is. It must not however know about any frontend that is accessing it.
    The frontend obvisouly needs to know about the core code - that is not a problem.

    I have reviewd the MVC pattern, the observer and chain-of-responsibility patterns. I've also looked at the "callback" method.

    I still am a bit confused at which is the best practice. Please send me any suggestions.

    Thanks a lot!
    KS
  2. Separate frontend from core code[ Go to top ]

    any tips?
  3. Separate frontend from core code[ Go to top ]

    I have developed a similar framework... and it has morphed a lot from what i percieved it to be to begin with. Here are a few tips I which i had before i wrote is :-P. BTW what I have is a Workflow engine, I don't know if this is what you are looking for.

    the system fits in to an environment with a central controller...

    1. <user> -> <action> -> controller -> <Workflow Controller> -> processor
    2. processor -> (after processing) -> controller
    3. controller -> viewmanager -> view -> user

    The processor interacts witht the request chain through a single object (I call it the RequestDecorator), it is basically a decorator pattern based object that lets the processor get parameters from the request domain, and attach processed data to the request domain.

    thus if i have to switch from lets say a web based system to a messaging based system, I'll switch the implementation of RequestDecorator. Also I realized that parameters / data interaction with the request / response sections are often placed in different domains, so i characterised domains based on its properties like

    - is it Binary or Text?
    - is the lifespan across the conversation or just this request?
    - is the lifespan across the context or local?
    - is the domain read only?

    there is seven or eight of them... and basically the request decorator uses existing domains or implement the domain to service the processor.

    I have been using this in the web context, but i'll need to use the framework in the near futre for JMS and Swing based applications. I think it'll adapt well to both of these views... if you need to look at the code, mail me at adiand at usa dot net.

    cheers
    Adi