Storage layer and entity classes

Question

According to the book I am reading, in the three layer architecture (presentation, application ,storage), storage layer is responsible for looking after the persistence storage of data in the system. If so, I think entity classes are in the application layer.Is that correct? What classes will be in the storage layer? What is the difference between entity classes and the classes of storage layer? Can you please give me some examples?

Answer 1

There is not one truth here. People have different opinions and have their own definitions.

You have tagged your question with the UML tag, but UML does not define such things like "storage layer" or "entity class".

You have tagged your question with the "ecb-pattern" tag, but this pattern defines logical layers and does not prescribe a certain physical layering and vice versa, a physical layering does not prescribe a logical layering. The three-tier architecture you mention is probably a physical layering. Each physical layer may or may not use the ecb-pattern. This is a decision made by the software architect.

Most authors define the storage layer as being implemented by a database management system (DBMS) usually relational (RDBMS), where object-oriented notions like classes are not used. In that case, if the ecb-pattern is used, entity classes are part of the application layer and/or the presentation layer.

Example 1: The entity class Person could be a class in the application layer, which persists itself by sending a SQL message to the RDBMS (= storage layer). Class Person typically also implements business rules like "date of birth should be in the past".

Example 2: The entity class Person could be a class in the presentation layer, which persists itself by sending a message to the application layer, where the ecb-pattern is not used (suppose).

Answer 2

Entities are the low end database "parts". They represent the bits and pieces you put in the data storage for persistence. UML uses a stereotype which resembles a tape/head (if still someone remembers what that is):

The stereotypes for a boundary resemble a screen (or you can think of that being some projection). A boundary presents some information to an actor.

The control stereotype resembles a turning wheel (where you think of work being done) and it hides the business logic which react no boundary events and changes/reads entities.

You can also use rectangle notation:

Edit As @www.admiraalit.nl notes, this notation is not part of Superstructures itself (so not basic UML) but a common used notation in various UML profiles.