As an archi­tect with Adobe Con­sult­ing Ser­vices, I have the oppor­tu­ni­ty to see a wide vari­ety of projects. Inte­grat­ing domain mod­el class­es into AEM/CQ projects remains one of the repeat­ed strug­gles I’ve seen over the past few years. In many cas­es, such class­es are not nec­es­sary – the Sling Resource and JCR APIs pro­vide a suf­fi­cient set of domain class­es. How­ev­er, many projects, espe­cial­ly those with suf­fi­cient com­plex­i­ty, are well served by a rich domain mod­el.

Back in Decem­ber, I intro­duced a new sub-project with­in the Apache Sling project to deal with this prob­lem. Devel­oped first under the work­ing name of YAMF (for Yet Anoth­er Mod­el Fac­to­ry), and then renamed to the more for­mal Sling Mod­els, this mod­ule allows you to use a mix of stan­dard and cus­tom anno­ta­tions to eas­i­ly adapt stan­dard Sling objects—such as Resource and SlingHttpServle­tRe­quest objects—into domain class­es with­out any boil­er­plate code. You write your class­es or inter­faces, anno­tate them, and the nec­es­sary plumb­ing is cre­at­ed dynam­i­cal­ly for you.

Sling Mod­els allows you to write read­able, high­ly testable code, and elim­i­nates the need for cre­at­ing mock Resource or Node objects. Although the pri­ma­ry use case for Sling Mod­els is per­form­ing map­ping Sling Resource objects, as a frame­work it is not lim­it­ed to a par­tic­u­lar type of source object. Resource and SlingHttpServle­tRe­quest are sup­port­ed using the exist­ing injec­tors and new injec­tors can be cre­at­ed for addi­tion­al types as nec­es­sary.

Click here to read more about Sling Mod­els. In addi­tion, I’ll be pre­sent­ing Sling Mod­els at AEM Hub 2014, April 9–10 in Lon­don, pro­vid­ing a deep dive into its usage and exten­si­bil­i­ty.