I've an HttpHandler, which allows users to login to a system by passing in an encrypted code.Inside the ProcessRequest it performs quite a few steps.Retrieve the encrypted code from request (could be in Form/X-Header/Query)Decrypt it. (Results in an JSON string)Deserialize to a dynamic typeDetermine the type of request, could be login/register/activateValidate requestLoad user subscriptionLoad User entityIf Req.Type = Login -> Login using FormsAuthIf Req.Type = Register -> Create userIf Req.Type = Register -> Send Activation emailThis goes on. Currently this is something like a long if/else statement which I'm trying to refactor.I'm thinking of using the Chain Of Responsibility pattern to convert these steps in if/else to a chain which executes sequentially.However, this will be different from original CoR as only last few steps will actually handle the request, first steps will just do some pre-processing and make stage for last steps to perform it's job. My main problem is, different steps in the chain will work on different input data. First few steps (Decryption, Deserialization, etc) will work on strings while latter half should ideally work on deserialized dynamic object. I don't like the way it sounds.Am I trying to fit a round lid to an square bottle? Is this not a scenario where CoR can/should be applied? Are there any other patterns/strategies I could use to solve such scenarios.I thought of using the decorator pattern as well, but that doesn't suite me very well, as I'd like to be able to switch certain steps in and out (ex: email activation) for some scenarios.NOTE: I've seen this question as well, but not sure if it answers my question.
Get rid of long/Complex if..else statements using Chain of Responsibility?
c#;refactoring;design patterns;asp.net
Your ProcessRequest method is doing too much in one block of code.  Chain of Responsibility is an inappropriate pattern because some of these steps are mandatory and some are alternatives. Look at the last 3 steps - 8 to 10.  Your main method should not care what has to be done for each individual type of request.  All that should be happening here isIs the request type in my set of permitted types?If yes, invoke the corresponding classIf no, handle the error.That's going to be a very short block of code.  It does require you, somewhere else in your code, to create your request-type-specific class (and subclasses) and the set to contain them, but the benefit is that this block of code in your main method need never change.Step 5 should be a method of the type-specific class.Steps 6 and 7 can probably be encapsulated in a User object but also only mean something for existing users, so the User-object handling stuff should go inside the type-specific class.So we've already reduced the code toRetrieve the encrypted code from request (could be in Form/X-Header/Query)Decrypt it. (Results in an JSON string)Deserialize to a dynamic typeDetermine the type of request, could be login/register/activateif type in set-of-allowed-types then request-type = new type-specific-class else fail.if not request-type.validate() then failrequest-type.dostuff()See?  No patterns involved.  If-then-else chains are a bad smell, yes, but they can usually be replaced with a set of valid options or a switch statement.  Try that simple approach before going all pattern-mad.