AEM Sling Models - Why Bother? | AEM Community Bl... - Adobe Experience League Community

AEM Sling Models - Why Bother? by Brett Birschbach,

Abstract

A debate sometimes arises among developers creating components on Adobe Experience Manager (AEM) as to whether or not to create sling models for all components. The discussion often focuses on simple components that merely read authored properties from the JCR and display them on the page since HTL can readily do this without the aid of sling models.

Some common perceptions are that sling models for these components represent unnecessary complexity (arguable in some aspects, but not true in the big picture) and that development is simpler and quicker, especially for front-end developers, by omitting sling models (also not true).

Sling models are recommended for all AEM components, complex or simple, and building them via standard practices saves development time in both initial implementation and ongoing maintenance.

Adobe Best Practices
Coding components with sling models is the recommended AEM best practice from Adobe, as demonstrated by the implementation patterns in WCM Core Components. At face value, this reason can seem arbitrary. However, there are some very good reasons why we should follow AEM best practices in most cases.

Content Service (JSON) Support
Sling models coded according to best practices ensure that all content within a website can be accessed as JSON web services (via the .model.json URL extension). Content as a service is a feature that AEM fundamentally supports out of the box, and a feature that Adobe ensures customers are aware of.

Image/Link/Other Processing
Accessing properties directly in HTL leaving only complex values to sling models may seem convenient in some cases. However, that convenience will almost inevitably lead to shortcuts with hidden deficiencies and maintainability implications.