Gloop design guidelines

In order to help and encourage the creation of clean and efficient Gloop code, the recommended guidelines below should be followed.

Naming conventions, keywords you should not use, and more!

The appendix contains a page discussing rules that also should be followed when it comes to naming and organizing Martini packages, Martini endpoints, services, models and beans, and other components used for building applications.

Exception handling

By default, handling of exceptions is optional in Gloop. If a service throws an exception and is not caught, it will be propagated outside of the service. It is often preferable to handle the exception and provide a remedy to the error or a useful message explaining why the error occurred. This is especially true when a service is exposed via a Gloop REST or SOAP API.

Separation of concerns

In most cases, a service should only have one function or purpose. Consider services used to delete entities; a bad example would be one that is used to delete multiple types of entities as shown in the following code:

// Usage: com.company.Delete( type, entity )
com.company.Delete( 'account', account )
com.company.Delete( 'contact', contact )

A better example would be to break down the Delete service's functionality into multiple services, like so:

com.company.account.DeleteAccount( account )
com.company.contact.DeleteContact( contact )