ABAP_to_the_Future

10
ALV SALV Reporting Framework
good-looking fashion; it is not concerned with where the data comes from in the
first place or how any user input is handled.
Model-View-Controller
In almost any book or article on object-oriented programming, the MVC pattern is mentioned
almost at once. Head-First Design Patterns (see the “Recommended Reading”
box at the end of this chapter) describes this as the Elvis Presley of design patterns.
Although we go into a bit more detail on MVC in Chapter 12 of the book, here’s a brief
analogy to help you understand the gist.
Imagine that you are making a film. The model is the story writer: the writer has created
the story and nothing could happen without it, but at the time of writing the writer
could not be sure this would be realized as a movie; it might have ended up as a play or
even a book. The writer didn’t actually care about this when writing the story.
The view comprises the actors, make-up artists, special effects people, and so on, who
are doing their best to bring the story to life. They don’t actually care who wrote the
story in the first place.
The controller is the movie company who takes the story from the model (writer) and
gives it to the assorted view people (actors, etc.). The controller might suddenly decide
this is better as a radio play, sack all the movie-based view people, and replace them
with radio-based view people, and the model (writer and story) would still be the same.
Likewise, the controller might suddenly decide the writer is no good after all and
replace the story with a similar one with the same sort of plot submitted the week
before by another writer; the actors could stay the same and just learn some new lines.
The MVC design pattern tries to replicate this sort of real-world situation in software by
having three different parts of the program all dealing with one aspect: business logic
(model), presentation to the user (view), and interaction between the two (controller).
In this section, I’ll talk about creating a SALV-specific (concrete) class that contains
SALV-specific attributes (Section 10.1.1) and writing a small example program
to call that class (Section 10.1.2). These steps will prepare you to design the
actual report interface, which is the focus of this chapter and the subject of Section
10.2.
10.1.1 Defining a SALV-Specific (Concrete) Class
In Section 10.2 you will define an interface that is framework-agnostic. Interfaces
do not contain any code, so you need to define a concrete class that implements
the abstract interface—in this example, a SALV-specific class.
410