2014 May 26 3:39 PM
Hello,
I have an Data-Access Layer (SAP ABAP, but the language does not matter here) where I have 1 interface per entity/database-table, like
These interfaces are implemented by the actual database-access class-impls and a generated caching-layer, which is pretty simple since the methods really do not have any parameters and just return "the relevant" data.In certain consumers however, I require a filtered access to the returned data, specifically I need to get the data of all interfaces (~50) constrained by contract-position.So, do you recommend to
A) When extending every existing interface (the ~40-50 listed above) with the optional contract-position filter/constraint, the API is quite clean and would look like the following:
result = lo_data_object_calc->get_object_calculations( <FILTER> ).As already mentioned, it would require me to extend every implementation, the data-access as well as the generated caching-layer.
B) With the explicit filter-interface IF_DATA_FILTER_CONTRACT_POSITION on the other hand, I would have yet another interface-layer around data-access and I could generate the uncoupled filtering impls. I would neither need to touch the actual data-access impl nor the generated cache-layer. However, the usage would be a little more clumsy, like
TRY. " down-cast from data-interface to filter-interfaceRAISE i-need-a-filter-impl!
DATA lo_object_filter ?= lo_data_object_calc.
lo_object_filter->set_contract_position_filter( <FILTER> ).
CATCH could_not_cast.
ENDTRY.
result = lo_data_object_calc->get_object_calculations( ).
Hello,
I have an Data-Access Layer (SAP ABAP, but the language does not matter here) where I have 1 interface per entity/database-table, like
These interfaces are implemented by the actual database-access class-impls and a generated caching-layer, which is pretty simple since the methods really do not have any parameters and just return "the relevant" data.In certain consumers however, I require a filtered access to the returned data, specifically I need to get the data of all interfaces (~50) constrained by contract-position.So, do you recommend to
A) When extending every existing interface (the ~40-50 listed above) with the optional contract-position filter/constraint, the API is quite clean and would look like the following:
result = lo_data_object_calc->get_object_calculations( <FILTER> ).As already mentioned, it would require me to extend every implementation, the data-access as well as the generated caching-layer.
B) With the explicit filter-interface IF_DATA_FILTER_CONTRACT_POSITION on the other hand, I would have yet another interface-layer around data-access and I could generate the uncoupled filtering impls. I would neither need to touch the actual data-access impl nor the generated cache-layer. However, the usage would be a little more clumsy, like
TRY. " down-cast from data-interface to filter-interfaceRAISE i-need-a-filter-impl!
DATA lo_object_filter ?= lo_data_object_calc.
lo_object_filter->set_contract_position_filter( <FILTER> ).
CATCH could_not_cast.
ENDTRY.
result = lo_data_object_calc->get_object_calculations( ).
2014 Aug 05 8:11 AM
Update 05.08.2014: I decided to go with
C) create a seperate filter-object which explicitly filters the tables retrieved by e.g. get_object_calculations( ).
Reasoning: Separation of Concerns, explicit semantic of filtering, no need to update all interfaces or regenerate caching-layer.
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |