Impact of Spring on Interface-Based Design
Spring has a huge impact on applications that are designed using interfaces. Because Spring takes care
of wiring all the components together, you no longer have to worry about creating Factory classes that
consider every possible situation.
On the surface, when you are building interface-based applications, the biggest benefit from Spring
is the reduction in glue code that you have to write. This benefit is further enhanced by the excellent
out-of-the-box support for external configuration of component dependencies. However, the biggest
benefit comes from Spring's use of Dependency Injection. Because Spring removes the responsibility
for dependency location from the components themselves and simply asks that components allow it to
provide them with the dependencies, Spring is able to solve the last two of the three problems discussed
previously.
Dependency Injection means that Spring can provide any instance of any implementation class to
any instance of any application component without requiring any special coding in the application
component whatsoever. This is coupled with the fact that Spring can freely manage the life cycle of any
instance of any dependency that it is managing for an application component.
Basically, this means that Spring has all the features that we need to design interface-based
applications, and we don't have to worry about how we are going to glue the components together
during implementation.
Building a Domain Object Model
A Domain Object Model (DOM) is a set of classes that model concepts from the problem domain. Again,
the DOM is a big topic, and we will just cover the main concepts of the DOM in this section. For a more
complete description of the DOM Pattern, we recommend you read Patterns of Enterprise Application
Architecture by Martin Fowler (Addison-Wesley, 2002) or Domain-Driven Design: Tackling Complexity in
the Heart of Software by Eric Evans (Addison-Wesley, 2003). Although we do not go into great detail on
this pattern, we do show you why we chose to create a DOM for the SpringBlog application and how we
built our DOM.
Spring and the Domain Object Model
Given that this is a topic on Spring, you might find it strange that we dedicate considerable space to a
topic that is not directly related to Spring in any way. Of the applications that we have built using
Spring, the only objects that are consistently not managed by Spring are domain objects. (Even though
in Spring it's possible to have Spring manage domain objects by applying the @Component annotation to
the classes and assigning them with prototype scope, most of the time we will choose to manage
domain objects within the application.) The reason for this is that, practically, Spring does not need to
be involved with domain objects. Generally, you create many instances of your domain objects using
the new() operator and perform processing either in the service or data access layer. Although Spring
also supports the injection of new instance of domain objects every time it was requested (by using the
bean scope prototype), generally developers will not adopt this approach since typically domain
objects do not take advantage of Dependency Injection, because they generally have few dependencies
outside of the DOM itself, and they don't require much configuration.
You might well be wondering, then, why so much attention is paid to the DOM. The answer is
simple. The DOM is the most critical area that affects so many other parts of the application, parts that
are managed by Spring, that getting it right is very important to getting your whole application right.
Search WWH :
