This question is a little too broad for SO and you did not really investigate before by e.g. reading the documentation. Hence the downvotes.
Nevertheless, I will link you to the appropriate documentation page and provide a short excerpt and explication:
Controls can aggregate other controls. These controls with aggregations serve as a container or layout control to which the application can add child controls. They can also serve as composite controls if the control itself adds child controls and reuses available components. In an aggregation, child controls are owned by the parent control and are destroyed together with the parent control. A control can only have one aggregation parent. Adding the control to another aggregation removes it from the previous parent control.
In a nutshell, aggregations in UI5 have mostly the same meaning as a typical OOP aggregation: they represent has-a or conversely a is-a-part-of relationship between controls. Tables have rows, rows have cells and so on. The lifecycles of the related controls are bound (when the parent is destroyed, the children are also destroyed).
When looking strictly at aggregations, a UI5 application consists of a tree of controls, where the controls of one level are part of an aggregation of a control from the level above.
Each aggregation has its own semantics. For example the items of a sa.m.Table are displayed between the header and the footer and the pages of a NavContainer are displayed one at a time. The behavior of the aggregation contents is generally described in the SDK reference.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
