Changes between Initial Version and Version 2 of Ticket #933
- Timestamp:
- 02.02.2016 16:45:46 (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #933
- Property Status changed from new to accepted
-
Ticket #933 – Description
initial v2 1 Currently the various Core responsibilities -- DB access, DM object instantiation, Access Control, creating directives, firing events -- are still too intertwined. The current layering approach is not stringent and thus makes the DM architecture more and more difficult to maintain. This became evident in the face of the required refactoring of the Delete operation (see #833).1 From an architectural viewpoint the various Core responsibilities -- DB access, DM object instantiation, Access Control, creating directives, firing events -- are partly still too intertwined. The current layering approach is not stringent and thus makes the DM Core more and more difficult to maintain. This became evident in the face of the required refactoring of the Delete operation (see #833). 2 2 3 3 Internally the Core's model classes needs direct read access to the DB resp. to the type model cache. On the other hand the direct DB access must not be available to Core API users (and furthermore the Core API users should not be supposed to pass the `dms` object when creating model instances). This can be realized by specifying public interfaces for the model classes too. The Core API user would instantiate model objects through a public Model Factory then.