The Model-View-Controller (MVC) pattern has its origin in Smalltalk. It
describes a principle for developing graphical user interfaces. The core
idea is the separation of the domain classes from its presentation.
The pattern has three components
- Model - the domain class
- View - presentation
- Controller - user interaction
The advantage of this pattern is that
the domain class has no knowledge about their presentation. By that it's
possible to change the presentation without any changes at the domain class.
For multiple presentation of the same domain class it makes life a lot
easier. The reason for the separation of the presentation (View) from the
user interaction (controller) is also flexibility. One controller could
be used for different presentations.
But what about Lotus Notes? In my last
blog entry OOP in LotusScript
- Why should you care? I showed why object-oriented programming
in LotusScript is a good thing. So this one is more about how to integrate
custom classes writen in LotusScript.
The primary design element for presentation
and editing of information in Lotus Notes is the form. So the integration
has to start by using the LotusScript custom class from within the form.
Frankly I don't like too much code in the form. If things get complicated
there are to many places where code could be. All relevant code should
be in one script library. In the form there should only be calls to the
script library.
So lets have a look at the model-view-controller
pattern for Lotus Notes. The domain class is the model. The presentation
is done using a Notes form, which has the role of the view part (Not Notesview
but more on a conceptual level). For interaction between these both components
there is a controller class.
Why do we need a controller class? Why
not interact from the domain class directly with the form? Hypothetical
we could do it, but we would lose flexibility. Specially if we use UI classes
or methods in our domain class we could no longer use it for a scheduled
agent running on the server. The controller class takes care about this
problem by giving us a way to use all UI methods we need and also be able
to use our domain class in every context we want to.
I will discuss the separation of back
end and front end and the use of the controller class in my next blog entry:
OOP in LS: Use of Controller Classes / Separation
of Front end and Back end