none
WCF Service Operation returns empty class rather than void - what is the point of that? RRS feed

  • Question

  • in the code, see the comment on the last line, I want to know WHY this is being done?

    Is it to future proof the operation IN CASE one day something useful needs to be returned... "BaseResponse" is an empty class

    All the operations in this service appear to use a baseREquest and BaseResponse classes, which for most operations are empty... whats the reasoning behind this?

    effectively this class is called like "var r = svc.ChangePassword(new ChangePasswordRequest(user,p1,p2));

    and "r" is discarded because it contains nothing useful, and a try/catch is going to deal with any errors...

    can someone enlighten me as to the purpose/thinking around this process and if this can be improved/unsmellified I'd love some adbvice/guidance.

           public BaseResponse ChangePassword(ChangePasswordRequest request)
            {
                Ensure.ArgumentNotNull(request, "request");
                var Success = _securityManager.ChangePassword(request.Username, request.OldPassword, request.NewPassword) ;
                if (!Success)
                    throw new FaultException("Failed to change password for user " + request.Username);
                
                return new BaseResponse();// NOTE: nothing particularly useful returned
            }


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Thursday, May 28, 2015 4:25 PM

Answers

  • Yeah, just trying to understand reasoning behind doing it. (Technically your (first)answer was just an explanation of the code and its function/behavior whcih is not what I was after)

    I really wanted more insight into why one might choose this approach - you gave an opinion which I upvoted, thanks for that.

    Its not a big deal  -  just trying to understand reasons (if any) for doing/not doing such things (that's why I found your IMO, more useful) - there are almost always some - you say you've "done it", but you didn't provide insight into the reason behind your decision at the time (it was probably ages ago an you may not remember, so I'm not fussed).

    that's what I was trying to "get to".

    From doing a lot of reading of other threads on this forums, I think the answer is that the developer was probably trying to follow the Request/Response pattern as a consistent pattern through all calls on the service, and this is why some of them return mostly useless/ignored data...

    thnx for your ideas


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -




    • Marked as answer by noJedi Tuesday, June 2, 2015 3:23 PM
    • Edited by noJedi Wednesday, June 3, 2015 5:00 AM
    Tuesday, June 2, 2015 3:15 PM

All replies

  • The method's signature wants an object returned.

    public BaseResponse ChangePassword(ChangePasswordRequest request)

    So you either return an empty object of BaseResponse  or the return type can be null.

    retrun null; // No object is returned a null value.

    The code that made the call would need to make a null value check on BaseResponse upon the return to the code that made the call,  and any code after the call addressing BaseResponse would need to do the null check, if a null is returned. If a null object is not retuned, an empty BaseResponse  is returned, then no null check needs to be made on BaseResponse, becuase the empty object exist in memory instead of a null value object not in memory.

     If a null value object is addressed in code, then the program is going to blow-up with 'object not set to an instance of an object' error message/exception is going to be thrown, which is most likely the reason of an empty object being returned that exist in memory even though it is an empty object to avoid a possible exception being thrown,  if the object is addressed and it's a null value object.

    Thursday, May 28, 2015 6:51 PM
  • Hi Thanks fir the input bit i was more referring to tge reason the contract was setup like that... What is the point of having that ,as all your examples illustrate, potentially problematic return type when its effectively unused? is there a reason or is it just a poorly designed interface/contract?

    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Thursday, May 28, 2015 11:23 PM
  • Hi Thanks fir the input bit i was more referring to tge reason the contract was setup like that... What is the point of having that ,as all your examples illustrate, potentially problematic return type when its effectively unused? is there a reason or is it just a poorly designed interface/contract?

    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    IMO, one should not be sending back a null value anything. If an empty object is sent back, where is the harm in it? Maybe, the method shouldn't be called at all then, depreciated and code refactored.
    Friday, May 29, 2015 6:33 PM
  • Okay that's an opinion thanks.

    What I'm trying to figure out if there is a "method to the madness" (ie a reason why someone might do this RATHER than deprecating and/or refactoring).

    ie: is there a reason why SOMEONE might do this - ie supporting old client expecting this return type but doing nothing with it - in which case we might need to leave the thing "there" but create a new contract for new stuff to talk to, or is this here so that if someone changes things in future and WANTS to return something other than null then its easier... somehow...

    I don't know - I'm just guessing these things, and trying to get some insight from this forum as to why the previous developer/designer made things this way (system is undocumented and integrates with many legacy and other systems, so we are reluctant to pull on anything hastily).


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Sunday, May 31, 2015 1:18 AM
  • Hmm... just had a thought.

    Is a response of "object" vs void or something else done to try to distinguish from TimeoutException?

    I've seen a lot of instances where a timeout occurs but its because the task (on the server) took too long (but completed on the server successfully) to response... so the user receives "timeout" error but its effectively ignored (by client code) because 9/10 the action was received and its okay, we just don't have the "result" so the result is (over time) ignored because its unreliable...?

    I'm trying to grok this as I type, so its probably not making much sense, sorry...

    I'm not really sure what impact/influence this has on the above issue, but it MIGHT be related...maybe...?

    Is this a "thing" (ie - pattern, common occurrence, "best practice", or something)?


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -

    Sunday, May 31, 2015 1:43 AM
  • What I'm trying to figure out if there is a "method to the madness" (ie a reason why someone might do this RATHER than deprecating and/or refactoring).

    Look, I gave you the reasons why it is done.  I have done it and seen it done in code too. It's not that big of a deal and it is not uncommon. You are making more out of this than needs to be made. You either change the code or leave it alone. Those are your two options and it doesn't need to be beaten into the ground.

    Sunday, May 31, 2015 6:57 PM
  • Yeah, just trying to understand reasoning behind doing it. (Technically your (first)answer was just an explanation of the code and its function/behavior whcih is not what I was after)

    I really wanted more insight into why one might choose this approach - you gave an opinion which I upvoted, thanks for that.

    Its not a big deal  -  just trying to understand reasons (if any) for doing/not doing such things (that's why I found your IMO, more useful) - there are almost always some - you say you've "done it", but you didn't provide insight into the reason behind your decision at the time (it was probably ages ago an you may not remember, so I'm not fussed).

    that's what I was trying to "get to".

    From doing a lot of reading of other threads on this forums, I think the answer is that the developer was probably trying to follow the Request/Response pattern as a consistent pattern through all calls on the service, and this is why some of them return mostly useless/ignored data...

    thnx for your ideas


    - sure I'm noJedi but that's no reason to stop trying to make stuff levitate! -




    • Marked as answer by noJedi Tuesday, June 2, 2015 3:23 PM
    • Edited by noJedi Wednesday, June 3, 2015 5:00 AM
    Tuesday, June 2, 2015 3:15 PM
  • I don't see what you have replied and then marked as an answer is an answer. But hey, it's your thread and your show. :)
    Wednesday, June 3, 2015 2:45 AM