What is difference between ApplicationLogic and PresentationLogic

[srinivasarao_kambala4]

difference between ApplicationLogic and PresentationLogic

[Former Member · Accepted solution]

Hi Srinivasarao,

When we talk about business logic - we mean the following kind of logic

• How we model real world business objects in our application - such as accounts, loans, travel itineraries etc

• How these objects are stored

• How these objects interact with each other - e.g. a bank account must have an owner and a bank holder's portfolio is the sum of his accounts

• Who can access and update these objects

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.

There are several reasons why separating business logic from presentation logic is desired. Below are a couple of reasons why we do it.

• The kind of programming you do for each part and sometimes the language you do it in are different. Separating the two allows one to use the best tools for that particular part. For example if you are programming a user interface screen - the kinds of things you are concerned with are paging - e.g. how many records to show on a page, widths of forms, colors, readability etc. There is also the need to see the screen as you are developing and to position the items. On the business side you are not so concerned about visuals - you need to get the data from somewhere and you need to control what data is loaded, and how that data is updated. If you change your programming languages next year, it is much easier to reuse old code when it is separated. E.g your presentation would be mostly html or xml which can be easily refitted with a different model.

• The two parts - business logic and presentation logic - do not always occur at the same time. For example, often times you design the screens first and then cut in the business logic later. Separating the two minimizes time dependency and allows for concurrent development. You can work on each part independently and then integrate them later or integrate in an iterative fashion.

• Separation of Workforce: This is important for big organizations with very specialized people, but is less important for small shops where often the programming of all parts is done by the same person.

• Separation of Thought and Readability of code: It is easier to read business logic that is not intermingled with presentation logic. Similarly, it is easier to look at the presentation of a screen or read html code without having to sift through the database and security logic. Case in point if you look at standard ASP,JSP, or PHP coding, you will often see structures with things like looping thru a dataset and spitting out results in html. If this happens it's hard to tell when an html tag is missing or find the logic that tells where the data is coming from.

Regards.

Gianluca Barile

[Former Member]

Hi Srinivasarao,

if you're satisfied by the answers set up this thread as ANSWERED and assign right points.

Thanks.

Best regards,

Gianluca Barile

[Former Member]

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