The WCM usage class can be used wherever we can use sling models. Which one should be preferred and why?

If you are given the opportunity to use Sling Models or the WCM usage class, which one is preferable when and why?

Is one of them more efficient in terms of performance?

Thanks at Advance

+6
source share
1 answer

Sling models save you a lot of time accessing simple objects as the current page / resource, introduce some properties or services, adapt to the request for a resource or sling http to your model. Of course, when using a simple API, your code will run a little faster, because you only initialize the objects that you really need, but you must do it all "manually." I think this overview view gives a good overview of all the possible implementations you can go with. You can also take a look at the official documentation . Below you can find a brief overview of what you can expect and hopefully simplify your decision (quoted from the official review documentation).

Java Usage Provider

Benefits Objects provided through packages:

  • initialize and execute faster than Sling models for similar code
  • easily extend to other similar object objects
  • easy setup for unit testing

Use-objects supported by resources:

  • initialize and execute faster than Sling models for similar code
  • it is easy to override from inherited components via the overlay search path or using the sling: resourceSuperType property, which allows for more flexibility.
  • business logic for components is next to Sightly scripts where objects are used

Disadvantages Objects provided through packages:

  • lack of flexibility in terms of component overlay

Use-objects supported by resources:

  • cannot distribute other Java objects
  • A Java project may need a different setting that allows it to run a unit of tests, since objects will be deployed as content

Sling Use Provider Models

Benefits

  • handy annotations for data extraction
  • easily extend to other Sling models
  • easy setup for unit testing

disadvantages

  • lack of flexibility in terms of component overlapping, relying on service.ranking configurations

If you ask me, I would always take the framework as a sling or slice model, which makes development easier and faster. In the end, the impact of performance using the structure is not really a problem; it will not be the only third-party structure in the project. But if your project is performance-oriented, perhaps you can do a few tests with all the possibilities and decide if such a structure suits your needs (or just mix both).

+6
source

All Articles