12 ms·
Sure thing. First, weirdly enough I prefer to call the Business logic layer just the Logic layer. This is just personal, for all intensive purposes its the Bus
by usernamebias 10y ago
Sure thing.
First, weirdly enough I prefer to call the Business logic layer just the Logic layer. This is just personal, for all intensive purposes its the Business logic.
Goes without saying this example is basic and open for improvements. Let's suppose an application exists where a user can donate $10 a month and the app would randomly distribute it to charities of the users choice.
-- Presentation layer, usually a public facing web application or mobile app will handle user interaction with said app. Here the pretty UI will make sure the user provides proper card information, charities etc.
-- Logic layer, will be some API that will process the users information and distribute the money programmatically.
-- Data layer, is some kind of relational database where data will can be persist if necessary. e.g User credentials.
Standard security protocols such as form validation and sanitization should always be performed both at Presentation level and at Logic level.
For compliance, Things like encryption at data rest and while its in transit are important. Method of communication between each layer would be critical as well. There is a whole LOT more things to consider so when thinking security. These are just an example.
- ruslan_talpa 10y agoFrom high level i agree with your statement (about separating stuff) but when you say "logic layer", what prevents me from looking at it as a specific schema (in the sens of PostgreSQL) in the db (call it api) that has only stored procedures and views and the presentation layer has access only to that schema and not the underlying data? I don't have to move data across between layers (data<->logic) over the network.