S
SAgosto
Guest
I inherited a single tier of WCF services that use various different methods to returning data to the caller from a boolean to indicate success/failure to status codes enumeration. There is a need to create a common, reusable object that contains the API specific response (e.g. data to display, flag to indicate update was successful, etc.) with a generic response object that provides transparency into the caller's request. The generic response object would allow the API to return information, validation, exception, etc. messages with the high majority being error-based. For example, the caller (internal front end system) would know that the data does not exist and would be able to display it to the screen rather including any specific details rather than just guessing why the data is null.
The initial implementation uses dependency injection to create the API-specific response interface and the idea is to combine responses from the various methods that are executed during the work flow. For example, if the request is to retrieve some data, the API might call 3-5 methods including other services (NOTE: I inherited this...) that ALL might have responses that need to be returned. The goal is to 'combine' the responses back into the API-specific response and back to the call. And, here where I am having some second guessing as to finalizing the design.
1) Should the API-specific response interface inherit from the common response object's interface? Currently, the API-specific response inherits from the common response NOT at the interface level.
2) The majority of the methods are shared for the various APIs and I don't see any easy way to have them return common response information back. These shared methods could create a local instance of the common response so it can be returned back but you can't create an interface directly. You could create the interface from the underlying instantiated object? But, that seems funny.
Continue reading...
The initial implementation uses dependency injection to create the API-specific response interface and the idea is to combine responses from the various methods that are executed during the work flow. For example, if the request is to retrieve some data, the API might call 3-5 methods including other services (NOTE: I inherited this...) that ALL might have responses that need to be returned. The goal is to 'combine' the responses back into the API-specific response and back to the call. And, here where I am having some second guessing as to finalizing the design.
1) Should the API-specific response interface inherit from the common response object's interface? Currently, the API-specific response inherits from the common response NOT at the interface level.
2) The majority of the methods are shared for the various APIs and I don't see any easy way to have them return common response information back. These shared methods could create a local instance of the common response so it can be returned back but you can't create an interface directly. You could create the interface from the underlying instantiated object? But, that seems funny.
Continue reading...