One of the most important organizational rules to follow is keeping what is known as your user interface and business logic separate. We haven't written any user interface logic yet, but we will in upcoming lessons. In this lesson we'll explore what user interface and business logics are, and what each handles.
Consider a basic calculator application. Its code falls into two categories: Code that performs calculations, or code responsible for interacting with the user.
The code that handles arithmetic is the business logic. It's the 'inner workings' of the application that performs calculations and returns a value. It's what takes the numbers
5, adds them together, and arrives at
9. The functions we've explored so far are all business logic.
The code that handles interacting with users is the user interface logic. It retrieves information from the user and provides it to the business logic to calculate. While buttons on a calculator may be labeled with numbers, they're just visual buttons. User interface logic is what translates clicking on this area of the page:
... into the number
4. After all, we cannot perform addition on buttons, but you can perform addition on numbers. The user interface logic registers that the user has pushed the button labelled "4". It then provides the number
4 to the business logic where we may perform calculations with it.
Let's say we also press the buttons labelled "+" and "5". The user interface logic also translates these interactions into the number
5 and recognizes it will need a method for addition. The business logic then adds the numbers
5 together, and returns
9. The user interface logic can then display this result to the user:
User interface logic handles interacting with the user including displaying or gathering information. The business logic handles calculating or manipulating information behind the scenes.
Remember, we want to write clean, well-organized code. Because user interface and business logic have separate purposes, their code should always be separate. So far, we've only written business logic, so we don't have much to worry about. But keep this rule in mind as we begin to explore user interface logic with jQuery in the coming lessons.
You may be wondering about
alert. We've been putting these in our business logic - but aren't they actually user interface logic?
alert really don't belong in business logic - we've been using them because they are the easiest way for beginners to get a user response. In fact,
alert really shouldn't be in UI logic, either - very few users like to be prompted or alerted (and both now have strong associations with hacky sites and malware). We will use them for a little while longer because they are easy to use - but be aware they should generally be avoided.
Business logic: The code responsible for handling the evaluation and manipulation of data; does not require any user interface.
User interface logic: The code responsible for the interaction between the user and the application; handles tasks such as event listening, user input forms, DOM manipulation, display and styling. We have not covered how to write the actual code for this yet; don't worry!
Because they are responsible for entirely separate things, code for business logic and user interface logic should always be separated. We have not yet written any applications that use both; but as we explore jQuery in the upcoming lessons, always keep this rule in mind.
Lesson 1 of 13
Last updated more than 3 months ago.