Now let’s take a look at the business logic. A long time ago, applications were designed with all of their code in a single file as a long list of statements or commands. As applications became more complex, early software engineers looked for ways to improve software quality and organize code in a more manageable way. This gave rise to object-oriented programing. As applications became even larger, even with object-oriented programming, application developers needed a way to increase the flexibility and reusability of their application. This gave rise to n-tier applications. By breaking up an application into tiers or layers, developers only need to modify or add code to a specific layer, rather than rewrite the entire application. In general, you will find at least a presentation tier, a business logic tier, a data access tier, and a data tier. LightSwitch applications follow this tiered architecture, having a user interface layer, a business layer, and a data layer. The decision about where to put code is taken care of by LightSwitch.
Each of the entities that we created in our data model can be displayed on multiple screens. Therefore, make sure that your business logic is stored in services rather than in screens. In basic n-tier architecture-speak, the business logic belongs in the business logic layer, not in the user interface. To accomplish this, let’s go back to the entity designer for Ticket and explore the Write Code drop-down again.