I'm a big advocate of separating an application's logic from it's user interface. By keeping the logic separate from the data presentation layer (UI), it becomes easy to swap out either component with minimal impact on the other. In addition to ease of replacing components, keeping the user interface separate from the application logic avoids blocking the UI during expensive operations.
Business Logic is often broken further into two components in the Model-View-Controller (MVC) paradigm -- the Model, which defines how the data will be stored and retrieved; and the Controller, which controls the interaction between the Model and the View. For simplicity and practicality, we are not going to make this distinction. In many cases, we feel this distinction is unnecessary because the control flow pattern of the Model and the Controller is very similar and conceived of at the same time. So the benefits of separation or thinking of them as independent are often mitigated by the hassle of the extra layer.
When we speak about Presentation Logic we mean how we display these objects to a user. E.g do we have a drop down list or a popup screen? Do we display accounts in a list format and have the user pick which one to edit? etc. This is often referred to as the View in the MVC paradigm.
It is often difficult to determine where business logic ends and presentation logic begins. How you model your application often dictates what is possible in the user interface. Sometimes the business and presentation logic is so intricate and dependent on each other that the two get intertwined with each other. Sometimes it is often difficult or impossible to separate the two. In most other cases, separating the two is just a matter of discipline.
please reward points if you find my explanation useful.
regards
Anil
Bluesky
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.