>> Friday, June 17, 2011
Can you compare the advantages and disadvantages of JSF vs. Struts. Both now, and from what you may know of futures, how and if JSF will evolve into a superior technology vs. Struts? Include how WSAD plays into the comparison if it will help differentiate the two.
This is a very popular question these days. In general, JSF is still fairly new and will take time to fully mature. However, I see JSF being able to accomplish everything Struts can, plus more. Struts evolved out of necessity. It was created by developers who were tired of coding the same logic again and again. JSF emerged both from necessity and competition.
Struts has several benefits:
* Struts is a mature and proven framework. It has been around for a few years and deployed successfully on many projects. The WebSphere Application Server admin console is a Struts application.
* Struts uses the Front Controller and Command patterns and can handle sophisticated controller logic.
* In addition to the core controller function, it has many add-on benefits such as layouts with Tiles, declarative exception handling, and internationalization.
There are disadvantages:
* Struts is very JSP-centric and takes other frameworks to adapt to other view technologies.
* Although Struts has a rich tag library, it is still geared towards helping the controller aspect of development and does not give a sense that you are dealing with components on a page. Therefore, it is not as toolable from a view perspective.
* Struts requires knowledge of Java™. Its goal was to aid Java developers, but not to hide Java. It does not hide details of the Java language to Web developers that well.
* ActionForms are linked programmatically to the Struts framework. Therefore, to decouple the model, you need to write transfer code or use utilities to move data from Action Forms to the Model on input.
JSF is an evolution of a few frameworks, including Struts. The creator of Struts, Craig McClanahan, is one of the JSF specification leads. Therefore, it is not by accident to see some overlap between Struts and JSF. However, one of JSF's major goals is to help J2EE Web applications to be easily developed using RAD tools. As such, it introduces a rich component model. JSF has several advantages:
* JSF is a specification from Sun® and will be included in future versions of the J2EE specification. All major vendors are pledging strong support for JSF.
* JSF uses the Page Controller Pattern and therefore aids in Page rich applications. Components can respond to event from components on a page.
* JSF has a well-defined request lifecycle allowing for plugability at different levels.
* One powerful example of plugability is building your own render toolkit. The ability to separate the rendering portion from the controller portion of the framework allows for wonderful opportunities of extensibility. Component providers can write their own toolkits to render different markup languages, such as XML or WML. In addition, the render toolkit is not tied to JSP.
* Because JSF has a rich component model, it favors a RAD style of development. I can now build my Web pages using drag and drop technology. In addition, JSF gives me a way to link visual components to back model components without breaking the layering.
JSF has disadvantages:
* JSF is still quite new and evolving. It will take some time to see successful deployments and wide usage. In addition, as vendors write components, they may not do everything you want them to.
* JSF by hand is not easier than Struts. Its goal was more oriented to RAD. Those who prefer to do things by hand (for example, the vi type guy who does not like IDEs) may find Struts easier to develop.
* Struts navigation may be a bit more flexible and adhere to more complex controller logic.
Multiple Sub-applications
One of the shortcomings in Struts 1.0 is manageability of the configuration file (commonly known as struts-config.xml) when the development of the application involves a sizable team. This problem arises because a Struts-based application must run under one controller servlet, the ActionServlet, and the ActionServlet can use only one struts-config.xml. It is not an issue when the project is relatively small and the team consists of a couple of developers; however, when the project size becomes significant and the project involves a large number of developers, maintaining all the mapping information in a single file becomes increasingly problematic.
Struts 1.1 solves this problem nicely by introducing multiple sub-applications. In Struts 1.1, each sub-application has its own struts-config.xml file. A large Struts-based application can thus be easily partitioned into largely independent modules, i.e. sub-applications, and each sub-team can maintain their struts-config.xml independently.
The sub-application scheme is a natural extension of the servlet context mapping scheme of the URI paths used by servlet containers. According to the Servlet standard, when the servlet container receives a request with a URL, the servlet container will try to match the prefix of the URI path to a deployed web-application in the container. What Struts 1.1 does is it maps the second prefix of the path to a sub-application. In effect, this prefix mapping scheme creates another level of namespace for each sub-application. For example, for the URI,
http://some-host.com/myApp/module2/editSubscription.do
/myApp is the context path for a web-application called "myApp" and /module2 is the sub-app prefix for a Struts sub-application called "module2".
DynaBean and BeanUtils
Another major complaint usually heard amongst Struts 1.0 users is the extensive effort involved in writing the FormBean (a.k.a. ActionForm) classes.
Struts provides two-way automatic population between HTML forms and Java objects, the FormBeans. To take advantage of this however, you have to write one FormBean per HTML form. (In some use cases, a FormBean can actually be shared between multiple HTML forms. But those are specific cases.) Struts' FormBean standard follows faithfully the verbose JavaBean standard to define and access properties. Besides, to encourage a maintainable architecture, Struts enforces a pattern such that it is very difficult to 'reuse' a model-layer object (e.g. a ValueObject from the EJB tier) as a FormBean. Combining all these factors, a developer has to spend a significant amount of time to write tedious getters/setters for all the FormBean classes.
Struts 1.1 offers an alternative, Dynamic ActionForms, which are based on DynaBeans. Simply put, DynaBeans are type-safe name-value pairs (think HashMaps) but behave like normal JavaBeans with the help of the BeanUtils library. (Both the DynaBeans and the BeanUtils library were found to be useful and generic enough that they have been 'promoted' into Jakarta's Commons project.) With Dynamic ActionForms, instead of coding the tedious setters/getters, developers can declare the required properties in the struts-config.xml files. Struts will instantiate and initialize Dynamic ActionForm objects with the appropriate metadata. From then onwards, The Dynamic ActionForm instance is treated as if it is an ordinary JavaBean by Struts and the BeanUtils library.
This is a very popular question these days. In general, JSF is still fairly new and will take time to fully mature. However, I see JSF being able to accomplish everything Struts can, plus more. Struts evolved out of necessity. It was created by developers who were tired of coding the same logic again and again. JSF emerged both from necessity and competition.
Struts has several benefits:
* Struts is a mature and proven framework. It has been around for a few years and deployed successfully on many projects. The WebSphere Application Server admin console is a Struts application.
* Struts uses the Front Controller and Command patterns and can handle sophisticated controller logic.
* In addition to the core controller function, it has many add-on benefits such as layouts with Tiles, declarative exception handling, and internationalization.
There are disadvantages:
* Struts is very JSP-centric and takes other frameworks to adapt to other view technologies.
* Although Struts has a rich tag library, it is still geared towards helping the controller aspect of development and does not give a sense that you are dealing with components on a page. Therefore, it is not as toolable from a view perspective.
* Struts requires knowledge of Java™. Its goal was to aid Java developers, but not to hide Java. It does not hide details of the Java language to Web developers that well.
* ActionForms are linked programmatically to the Struts framework. Therefore, to decouple the model, you need to write transfer code or use utilities to move data from Action Forms to the Model on input.
JSF is an evolution of a few frameworks, including Struts. The creator of Struts, Craig McClanahan, is one of the JSF specification leads. Therefore, it is not by accident to see some overlap between Struts and JSF. However, one of JSF's major goals is to help J2EE Web applications to be easily developed using RAD tools. As such, it introduces a rich component model. JSF has several advantages:
* JSF is a specification from Sun® and will be included in future versions of the J2EE specification. All major vendors are pledging strong support for JSF.
* JSF uses the Page Controller Pattern and therefore aids in Page rich applications. Components can respond to event from components on a page.
* JSF has a well-defined request lifecycle allowing for plugability at different levels.
* One powerful example of plugability is building your own render toolkit. The ability to separate the rendering portion from the controller portion of the framework allows for wonderful opportunities of extensibility. Component providers can write their own toolkits to render different markup languages, such as XML or WML. In addition, the render toolkit is not tied to JSP.
* Because JSF has a rich component model, it favors a RAD style of development. I can now build my Web pages using drag and drop technology. In addition, JSF gives me a way to link visual components to back model components without breaking the layering.
JSF has disadvantages:
* JSF is still quite new and evolving. It will take some time to see successful deployments and wide usage. In addition, as vendors write components, they may not do everything you want them to.
* JSF by hand is not easier than Struts. Its goal was more oriented to RAD. Those who prefer to do things by hand (for example, the vi type guy who does not like IDEs) may find Struts easier to develop.
* Struts navigation may be a bit more flexible and adhere to more complex controller logic.
Multiple Sub-applications
One of the shortcomings in Struts 1.0 is manageability of the configuration file (commonly known as struts-config.xml) when the development of the application involves a sizable team. This problem arises because a Struts-based application must run under one controller servlet, the ActionServlet, and the ActionServlet can use only one struts-config.xml. It is not an issue when the project is relatively small and the team consists of a couple of developers; however, when the project size becomes significant and the project involves a large number of developers, maintaining all the mapping information in a single file becomes increasingly problematic.
Struts 1.1 solves this problem nicely by introducing multiple sub-applications. In Struts 1.1, each sub-application has its own struts-config.xml file. A large Struts-based application can thus be easily partitioned into largely independent modules, i.e. sub-applications, and each sub-team can maintain their struts-config.xml independently.
The sub-application scheme is a natural extension of the servlet context mapping scheme of the URI paths used by servlet containers. According to the Servlet standard, when the servlet container receives a request with a URL, the servlet container will try to match the prefix of the URI path to a deployed web-application in the container. What Struts 1.1 does is it maps the second prefix of the path to a sub-application. In effect, this prefix mapping scheme creates another level of namespace for each sub-application. For example, for the URI,
http://some-host.com/myApp/module2/editSubscription.do
/myApp is the context path for a web-application called "myApp" and /module2 is the sub-app prefix for a Struts sub-application called "module2".
DynaBean and BeanUtils
Another major complaint usually heard amongst Struts 1.0 users is the extensive effort involved in writing the FormBean (a.k.a. ActionForm) classes.
Struts provides two-way automatic population between HTML forms and Java objects, the FormBeans. To take advantage of this however, you have to write one FormBean per HTML form. (In some use cases, a FormBean can actually be shared between multiple HTML forms. But those are specific cases.) Struts' FormBean standard follows faithfully the verbose JavaBean standard to define and access properties. Besides, to encourage a maintainable architecture, Struts enforces a pattern such that it is very difficult to 'reuse' a model-layer object (e.g. a ValueObject from the EJB tier) as a FormBean. Combining all these factors, a developer has to spend a significant amount of time to write tedious getters/setters for all the FormBean classes.
Struts 1.1 offers an alternative, Dynamic ActionForms, which are based on DynaBeans. Simply put, DynaBeans are type-safe name-value pairs (think HashMaps) but behave like normal JavaBeans with the help of the BeanUtils library. (Both the DynaBeans and the BeanUtils library were found to be useful and generic enough that they have been 'promoted' into Jakarta's Commons project.) With Dynamic ActionForms, instead of coding the tedious setters/getters, developers can declare the required properties in the struts-config.xml files. Struts will instantiate and initialize Dynamic ActionForm objects with the appropriate metadata. From then onwards, The Dynamic ActionForm instance is treated as if it is an ordinary JavaBean by Struts and the BeanUtils library.
0 comments:
Post a Comment