2

I have a situation where some commands are using some common methods. These were originally developed in one command and are now helpful to other commands, they can be static and are self contained.

public Command1 : ICommand
{
   // does something specific to some records
   // tidying up fields before they go to the db
   public static void DoSomePreRecordManuipulation(List<record> records)
   {
      //
   }

   public static void DoSomeMoreCommonThings(List<record> records)
   {
      //
   }

   public void Execute()
   {   
       ...
       DoSomePreRecordManuipulation(someRecords);
       ...
       //SaveDbChanges();
   }
}

public command2 : ICommand
{

   public void Execute()
   {
       ...
       BlahCommand.DoSomePreRecordManuipulation(someRecords);
       ...
       SaveDbChanges();
   }
}

As you can see from the example above, command2 is just calling the static method from the command1. However, suppose there are a few more methods and a few more commands involved.

Caveat : There is little chance of these being used many more times, but this might arise

Also, these methods are concerned with just a hand full of commands and common methods and are in their own sphere of influence.

So i'm wondering whether i should.

  1. Inject the main command into other commands to access these methods
  2. Make the methods static and reference the command directly for its static methods
  3. make a static helper class so the common methods (if needed again) are easier to find (and doesnt live down in the depths of CQRS)
  4. make a base class to encapsulate the logic (which would become a little unmanageable if more composition is needed

My thinking

  1. seems like a smell
  2. seems like it will be hard to find.
  3. seems a little over categorised, i.e its useful to have them as a helper, but their values seems limited
  4. hrmm (maybe)
  • A minimal example would probably be helpful here. – candied_orange Apr 3 '18 at 5:08
  • @CandiedOrange updated – TheGeneral Apr 3 '18 at 5:19
5

What you have here is a problem of code reutilization.

The CQRS commands should be simple, immutable, with behavior related to their own data. Their role is to express the intent of doing something and to carry the data necessary to do that. They are not libraries, helpers nor do they serve as code-reutilization artifacts.

The solutions that puts the responsibility of reutilizing the code into a command (1 and 2) are not OK as they would break the SRP applied to commands. If you do this, the commands would have more than one reason to change.

The best solution would be to extract the common behavior into its own class and use that class where necessary. For that you have two options:

  1. inject the class into the command; this has the advantage that the client of the command knows immediately what are the dependencies of the command but it has the disadvantage that it moves the burden of managing dependencies to the client.

  2. use static methods; this has the advantage that hides the dependency to another class but it is harder to test in isolation; on the other hand, who test the command in isolation? Remember, that a command does not have a complex behavior, only some field validation logic and maybe mutable list to immutable list conversion or sorting.

What solution to use depends on every use case but I would incline to use the static methods.

  • 2
    Thanks for the reply, and here have an up-vote for a very well articulated and elegant answer. – TheGeneral Apr 3 '18 at 6:12

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.