framework

wxwidgets和其他GUI类库比较

Diviner — Thu, 09 Jun 2005 02:17:00 GMT

WxWidgets Compared To Other Toolkits

WxWiki | RecentChanges | Log in/Preferences

wxWidgets compared to other toolkits

Some general notes:

wxWidgets not only works for C++, but also has bindings for python, perl, java, lua, eiffel, C# (.NET), basic, ruby and even javascript (see [Related projects]).
it is one of the most complete GUI toolkits. There are many utility classes.
it is still heavily developed
there is a lot of documentation (though a bit fragmented in places)
free for personal and commercial use
whenever possible, wxWidgets uses the platform SDK. This means that a program compiled on Windows will have the look and feel of a Windows program, and when compiled on a Linux machine, it wil get the look and feel of a Linux program.

There is also a [slashdot thread] about cross-platform gui toolkits. Though it's old and, well, it's slashdot :), there are probably some useful insights there.

wxWidgets compared to Qt

Both Qt (http://www.trolltech.com/) and wxWidgets have many non-GUI-related classes, such as date/time, containers, networking and OpenGL functionality. However, if you are developing commercial applications (non-gpl) in Qt and want to use most of these classes (including the OpenGL widget), you have to pay extra for the "enterprise edition" (http://www.trolltech.com/products/qt/editions.html) on top of the normal commercial version of Qt (the "professional edition").
Qt2 is available under the GPL for open-source applications, and under the QPL for commercial applications. Qt3 for Mac and GNU/Linux is similarly dual-licensed, but there is no free version of Qt3 for Windows. All ports of wxWidgets are distributed under a permissive modified (but explicitly OSI-approved) LGPL.
- Trolltech has announced that Qt4 will be available under the GPL on Windows. See http://www.trolltech.com/newsroom/announcements/00000192.html.
Qt doesn't have true native ports such as wxWidgets ([with the exception of Qt/Mac].) Qt draws its own widgets on each platform instead of using the native widgets, whereas wxWidgets offers true native ports for all the supported platforms. Additionally, an approach similar to Qt's is achieved with wxUniversal (of course it should be noted that on some platforms, Qt _is_ the native GUI library.)
Qt programs are not true C++ programs and require a special pre-compiler, the so-called Meta Object Compiler or moc. wxWidgets programs do not require this kind of preprocessing and are true C++ programs.
Qt is used by several large projects like KDE and the Opera browser (on the other hand, wxWidgets is used by projects like the AOL Communicator)
Qt makes extremely liberal use of virtual functions (QTWidget, the base class of all widgets in Qt had 91 at last count), giving it a more OO design than wxWidgets (which uses a more MFC-like approach using macros). What this means is fewer lines of code in general when using Qt, but faster execution speed when using wxWidgets (although the degree to which this occurs depends on whom you ask).
Qt is used by IBM and Borland Kylix: this should yield more reliability. However, it is rumoured that wxWidgets will be used in the next version of C++BuilderX.
Qt has a full-featured (commercial and royalty dependent) embeddable GUI (Qt/Embedded) based on GNU/Linux with framebuffer, it gives you a very fast time to market. This means that once you have Linux with /dev/fb you are ready to run examples in minutes, with no additional pains. Qt/Embedded has a small footprint compared with X11.
There is an IDE for Qt, Qt Designer (though there are also several IDEs for wxWidgets).
Qt offers reliable commercial support.
There is nothing to stop somebody writing a Qt-based implementation of wxWidgets.

wxWidgets compared to FLTK

FLTK website: http://www.fltk.org/
wxWidgets has a more mature OO design.
FLTK is more light-weight, whereas wxWidgets is more full-featured (wxWidgets supports networking, printing, etc. while FLTK has limited or no support for these things). See xwWidgets Feature List (http://wxwidgets.org/whychoos.htm) vs. FLTK Feature List (http://www.fltk.org/documentation.php/doc-1.1/intro.html#2_2).
FLTK actually has more elaborate, different widget types. Just compare what you can do in FLUID to wxDesigner or DialogEdit. I ported a FLTK app to wxWidgets and had a hard time emulating the buttons. The window class we used gave screen flicker, etc. as the app grew in size, which was the motivation to transform it to wxWidgets.
FLTK's modified LGPL license is more restricting than wxWidgets license, although it does provide exceptions for static linking.

wxWidgets compared to FOX

FOX website: http://www.fox-toolkit.org/
FOX is more light-weight, whereas wxWidgets is more full-featured.
wxWidgets has a more complete API, while FOX focuses mainly on GUI features.
FOX draws its own widgets on each platform, instead of using the native widgets (like Qt), whereas wxWidgets offers true native ports for all the supported platforms. FOX may be faster because of this, but the provided look-and-feel may not be well integrated into the target platform (e.g. the Windows XP theme is not currently available).
FOX lacks printing and I18N support.
Standard Windows dialog boxes are not supported in FOX, but a portable similar feature is available.

wxWidgets compared to Java

Java is a platform while wxWidgets is a GUI API (and can be used with python, perl, C++, java, lua, eiffel, C# , basic, ruby, etc.) so a comparision of the two may not be completely balanced.
Java programs are compiled from bytecode at runtime. This means when a user first starts your program, it will take longer to load and the first few moments using the program will be sluggish. (Java compilers such as GJC are avalible, but do not support all Java features well/at all).
On the other hand, wxWidgets is compiled directly to machine code and gains all the speed advantages that go along with that.
Java bytecode can be decompiled. This is not a problem if your application is open source. However, if having users seeing your source code is a problem, then you may wish to consider other options.
Users of Java based applications must have a JVM installed. In recent years, this has become less of an issue as more computers are being installed with Sun's JVM. However, user's that have an older JVM may suffer from performance/security problems.
Due to the fact that Java's libraries are slow, some Java libraries are being written in C++ using wxWidgets!
An example of the above is wx4j, a wxWidgets implementation for Java. wx4j is a wxWidgets binding for Java which allows Java programmers to keep their Java language but still have the speed of a C++ written program.
In order to be cross-platform, Java generally targets the least common denominator. Features that are only available or relevant on one platform but not others are left out of the Java APIs. Examples include manipulating the Windows taskbar, the Mac OS menu bar, Unix file attributes, etc.
A corollary of the statement above: in a wxWidgets program, you can always write some platform-specific code where necessary, inside of an ifdef that makes it only compile on that one platform. In Java, there's no equivalent of an ifdef, and you have to jump through hoops to access external APIs. Also, wxWidgets emulates certain features that are not avalible on different platforms (such as MDI and tree controls).
Java programs invariably consume more memory than equivalent C++ programs.
While a great idea, "Write once, run anywhere" is still a myth. All JVMs have bugs in them, and it is simply impossible to develop a large Java program on one platform and expect it to work flawlessly on another. Not to say all problems have been eliminated from wxWidgets, but the situation is definately not worse.
wxWidgets is in many ways more complete and more intuitive. Compare wxString with [java.lang.String]. Be sure to compare both the features, and the quality of the documentation.
Some Java advocates claim that the next version of the JVM will fix many speed problems. However, [benchmark tests do not reflect this].
[Benchmarks] (using JVM server 1.4.0) show that Java is still significantly slower than C++. Significant enough to warrent the use of C++ over Java.

wxWidgets compared to SDL

http://www.libsdl.org
SDL (Simple DirectMedia Layer) is a multimedia C library more suited for when you're writing games and such, and want custom-everything and no convenient general-purpose UI elements. It is made of a lot of C structures starting with SDL_.
Under the LGPL with the additional restriction that the source to SDL must be distributed with your application.

wxWidgets compared to Allegro

http://alleg.sourceforge.net
Much like SDL, Allegro is a cross-platform c library (with quite a bit of assembly used in the backend) for programming games.
Almost as old as wxWidgets (circa 1993).
Giftware license (essentially public domain).
Requires gcc and an assembler to build.
Development has been stuck in the same version for years, there are a lack of core developers (original developer is no longer on the team), and there are some internal disputes which may lead to a fork.
Very basic GUI functionality - only supports one window with only bare bones operations supported - you can't move the window, etc.
"Controls" are sort of supported in allegro also through functions with (many) variable-length arguments, and are owner drawn much like QT (but don't look as good by default). They can be customized via a relatively easy API (and there are a few sub libraries that already have somewhat fair-looking versions).
Drawing routines are much faster than wx, and there is a opengl layer (allegrogl - http://allegrogl.sourceforge.net/) that makes drawing with opengl even easier then it is to begin with.
Non-GUI routines (input, etc.) are lower-level and generally faster than wxWidgets' native implementations.
Can be used with wxWidgets without too much trouble - since allegro has some platform specific functions to get the window handle, you can create a wxWidgets window from the window handle and do what you want from that from that point on. While wxWindows uses a wxApp to handle platform-specific main/WinMain stuff, Allegro requres you put END_OF_MAIN() after your main function - getting the two to work together is somewhat of a task, but not a very large one.

wxWidgets compared to GTK+

http://www.gtk.org
GTK+, originally the Gimp toolkit, is a GPL GUI library for Unix systems, written in C. It has been ported to Windows, VMS, and other systems (MacOS?) using the same API.
GTKs Windows support is... miserable, not to be too blunt. It has nothing even remotely resembling native look and feel or behavior, and there are many drawing/flicker problems. If you are satisfied with the look and functionality of GTK on Windows, you probably weren't the target audience for wxWidgets anyway.
Unlike wxWidgets, GTK+ supports C (and there is a C++ wrapper called GTKMM)
The API is quite well developed, and includes safe casting and other things; but C++ has these built in.
It's built on top of glib, a general-purpose library (similar in some ways to the C++ STL -- it provides a few data structures, functions to help memory management, etc).
It looks the same on all platforms, except Windows XP, where it tries (with some success) to emulate Windows' native look and feel. However, it's still very much a Unix library.
Since wxWidgets uses GTK (or GTK2) on Unix, there seems to be little reason to use GTK over wxWidgets in a C++ program.

wxWidgets compared to Kylix

Kylix hasn't been much of a success for Borland/Inprise, so it's doubtful how long it will be continued to be supported.
Kylix is based on Qt, see above :)
Fewer platforms are supported by Kylix
The IDE, being based on no less than 3 toolkits, is rather unprofessional.

wxWidgets compared to Ultimate++

Ultimate++ only supports Windows and Linux, not MacOS
The comparision on http://upp.sourceforge.net/vswx.html isn't really fair. The (very old) wxWidgets sample they took is well-commented and well-structured to show the reader how to design a wxWidgets application. Their implementation is uncommented and doesn't even behave the same. Also, a small example like that doesn't show how the toolkit scales to bigger applications.

wxWidgets compared to Notus

See: http://sourceforge.net/projects/notus
wxWidgets actually exists ;)
notus is likely to make a lot more use of standard library and modern C++ concepts, such as iterators, templates, namespaces, etc (whereas wxWidgets reimplements or works around many of these things in non-standard ways); and it's also likely to follow the design principles of Boost (which you could consider either a good or bad thing), and work well with the rest of the Boost library. Of course, since it doesn't yet exist, whether this is true in practice remains to be seen.

wxWidgets compared to MFC

MFC is only available for free for Windows
- A macintosh version was (is?) available with Visual C++ Crossplatform Edition (~$800 at last check), and also comes with CodeWarrior
- There are also UNIX variants such as MainWin, which are extremely expensive, require runtime licenses, and are reported to have problematic support
While the source for both wxWidgets and MFC is available, EULAs are not a concern with wxWidgets.
MFC has a smaller executable size than wx (generally irrelevant with a decent compiler).
MFC has greater range of good quality commercial components.
Some say event tables (wxWidgets) are 'better' than message maps (MFC).
wx's class hierarchy is more intuitive, while MFC tends to be more consistent among top-level class names.
wx provides a far greater abundance of convenience classes, while MFC provides more windows-specific classes.
.NET isn't an issue - MFC won't be ported to .NET. On the other hand, wx already has .NET wrappers in alpha stage!
MFC has a broader range of components available, especially data-bound controls.
Some things are easier with wxWidgets, such as certain types of windows (always on top, etc.), while other things are easier with MFC, such as detachable toolbars.
Probably the strongest point to use MFC is MSVC, the IDE, itself.
For info on class names and other points, see wxWidgets for MFC programmers

wxWidgets compared to the Mozilla framework

See: http://www.mozilla.org/why/framework.html
JavaScript, XUL and C++ are all needed to program in Mozilla; wxWindows only needs C++.
Programming Mozilla in C++ (XPCOM) is very difficult; C++ in wxWindows is easier.

So, why not use wxWidgets?

No commercial-grade resource editors specifically made for wxWidgets (although some have been built with wxWidgets!).
Lack of commercial GUI components for making nice GUI themes, grids, charts, etc (will usually have to hack the wxWidgets source code itself to get these results).
- This is incorrect - you do not need to edit the wx library source to add new widgets, not even complicated ones. You would need to if you wanted to add theme support.
X11 port is very sub-par compared to other toolkits and very instable. You should use the wxGTK port instead, which builds upon GTK instead of directly onto X11.

the wxWiki is hosted and maintained by Arnout Engelen (raboof on IRC)

spring-4

Diviner — Wed, 08 Jun 2005 00:32:00 GMT

Spring in Action: A Spring Jump Start. Part 1
The GreetingServiceImpl class has a single property: the greeting property. This property is simply a String that holds the text that is the message that will be printed when the sayGreeting() method is called. You may have noticed that the greeting can be set in two different ways: by the constructor or by the property抯 setter method.

What抯 not apparent just yet is who will make the call to either the constructor or the setGreeting() method to set the property. As it turns out, we抮e going to let the Spring container set the greeting property. The Spring configuration file (hello.xml) in listing 1.3 tells the container how to configure the greeting service.

Listing 1.3 Configuring Hello World in Spring

The XML file in listing 1.3 declares an instance of a GreetingServiceImpl in the Spring container and configures its greeting property with a value of 揃uenos Dias!?Let抯 dig into the details of this XML file a bit to understand how it works. At the root of this simple XML file is the element, which is the root element of any Spring configuration file. The element is used to tell the Spring container about a class and how it should be configured. Here, the id attribute is used to name the bean greetingService and the class attribute specifies the bean抯 fully qualified class name.

Within the element, the element is used to set a property, in this case the greeting property. By using , we抮e telling the Spring container to call setGreeting() when setting the property.

The value of the greeting is defined within the element. Here we抳e given the example a Spanish flair by choosing 揃uenos Dias?instead of the traditional 揌ello World.?/p>

The following snippet of code illustrates roughly what the container does when instantiating the greeting service based on the XML definition in listing 1.3:2

GreetingServiceImpl greetingService = new GreetingServiceImpl();
greetingService.setGreeting("Buenos Dias!");
Similarly, we may choose to have Spring set the greeting property through GreetingServiceImpl抯 single argument constructor. For example:

Similarly, we may choose to have Spring set the greeting property through GreetingServiceImpl抯 single argument constructor. For example:

The following code illustrates how the container will instantiate the greeting service when using the element:

GreetingServiceImpl greetingService =
new GreetingServiceImpl(揃uenos Dias?;
The last piece of the puzzle is the class that loads the Spring container and uses it to retrieve the greeting service. Listing 1.4 shows this class.

2 The container actually performs other activities involving the life cycle of the bean. But for illustrative purposes, these two lines are sufficient.

Listing 1.4 The Hello World main class

The BeanFactory class used here is the Spring container. After loading the hello.xml file into the container, the main() method calls the getBean() method on the BeanFactory to retrieve a reference to the greeting service. With this reference in hand, it finally calls the sayGreeting() method. When we run the Hello application, it prints (not surprisingly)

Buenos Dias!

This is about as simple a Spring-enabled application as we can come up with. But it does illustrate the basics of configuring and using a class in Spring. Unfortunately, it is perhaps too simple because it only illustrates how to configure a bean by injecting a String value into a property. The real power of Spring lies in how beans can be injected into other beans using IoC.

Next week, we begin with Understanding inversion of control.

Spring in Action: A Spring Jump Start is written by Craig Walls and Ryan Breidenbach and reproduced from "Spring in Action" by permission of Manning Publications Co. ISBN 1932394354, copyright 2005. All rights reserved. See http://www.manning.com for more information.

spring -3

Diviner — Wed, 08 Jun 2005 00:30:00 GMT

Spring in Action: A Spring Jump Start. Part 1

The core container

Spring抯 core container provides the fundamental functionality of the Spring framework. In this module you抣l find Spring抯 BeanFactory, the heart of any Spring-based application. A BeanFactory is an implementation of the factory pattern that applies IoC to separate your application抯 configuration and dependency specifications from the actual application code.

We抣l be discussing the core module (the center of any Spring application) throughout this book, starting in chapter 2, when we cover bean wiring using IoC.

Application context module

The core module抯 BeanFactory makes Spring a container, but the context module is what makes it a framework. This module extends the concept of BeanFactory, adding support for internationalization (I18N) messages, application life cycle events, and validation.

In addition, this module supplies many enterprise services such as e-mail, JNDI access, EJB integration, remoting, and scheduling. Also included is support for integration with templating frameworks such as Velocity and FreeMarker.

Spring抯 AOP module

Spring provides rich support for aspect-oriented programming in its AOP module. This module serves as the basis for developing your own aspects for your Spring-enabled application.

To ensure interoperability between Spring and other AOP frameworks, much of Spring抯 AOP support is based on the API defined by the AOP Alliance. The AOP Alliance is an open-source project whose goal is to promote adoption of AOP and interoperability among different AOP implementations by defining a common set of interfaces and components. You can find out more about the AOP Alliance by visiting their website at http://aopalliance.sourceforge.net. The Spring AOP module also introduces metadata programming to Spring. Using Spring抯 metadata support, you are able to add annotations to your source code that instruct Spring on where and how to apply aspects.

JDBC abstraction and the DAO module

Working with JDBC often results in a lot of boilerplate code that gets a connection, creates a statement, processes a result set, and then closes the connection. Spring抯 JDBC and Data Access Objects (DAO) module abstracts away the boilerplate code so that you can keep your database code clean and simple, and prevents problems that result from a failure to close database resources. This module also builds a layer of meaningful exceptions on top of the error messages given by several database servers. No more trying to decipher cryptic and proprietary SQL error messages!

In addition, this module uses Spring抯 AOP module to provide transaction management services for objects in a Spring application.

Object/relational mapping integration module

For those who prefer using an object/relational mapping (ORM) tool over straight JDBC, Spring provides the ORM module. Spring doesn抰 attempt to implement its own ORM solution, but does provide hooks into several popular ORM frameworks, including Hibernate, JDO, and iBATIS SQL Maps. Spring抯 transaction management supports each of these ORM frameworks as well as JDBC.

Spring抯 web module

The web context module builds on the application context module, providing a context that is appropriate for web-based applications. In addition, this module contains support for several web-oriented tasks such as transparently handling multipart requests for file uploads and programmatic binding of request parameters to your business objects. It also cotains integration support with Jakarta Struts.

The Spring MVC framework

Spring comes with a full-featured Model/View/Controller (MVC) framework for building web applications. Although Spring can easily be integrated with other MVC frameworks, such as Struts, Spring抯 MVC framework uses IoC to provide for a clean separation of controller logic from business objects. It also allows you to declaratively bind request parameters to your business objects, What抯 more, Spring抯 MVC framework can take advantage of any of Spring抯 other services, such as I18N messaging and validation.

Now that you know what Spring is all about, let抯 jump right into writing Spring applications, starting with the simplest possible example that we could come up with.

1.3 Spring jump start

In the grand tradition of programming books, we抣l start by showing you how Spring works with the proverbial 揌ello World?example. Unlike the original Hello World program, however, our example will be modified a bit to demonstrate the basics of Spring.

NOTE To find out how to download Spring and plug it into your project抯 build routine, refer to appendix A.

Spring-enabled applications are like any Java application. They are made up of several classes, each performing a specific purpose within the application. What makes Spring-enabled applications different, however, is how these classes are configured and introduced to each other. Typically, a Spring application has an XML file that describes how to configure the classes, known as the Spring configuration file.

The first class that our Springified Hello World example needs is a service class whose purpose is to print the infamous greeting. Listing 1.1 shows GreetingService.java, an interface that defines the contract for our service class.

Listing 1.1 The GreetingService interface separates the service抯 implementation from its interface.

package com.springinaction.chapter01.hello;

public interface GreetingService { public void sayGreeting(); }

GreetingServiceImpl.java (listing 1.2) implements the GreetingService interface. Although it抯 not necessary to hide the implementation behind an interface, it抯 highly recommended as a way to separate the implementation from its contract.

Listing 1.2 GreetingServiceImpl.java: Responsible for printing the greeting

home / programming / spring

Spring -2

Diviner — Wed, 08 Jun 2005 00:29:00 GMT

Spring in Action: A Spring Jump Start. Part 1

Good design is more important than the underlying technology

As a developer, you should always be seeking the best design for your application, regardless of the implementation you choose. Sometimes the complexity of EJB is warranted because of the requirements of the application. Often, this is not the case. Many applications require few, if any, of the services provided by EJB yet are still implemented using this technology for technology抯 sake. If an application does not require distribution or declarative transaction support, it is unlikely that EJB is the best technology candidate. Yet many Java developers feel compelled to use EJB for every Java enterprise application.

The idea behind Spring is that you can keep your code as simple as it needs to be. If what you want are some plain-vanilla Java objects to perform some services supported by transparent transactions, you抳e got it. And you don抰 need an EJB container, and you don抰 have to implement special interfaces. You just have to write your code.

JavaBeans loosely coupled through interfaces is a good model

If you are relying on EJBs to provide your application services, your components do not just depend on the EJB business interface. They are also responsible for retrieving these EJB objects from a directory, which entails a Java Naming and Directory Interface (JNDI) lookup and communicating with the bean抯 EJBHome interface. This is not creating a decoupled application. This is tightly coupling your application to a specific implementation, namely EJB.

With Spring, your beans depend on collaborators through interfaces. Since there are no implementation-specific dependencies, Spring applications are very decoupled, testable, and easier to maintain. And because the Spring container is responsible for resolving the dependencies, the active service lookup that is involved in EJB is now out of the picture and the cost of programming to interfaces is minimized. All you need to do is create classes that communicate with each other through interfaces, and Spring takes care of the rest.

Code should be easy to test

Testing J2EE applications can be difficult. If you are testing EJBs within a container, you have to start up a container to execute even the most trivial of test cases. Since starting and stopping a container is expensive, developers may be tempted to skip testing all of their components. Avoiding tests because of the rigidness of a framework is not a good excuse.

Because you develop Spring applications with JavaBeans, testing is cheap. There is no J2EE container to be started since you will be testing a POJO. And since Spring makes coding to interfaces easy, your objects will be loosely coupled, making testing even easier. A thorough battery of tests should be present in all of your applications; Spring will help you accomplish this.

1.2 What is Spring?

Spring is an open-source framework, created by Rod Johnson and described in his book Expert One-on-One: J2EE Design and Development.1 It was created to address the complexity of enterprise application development. Spring makes it possible to use plain-vanilla JavaBeans to achieve things that were previously only possible with EJBs. However, Spring抯 usefulness isn抰 limited to server-side development. Any Java application can benefit from Spring in terms of simplicity, testability, and loose coupling.

NOTE To avoid ambiguity, we抣l use the term 揈JB?when referring to Enterprise JavaBeans. When referring to the original JavaBean, we抣l call it 揓avaBean,?or 揵ean?for short. Some other terms we may throw around are 揚OJO?(which stands for 損lain old Java object? or 揚OJI?(which means 損lain old Java interface?.

Put simply, Spring is a lightweight inversion of control and aspect-oriented container framework. Okay, that抯 not so simple a description. But it does summarize what Spring does. To make more sense of Spring, let抯 break this description down:

Lightweight - Spring is lightweight in terms of both size and overhead. The entire Spring framework can be distributed in a single JAR file that weighs in at just over 1 MB. And the processing overhead required by Spring is negligible. What's more, Spring is nonintrusive: objects in a Spring-enabled application typically have no dependencies on Springspecific classes.
Inversion of control - Spring promotes loose coupling through a technique known as inversion of control (IoC). When IoC is applied, objects are passively given their dependencies instead of creating or looking for dependent objects for themselves. You can think of IoC as JNDI in reverse - instead of an object looking up dependencies from a container, the container gives the dependencies to the object at instantiation without waiting to be asked.
Aspect-oriented - Spring comes with rich support for aspect-oriented programming that enables cohesive development by separating application business logic from system services (such as auditing and transaction management). Application objects do what they're supposed to do - perform business logic - and nothing more. They are not responsible for (or even aware of) other system concerns, such as logging or transactional support.
Container - Spring is a container in the sense that it contains and manages the life cycle and configuration of application objects. You can configure how your each of your beans should be created - either create one single instance of your bean or produce a new instance every time one is needed based on a configurable prototype - and how they should be associated with each other. Spring should not, however, be confused with traditionally heavyweight EJB containers, which are often large and cumbersome to work with.
Framework - Spring makes it possible to configure and compose complex applications from simpler components. In Spring, application objects are composed declaratively, typically in an XML file. Spring also provides much infrastructure functionality (transaction management, persistence framework integration, etc.), leaving the development of application logic to you.

1 In this book, Spring was originally called "interface21."

All of these attributes of Spring enable you to write code that is cleaner, more manageable, and easier to test. They also set the stage for a variety of subframeworks within the greater Spring framework.

1.2.1 Spring modules

The Spring framework is made up of seven well-defined modules (figure 1.1). When taken as a whole, these modules give you everything you need to develop enterprise-ready applications. But you do not have to base your application fully on the Spring framework. You are free to pick and choose the modules that suit your application and ignore the rest.

As you can see, all of Spring抯 modules are built on top of the core container. The container defines how beans are created, configured, and managed梞ore of the nuts-and-bolts of Spring. You will implicitly use these classes when you configure your application. But as a developer, you will most likely be interested in the other modules that leverage the services provided by the container. These modules will provide the frameworks with which you will build your application抯 services, such as AOP and persistence.

Figure 1.1 The Spring framework is composed of several well-defined modules.

Sping -1

Diviner — Wed, 08 Jun 2005 00:28:00 GMT

Spring in Action: A Spring Jump Start. Part 1

Written by Craig Walls and Ryan Breidenbach and reproduced from "Spring in Action" by permission of Manning Publications Co. ISBN 1932394354, copyright 2005. All rights reserved. See http://www.manning.com for more information.

This chapter covers

Creating simpler J2EE applications using Spring
Decoupling components with inversion of control
Managing cross-cutting concerns with aspectoriented programming
Comparing the features of Spring and EJB

It all started with a bean.

In 1996 the Java programming language was still a young, exciting, up-and coming platform. Many developers flocked to the language because they had seen how to create rich and dynamic web applications using applets. But they soon learned that there was more to this strange new language than animated juggling cartoon characters. Unlike any language before it, Java made it possible to write complex applications made up of discrete parts. They came for the applets, but they stayed for the components.

It was in December of that year that Sun Microsystems published the Java- Beans 1.00-A specification. JavaBeans defined a software component model for Java. This specification defined a set of coding policies that enabled simple Java objects to be reusable and easily composed into more complex applications. Although JavaBeans were intended as a general-purpose means of defining reusable application components, they have been primarily used as a model for building user interface widgets. They seemed too simple to be capable of any 搑eal? work. Enterprise developers wanted more.

Sophisticated applications often require services such as transaction support, security, and distributed computing梥ervices not directly provided by the Java- Beans specification. Therefore, in March 1998, Sun published the 1.0 version of the Enterprise JavaBeans (EJB) specification. This specification extended the notion of Java components to the server side, providing the much-needed enterprise services, but failed to continue the simplicity of the original JavaBeans specification. In fact, except in name, EJB bears very little resemblance to the original JavaBeans specification.

Despite the fact that many successful applications have been built based on EJB, EJB never really achieved its intended purpose: to simplify enterprise application development. Every version of the EJB specification contains the following statement: 揈nterprise JavaBeans will make it easy to write applications.?It is true that EJB抯 declarative programming model simplifies many infrastructural aspects of development, such as transactions and security. But EJBs are complicated in a different way by mandating deployment descriptors and plumbing code (home and remote/local interfaces). Over time many developers became disenchanted with EJB. As a result, its popularity has started to wane in recent years, leaving many developers looking for an easier way.

Now Java component development is coming full circle. New programming techniques, including aspect-oriented programming (AOP) and inversion of control (IoC), are giving JavaBeans much of the power of EJB. These techniques furnish JavaBeans with a declarative programming model reminiscent of EJB, but without all of EJB抯 complexity. No longer must you resort to writing an unwieldy EJB component when a simple JavaBean will suffice.

And that抯 where Spring steps into the picture.

1.1 Why Spring?

If you are reading this book, you probably want to know why Spring would be good for you. After all, the Java landscape is full of frameworks. What makes Spring any different? To put it simply, Spring makes developing enterprise applications easier. We don抰 expect that to convince you at face value, so first let抯 take a look at life without Spring.

1.1.1 A day in the life of a J2EE developer

Alex is a Java developer who has just started on his first enterprise application. Like many Java 2 Enterprise Edition (J2EE) applications, it is a web application that serves many users and accesses an enterprise database. In this case, it is a customer management application that will be used by other employees at his company. Eager to get to work, Alex fires up his favorite integrated development environment (IDE) and starts to crank out his first component, the CustomerManager component. In the EJB world, to develop this component Alex actually has to write several classes梩he home interface, the local interface, and the bean itself. In addition, he has to create a deployment descriptor for this bean.

Seeing that creating each of these files for every bean seems like a lot of effort, Alex incorporates XDoclet into his project. XDoclet is a code generation tool that can generate all of the necessary EJB files from a single source file. Although this adds another step to Alex抯 development cycle, his coding life is now much simpler. With XDoclet now handling a lot of the grunt work for him, Alex turns his attention to his real problem梬hat exactly should the CustomerManager component do? He jumps in with its first method, getPreferredCustomer(). There are several business rules that define exactly what a preferred customer is, and Alex dutifully codes them into his CustomerManager bean.

Wanting to confirm that his logic is correct, Alex now wants to write some tests to validate his code. But then it occurs to him: the code he is testing will be running within the EJB container. Therefore, his tests need to execute within the container as well. To easily accomplish this, he concocts a servlet that will be responsible for executing these tests. Since all J2EE containers support servlets, this will allow him to execute his tests in the same container as his EJB.

Problem solved!

So Alex fires up his J2EE container and runs his tests. His tests fail. Alex sees his coding error, fixes it, and runs the tests again. His tests fail again. He sees another error and fixes it. He fires up the container and runs the tests again. As Alex is going through this cycle, he notices something. The fact that he has to start the J2EE container for each batch of testing really slows down his development cycle. The development cycle should go code, test, code, test. This pattern has now been replaced with code, wait, test, code, wait, test, code, wait, get increasingly frustrated!

While waiting for the container to start during another test run, Alex thinks, "Why am I using EJB in the first place?" The answer, of course, is because of the services it provides. But Alex isn't using entity beans, so he is not using persistence services. Alex is also not using the remoting or security services. In fact, the only EJB service Alex is going to use is transaction management. This leads Alex to another question: "Is there an easier way?"

1.1.2 Spring's pledge

The above story was a dramatization based on the current state of J2EE - specifically EJB. In its current state, EJB is complicated. It isn't complicated just to be complicated. It is complicated because EJBs were created to solve complicated things, such as distributed objects and remote transactions.

Unfortunately, a good number of enterprise projects do not have this level of complexity but still take on EJB's burden of multiple Java files and deployment descriptors and heavyweight containers. With EJB, application complexity is high, regardless of the complexity of the problem being solved - even simple applications are unduly complex. With Spring, the complexity of your application is proportional to the complexity of the problem being solved.

However, Spring recognizes that EJB does offer developers valuable services. So Spring strives to deliver these same services while simplifying the programming model. In doing so, it adopts a simple philosophy: J2EE should be easy to use. In keeping with this philosophy, Spring was designed with the following beliefs:

Good design is more important than the underlying technology.
JavaBeans loosely coupled through interfaces is a good model.
Code should be easy to test.

Okay. So how does Spring help you apply this philosophy to your applications?