The primary concern is to implement
all requirements from the problem domain in one place.
If from the problem domain some items
has to be mandatory the definition of this is done within the model class.
In case of a change of requirements (which we all know happens) there is
only one place where the code must be changed. Which leads directly to
higher maintainability.
This advantage will become quit clear
if the application will be used both from the Notes client and the web
browser. Although you could use one form for both you normally use two
forms for better results. Instead of trying to keep the input validation
on both forms in sync the forms access the model class via their controller
classes.
There has to be different controller
classes for the Notes client and for the web browser because both have
different events to be handled. In a Notes client the QuerySave event could
be used to trigger the input validation. In a web browser there is the
OnSubmit event in JavaScript which is similar to the QuerySave event. But
it is not possible to use the OnSubmit event directly with LotusScript.
Another important point is that the use could disable JavaScript in his
web browser. So there has to be another input validation in the back end.
Without a doubt the requirements from
the problem domain has also to be fulfilled if the document is changed
from a scheduled Agent. In that case the agent uses the model class directly.
There is no need for a controller class because there are no events to
react on.
If we want to use the model class from
every context no Notes UI classes as NotesUIWorkspace or NotesUIDocument
must be used. Otherwise a scheduled agent or a WebQuerySave agent won't
run. But the ban of Notes UI classes is not a problem because the controller
classes take over all tasks where these classes would be handy to use.
In my next blog entry base classes for
model and controller are introduced which could be derived for concrete
use.
