ASP.NET and Struts: Web Application Architectures


how the industry standard patterns implemented in ASP.NET and Struts have helped reduce code complexity and accelerate development times. We will also explore the advantages and disadvantages of each offering, and the utility that they bring to the next generation of development.

These early e-commerce Web sites were often powered by Java-based technologies, including JSPs, EJBs, Servlets, and JDBC; or Microsoft-based technologies, including ASP, VBScript, MTS, ADO, COM and COM+. Although these technologies worked, most of the sites were built quickly without giving much thought to scalability, reliability or security.

Guys..Post your views regarding ASP.NET and J2EE Struts

__________________
The KINGMAKER
Makes Every Thing Possible

Stuffs (My Blog)

The webform controls sound very attractive in theory. One can simply drag and drop all the web page components into the designer. However, I once took a class where simple ASP.NET was taught. I found out that the webform components are not flexible at all in terms of layout. It's much easier to write layout using HTMl and CSS.

Do webform controls really work nicely in terms of layout? Could you develop a professional looking website just by using the drag and drop method?

Security plays a key role in every stage of an application, from the design, to development, to deployment, and into daily use. Struts does not offer any specific security features, as it relies on the security built into the JSP/Servlet and J2EE frameworks. The J2EE framework does offer basic authentication and authorization services; however the exact implementation is often dependent on the J2EE server. On the other hand, the .NET Framework, and ASP.NET in particular, offer many advanced security features that go above and beyond such simple tasks as authentication and authorization.

if u refer this url u can get more idea..

ASP.NET and Struts: Web Application Architectures

the next important thing regarding struts is
Caching

Web applications frequently use caching to speed up client access times. In Struts, caching content is left up to the developer, or to third-party caching systems such as JCACHE. In other words, the developer has to build a custom caching system or integrate a third-party product into any application. Quite often, a developer will build caching functionality into custom tag libraries. Although some J2EE servers offer native caching features, the Java community has yet to develop a standard caching interface. In the future, the J2EE Tiles functionality will provide a built-in system for page and object level caching.

ASP.NET, however, has numerous built-in caching functions, including object-level caching (storing code objects), input parameter-based caching (storing a dynamic page based on input parameters), and time-based caching (storing content for a specified time). Depending on your needs, you can cache data objects or an entire dynamic page. If your display depends on user input, but the actual display changes infrequently, you can even cache the page based on input parameters from the HTTP Request. In other words, you can cache a product page that depends on the product ID. ASP.NET will automatically cache one page for each input parameter (product) that is requested. Subsequent requests for the same product will pull the cached page rather than regenerate it from scratch. All of the ASP.NET caching mechanisms can be configured declaratively with attributes (that is to say, no coding required). Or you can access the cache programmatically through a simple API. The ASP.NET caching systems offer a wide range of options for improving the user response and decreasing access times for static or semi-static content.

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me

Struts supports MVC2 Architecture..is it ASP.NET Supprts?

__________________
The KINGMAKER
Makes Every Thing Possible

Stuffs (My Blog)

hi,
I am not sure of MVC2 architech, can anyone explain about that,
any referance article available.. since i didn't find any resource!

Thanks in advance
Regards
Manivannan

hi

i ll explain u about MVC2 clearly by referring MVC1

MVC1 was a first generation approach that used JSP pages and the JavaBeans component

architecture to implement the MVC architecture for the Web.
Requests are sent to a JSP page that implements Controller logic and calls out to the “Model” for data to update the “View.” This approach combines Controller and View functionality within a JSP page and therefore breaks the MVC paradigm. MVC1 is appropriate for simple development and prototyping. It is not, however, recommended for serious development.

The MVC2 architecture is actually a modified MVC implementation. The major modification is that the Model no longer fires events to its Views.
The central issue is that the life cycle of the servlet (the Controller and View) is not necessarily the life cycle of the application, as it is with desktop applications. The servlet begins with a user request, typically generated by a Web browser, and ends with the response. The Model, however, may, and typically does, persist across the life of multiple servlets. Therefore, it cannot reliably notify View objects of internal state changes.

This has the following consequences:

The Model is now more “generic,” because it no longer implements the logic for

registering and unregistering listeners, nor does it need to implement logic to generate

events.

The View is now responsible for capturing Model state changes.

The Controller now notifies the View of state changes to the Model.

The Controller must manipulate the Model before notifying the View.

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me

MVC1 was a first generation approach that used JSP pages and the JavaBeans component architecture to implement the MVC architecture for the Web. HTTP requests are sent to a JSP page that implements Controller logic and calls out to the “Model” for data to update the “View.” This approach combines Controller and View functionality within a JSP page and therefore breaks the MVC paradigm. MVC1 is appropriate for simple development and prototyping. It is not, however, recommended for serious development. The MVC2 architecture is actually a modified MVC implementation. The major modification is that the Model no longer fires events to its Views. The central issue is that the life cycle of the servlet (the Controller and View) is not necessarily the life cycle of the application, as it is with desktop applications. The servlet begins with a user request, typically generated by a Web browser, and ends with the response. The Model, however, may, and typically does, persist across the life of multiple
servlets. Therefore, it cannot reliably notify View objects of internal state changes.
This has the following consequences:

1.The Model is now more “generic,” because it no longer implements the logic for registering and unregistering listeners, nor does it need to implement logic to generate events.
2.The View is now responsible for capturing Model state changes.
3.The Controller now notifies the View of state changes to the Model.
4.The Controller must manipulate the Model before notifying the View.