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?
Asked
Active
Viewed 241 times
2 Answers
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.
qwerty_so
- 35,448
- 8
- 62
- 86
-
Entities are low end data 'parts'. That means they are in the storage layer? The book I am reading put them in the storag layer package. – Ju Ju Jul 24 '16 at 12:01
-
Ehrm. Is that a question? – qwerty_so Jul 24 '16 at 12:25
-
@ThomasKilian, you are describing the stereotypes as defined by the Rational Unified Process, not by UML. – www.admiraalit.nl Jul 26 '16 at 07:26
-
@www.admiraalit.nl You are right, it's not part of Superstructures, but has become a common notation as part of some profiles. I'll update my answer. – qwerty_so Jul 26 '16 at 08:22
2
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).
www.admiraalit.nl
- 5,768
- 1
- 17
- 32