Building a multilayer XPage Architecture
09. Dec, 2010 
9 Comments
Hi,
as promised, i will do a more technical screencast now. I will show you, how to set up an XPage application, that is seperated into different layers, where each layer has its own responsibility. Why should you do this?
It’s extremely easy to switch datasources, you could even switch between datasources (Notes, SQL, Webservice,…) based on the current time, current user,… . You will do this in a central Java Class, using the Factory-Pattern. No Changes in XPages,… are necessary.
Calculating the status of Objects (overdue, approved,…), formatting of Names,… will be done in a central place, if you change the logic, no changes to the XPages (UI) will be necessary.
Accessing the data in your XPage will be more user friendly, because you can write object.getStatus() etc… to access information.
You can use all the great Java editing features of eclipse and ~ 30% of your application can be developed by a pure Java programmer, no notes knowledge necessary.
And I’m sure there are loads of more advantages, otherwise these multilayer architectures wouldn’t be the de-facto standard.
To better understand the architecture, you can download a stripped down version of the application, containing only the display of the users e-mails. 
If you are really interested in the subject and willing to learn Java, you should search the internet for the following topics: “Interface driven design”, “Data Access Objects”, “Factory Pattern” and maybe “Data Transfer Object”
Screencast (if you have problems viewing it, there is a link to download the .mp4 file after registering at vimeo
*Update: the last 30 seconds of the sceencast are messed up, but you don’t really miss anything except a java interface explanation – there are better ones online, and i don’t want to recreate it now – its 00:52 am and i finally need some sleep 
Author
Mario,
Thanks an excellent articile. Been moving towards this model for xPages – this helps with better organising things.
Keep up the great work!!!
Mario, very nice. I like esp. the usage of Collections as data source.
Would be great if you could contribute this sample to OpenNTF.
The Demo NSF has local encryption enabled. Could you remove it?
@Ferry: Thanks for the information, i changed the file, it should work now.
@Niklas: I will do so if i find some time, maybe next week
@Niklas: The Openntf project: http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=XPage%20multi-layer%20architecture%20demo
Mario,
I am using JSF managed beans for my current project. This was a great little presentation, it clarified to me that I am missing 1 layer (the Data access Layer, I’m going straight from Model to Data), at this stage in project, I can correct my mistake. Thanks!
Hi Nick,
the Data Access Layer has several Advantages:
If you change the Datasource from Notes to SQL/… you have a central place to do so, you don’t have to overwrite existing code – you create additional classes, but must importantly: you don’t have to change you logic code (model layer), so you can’t break the application.
Another point are design principles, please google for “Single Responsibility Principle”. There is no reason, for your employee/… bean to know, how to save/search himself in the database. Thats the responsibility of the data access layer.
Hi Mario, It would be great if you could share the entire project that you have. I wanted to know what dto-es are and how you are using them in conjunction with the DAO?
Hi Dan,
i can’t share the Project because I’m not working anymore for my former employer. If you use DTOs or your business models directly, depends on the project and your design decision. Just do a search, there has been written enough about DTOs in the Java environment.
best regards
Mario *doing pure j2ee development from now on*