Design Patterns web based applications

Question

I am designing a simple web-based application  I am new to this web-based domain I needed your advice regarding the design patterns like how responsibility should be distributed among Servlets  criteria to make new Servlet  etc   Actually  I have few entities on my home page and corresponding to each one of them we have few options like add  edit and delete  Earlier I was using one Servlet per options like Servlet1 for add entity1  Servlet2 for edit entity1 and so on and in this way we ended up having a large number of servlets   Now we are changing our design  My question is how you exactly choose how you choose the responsibility of a servlet  Should we have one Servlet per entity which will process all it s options and forward request to the service layer  Or should we have one servlet for the whole page which will process the whole page request and then forward it to the corresponding service layer  Also  should the request object forwarded to service layer or not

User · Answer

IMHO  there is not much difference in case of web application if you look at it from the angle of responsibility assignment  However  keep the clarity in the layer  Keep anything purely for the presentation purpose in the presentation layer  like the control and code specific to the web controls  Just keep your entities in the business layer and all features  like add  edit  delete  etc in the business layer  However rendering them onto the browser to be handled in the presentation layer  For  Net  the ASP NET MVC pattern is very good in terms of keeping the layers separated  Look into the MVC pattern

User · Answer

A bit decent web application consists of a mix of design patterns  I ll mention only the most important ones   Model View Controller pattern The core  architectural  design pattern you d like to use is the Model-View-Controller pattern  The Controller is to be represented by a Servlet which  in directly creates uses a specific Model and View based on the request  The Model is to be represented by Javabean classes  This is often further dividable in Business Model which contains the actions  behaviour  and Data Model which contains the data  information   The View is to be represented by JSP files which have direct access to the  Data  Model by EL  Expression Language   Then  there are variations based on how actions and events are handled  The popular ones are   Request  action  based MVC  this is the simplest to implement  The  Business  Model works directly with HttpServletRequest and HttpServletResponse objects  You have to gather  convert and validate the request parameters  mostly  yourself  The View can be represented by plain vanilla HTML CSS JS and it does not maintain state across requests  This is how among others Spring MVC  Struts and Stripes works   Component based MVC  this is harder to implement  But you end up with a simpler model and view wherein all the  quot raw quot  Servlet API is abstracted completely away  You shouldn t have the need to gather  convert and validate the request parameters yourself  The Controller does this task and sets the gathered  converted and validated request parameters in the Model  All you need to do is to define action methods which works directly with the model properties  The View is represented by  quot components quot  in flavor of JSP taglibs or XML elements which in turn generates HTML CSS JS  The state of the View for the subsequent requests is maintained in the session  This is particularly helpful for server-side conversion  validation and value change events  This is how among others JSF  Wicket and Play  works    As a side note  hobbying around with a homegrown MVC framework is a very nice learning exercise  and I do recommend it as long as you keep it for personal private purposes  But once you go professional  then it s strongly recommended to pick an existing framework rather than reinventing your own  Learning an existing and well-developed framework takes in long term less time than developing and maintaining a robust framework yourself  In the below detailed explanation I ll restrict myself to request based MVC since that s easier to implement   Front Controller pattern  Mediator pattern  First  the Controller part should implement the Front Controller pattern  which is a specialized kind of Mediator pattern   It should consist of only a single servlet which provides a centralized entry point of all requests  It should create the Model based on information available by the request  such as the pathinfo or servletpath  the method and or specific parameters  The Business Model is called Action in the below HttpServlet example  protected void service HttpServletRequest request  HttpServletResponse response  throws ServletException  IOException       try           Action action   ActionFactory getAction request           String view   action execute request  response            if  view equals request getPathInfo   substring 1                 request getRequestDispatcher  quot  WEB-INF  quot    view    quot  jsp quot   forward request  response                     else               response sendRedirect view      We d like to fire redirect in case of a view change as result of the action  PRG pattern                       catch  Exception e            throw new ServletException  quot Executing action failed  quot   e            Executing the action should return some identifier to locate the view  Simplest would be to use it as filename of the JSP  Map this servlet on a specific url-pattern in web xml  e g   pages      do or even just   html  In case of prefix-patterns as for example  pages   you could then invoke URL s like http   example com pages register  http   example com pages login  etc and provide  WEB-INF register jsp   WEB-INF login jsp with the appropriate GET and POST actions  The parts register  login  etc are then available by request getPathInfo   as in above example  When you re using suffix-patterns like   do    html  etc  then you could then invoke URL s like http   example com register do  http   example com login do  etc and you should change the code examples in this answer  also the ActionFactory  to extract the register and login parts by request getServletPath   instead   Strategy pattern The Action should follow the Strategy pattern  It needs to be defined as an abstract interface type which should do the work based on the passed-in arguments of the abstract method  this is the difference with the Command pattern  wherein the abstract interface type should do the work based on the arguments which are been passed-in during the creation of the implementation   public interface Action       public String execute HttpServletRequest request  HttpServletResponse response  throws Exception     You may want to make the Exception more specific with a custom exception like ActionException  It s just a basic kickoff example  the rest is all up to you  Here s an example of a LoginAction which  as its name says  logs in the user  The User itself is in turn a Data Model  The View is aware of the presence of the User  public class LoginAction implements Action        public String execute HttpServletRequest request  HttpServletResponse response  throws Exception           String username   request getParameter  quot username quot            String password   request getParameter  quot password quot            User user   userDAO find username  password            if  user    null                request getSession   setAttribute  quot user quot   user      Login user              return  quot home quot      Redirect to home page                    else               request setAttribute  quot error quot    quot Unknown username password  Please retry  quot       Store error message in request scope              return  quot login quot      Go back to redisplay login form with error                       Factory method pattern The ActionFactory should follow the Factory method pattern  Basically  it should provide a creational method which returns a concrete implementation of an abstract interface type  In this case  it should return an implementation of the Action interface based on the information provided by the request  For example  the method and pathinfo  the pathinfo is the part after the context and servlet path in the request URL  excluding the query string   public static Action getAction HttpServletRequest request        return actions get request getMethod     request getPathInfo        The actions in turn should be some static applicationwide Map lt String  Action gt  which holds all known actions  It s up to you how to fill this map  Hardcoding  actions put  quot POST register quot   new RegisterAction     actions put  quot POST login quot   new LoginAction     actions put  quot GET logout quot   new LogoutAction             Or configurable based on a properties XML configuration file in the classpath   pseudo  for  Entry entry   configuration        actions put entry getKey    Class forName entry getValue    newInstance        Or dynamically based on a scan in the classpath for classes implementing a certain interface and or annotation   pseudo  for  ClassFile classFile   classpath        if  classFile isInstanceOf Action class            actions put classFile getAnnotation  quot mapping quot    classFile newInstance              Keep in mind to create a  quot do nothing quot  Action for the case there s no mapping  Let it for example return directly the request getPathInfo   substring 1  then   Other patterns Those were the important patterns so far  To get a step further  you could use the Facade pattern to create a Context class which in turn wraps the request and response objects and offers several convenience methods delegating to the request and response objects and pass that as argument into the Action execute   method instead  This adds an extra abstract layer to hide the raw Servlet API away  You should then basically end up with zero import javax servlet   declarations in every Action implementation  In JSF terms  this is what the FacesContext and ExternalContext classes are doing  You can find a concrete example in this answer  Then there s the State pattern for the case that you d like to add an extra abstraction layer to split the tasks of gathering the request parameters  converting them  validating them  updating the model values and execute the actions  In JSF terms  this is what the LifeCycle is doing  Then there s the Composite pattern for the case that you d like to create a component based view which can be attached with the model and whose behaviour depends on the state of the request based lifecycle  In JSF terms  this is what the UIComponent represent  This way you can evolve bit by bit towards a component based framework   See also   Examples of GoF Design Patterns in Java  39 s core libraries Difference between Request MVC and Component MVC Show JDBC ResultSet in HTML in JSP page using MVC and DAO pattern What components are MVC in JSF MVC framework  JSF Controller  Service and DAO

User · Answer

BalusC excellent answer covers most of the patterns for web applications   Some application may require Chain-of-responsibility pattern     In object-oriented design  the chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects  Each processing object contains logic that defines the types of command objects that it can handle  the rest are passed to the next processing object in the chain    Use case to use this pattern   When handler to process a request command  is unknown and this request can be sent to multiple objects  Generally you set successor to object  If current object can t handle the request or process the request partially and forward the same request to successor object    Useful SE questions articles   Why would I ever use a Chain of Responsibility over a Decorator   Common usages for chain of responsibility   chain-of-responsibility-pattern from oodesign  chain of responsibility from sourcemaking

User · Answer

In the beaten-up MVC pattern  the Servlet is  C  - controller   Its main job is to do initial request evaluation and then dispatch the processing based on the initial evaluation to the specific worker  One of the worker s responsibilities may be to setup some presentation layer beans and forward the request to the JSP page to render HTML   So  for this reason alone  you need to pass the request object to the service layer   I would not  though  start writing raw Servlet classes   The work they do is very predictable and boilerplate  something that framework does very well  Fortunately  there are many available  time-tested candidates   in the alphabetical order    Apache Wicket  Java Server Faces  Spring to name a few

User · Answer

I have used the struts framework and find it fairly easy to learn  When using the struts framework each page of your site will have the following items   1  An action which is used is called every time the HTML page is refreshed  The action should populate the data in the form when the page is first loaded and handles interactions between the web UI and the business layer  If you are using the jsp page to modify a mutable java object a copy of the java object should be stored in the form rather than the original so that the original data doesn t get modified unless the user saves the page   2  The form which is used to transfer data between the action and the jsp page  This object should consist of a set of getter and setters for attributes that need to be accessible to the jsp file  The form also has a method to validate data before it gets persisted    3  A jsp page which is used to render the final HTML of the page  The jsp page is a hybrid of HTML and special struts tags used to access and manipulate data in the form  Although struts allows users to insert Java code into jsp files you should be very cautious about doing that because it makes your code more difficult to read  Java code inside jsp files is difficult to debug and can not be unit tested  If you find yourself writing more than 4-5 lines of java code inside a jsp file the code should probably be moved to the action

[java] Design Patterns web based applications

Examples related to java

Examples related to design-patterns

Examples related to jsp

Examples related to servlets