OOP in LS: Use of Controller Classes / Separation of Front end and Back end

by Bernd,
assono GmbH, Standort Hamburg,

A picture named M2 In my last blog entry OOP in LS: MVC in Lotus Notes I promised to write about the separation of front end and back end and the use of controller classes.

The primary concern is to implement all requirements from the problem domain in one place.
A picture named M3

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.

Technical article Development

Sie haben Fragen zu diesem Artikel? Kontaktieren Sie uns gerne: blog@assono.de

Do you want an individual solution? Contact us

More interesting entries

Any questions? Contact us.

If you want to know more about our offers, you can contact us at any time. There are several ways to contact us for a non-binding first consultation.

We don’t sell your data. 100% guaranteed. See: Privacy Policy
assono GmbH

Location Kiel (headquarters)
assono GmbH
Lise-Meitner-Straße 1–7
24223 Schwentinental

Location Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Phone numbers:
Human resources department: +49 4307 900 407
Marketing department: +49 4307 900 402

E-Mail adresses: