Application classes

Page logic handles one request. Application classes handle the application's behaviour in a reusable way.

That distinction is worth keeping clear early. If a page needs to load a user, validate some input, save a record, or calculate a result, the page file should usually pass that work into an application class rather than own the whole process itself.

Common types of classes

Common classes in a WebEngine application include:

• services that coordinate useful work
• use-case classes that perform one application action
• domain entities that represent application data with behaviour
• repositories or data access helpers
• value objects for small typed concepts

Not every project needs all of these, but they are common shapes that help the codebase grow cleanly.

How Page Logic should use them

Page logic should stay thin. Let the page handler read the request, call the right class, and bind the final output data into the document.

That keeps the boundary clear. The page knows about the web request. The application class knows about the business rule. The view knows about presentation.

Keeping code framework-agnostic

As far as practical, application classes should not be tightly coupled to WebEngine. They should not need to know about the page lifecycle just to do their job.

That makes them easier to test and easier to reuse. It also keeps the framework at the edge of the application rather than at the centre of every class.

---

Next we'll learn about the client-side build system.