package com.abien.messageme.presentation;
//...other imports
import org.junit.Before;
import org.junit.Test;
import static org.mockito.Mockito.*;
public class IndexPresenter Test {
private IndexPresenter cut;
@Before
public void initialize(){
this.cut = new IndexPresenter();
}
@Test
public void save() {
this.cut.boundary = mock( Messaging.class);
this.cut.indexView = mock( IndexView.class);
Message expected = new Message("duke");
when( this.cut.indexView.getMessage()).thenReturn(expected);
cut.save();
verify( this.cut.boundary,times( 1)).store(expected);
}
}
In JSF 2 the values of the component can
be directly bound to a corresponding class,
whereas in Swing they are usually stored in
the view itself or in the model.
For the implementation of data-driven
use cases such as CRUD, the Supervising
Controller is a better choice than the
Passive View. In the Supervising Controller
pattern, a single backing bean (IndexView)
is responsible for managing both the presentation logic and the state of the view. In
more-sophisticated use cases, the Passive
View variant may be more applicable. In the
Passive View pattern, the backing bean is
split into the view and presentation logic,
and the presentation logic is extracted from
the IndexView to the IndexPresenter.
CDI is best suited for the implementation of the presentation layer. Because of
the built-in cross-cutting concerns (such as
transactions, concurrency, asynchronous
execution, monitoring, and throttling), the
boundary of the business logic is realized as
an EJB. The business component can be realized either as EJBs or CDIs. In general, you
can start with CDIs and, over time, replace
managed beans in special cases with EJBs.
The CDI-EJB-CDI (CEC) pattern is the simplest
and most pragmatic choice for Java EE 6.
collisions, developers often had to resort to
well-defined naming conventions such as
XyzLocal/XyzRemote and XyzBean. In Java
EE 6, interfaces for EJBs and CDIs are now
optional. Public EJB or CDI methods can
now expose a “no interface” view, with no
loss of functionality.
This new functionality makes interfaces
meaningful again. As opposed to the obligatory, nondescript use of interfaces with earlier
releases, interfaces in Java EE 6 can be used
for the implementation of the Strategy
pattern; implementation of a public API; or
strict separation of modules, which makes the
code more expressive. An interface can also
signal the “protected variations” of a system,
and direct dependencies between classes can
be used for code that is less likely to vary.
You can safely start without any interfaces
and introduce them later as the need arises.
This approach is fundamentally different
from that in Java EE 5. Compared to Java 2
Platform, Enterprise Edition (J2EE) from
2003, Java EE 6 code is simpler, in terms of
the elimination of several layers, indirec-
tions, and abstractions. Unlike J2EE, Java
EE 6 consists of annotated classes without
any dependencies on the platform. This
approach eliminates the need to separate
business logic from the infrastructure and
makes the majority of J2EE patterns and best
practices superfluous. In Java EE 6, simple
cases can be solved with two layers: presen-
tation and business logic. The EntityManager
is already a good enough abstraction of the
underlying persistence, so there is no need
for additional indirections.
Adam Bien ( blog.adam-bien.com) is a Java
Champion, consultant, lecturer, speaker,
software architect, developer, and author of
Java books and articles including Real World
Java EE Patterns: Rethinking Best Practices
( lulu.com, 2009). He was Oracle Magazine’s
2010 Java Developer of the Year.
NEXT STEPS
MAKING INTERFACES USEFUL
EJB 3.0 (in Java EE 5) required separate
interfaces for bean classes. To avoid naming
READ more about
CDI
bit.ly/9JKUdp
Protected Variations pattern
bit.ly/cGueFJ
Supervising Controller and Passive View
patterns
martinfowler.com/eaaDev
