CommandBase should be the same as BusinessBase... Only different :)

[lwmorris067]

I've been struggling with two issues. One is writing code that is self-documenting, the second is business objects with different behavior for Fetches, Inserts, etc.

I want to create a project that looks like:

Message (folder)
SendCommand.cs
ReceiveCommand.cs

That layout describes what can be done without even having to look at code. I like it from a self-documenting perspective. The usage would be something like:

var cmd= await _factory.GetPortal<Message.SendCommand>().CreateAsync();
cmd.Content = "Hello world!;

if(cmd.IsExecutable)
  cmd.Execute();

But I can't. I have at least 1 business rule, content is required. So... I can't use a command object.

Instead I have to do one of several things.

1. I can create a Message business object, then add a Send method that does a Save, then have [insert] perform the action.
2. I can create a send command with a message being pass to it. This complicates the code. The GetPortal is generic and, from a usage point of view, it doesn't really say which parameters need to be passed. I have to look.
3. I can create a send command, but have to code my rules in the execute method.

So...

I propose Csla either changes the CommandBase so it has the functionality of the BusinessBase

OR

Drop CommandBase and have BusinessBase support [Execute].

Just a thought.

[Chicagoan2016]

I have asked a similar question in the past about using BusinessBase as 'Command' object (When we have business rules involved) and @rockfordlhotka has confirmed he has done it in his projects as well.
I wonder if naming your objects 'appropriately' won't accomplish the self documenting purpose?

[lwmorris067]

Well, naming is the #1 most difficult thing about programming :) In this case, I'm not sure that's the issue.

I've just started using CSLA 6, so I can easily be missing something, but here's my thought process:

I need to receive/fetch a message. Then I need to indicate whether the message was successfully processed or if it failed.

The above statements make me think there's a Message (noun = businessbase) and two commands (verbs = commandbase).

ReadOnlyBusinessBase meets my requirements for Message. The only problem is knowing the parameters to pass into the portal's fetch method. I thought creating criteria classes could help as they are discoverable via tooltips. The criteria classes could be POCOs since most fetches don't require many parameters.

Commands pose a little more of a challenge. Like I did with fetch, I figure I can make some criteria classes, but since these could require many parameters, I would make them BusinessBases. I'm not crazy about some of the methods such as "Save", but at least I can make use of the business rules.

Even better, would be a CommandBase that worked like a BusinessBase, but instead of method names like "Save", there could just be an "Execute". You could probably remove some other things too, like BeginEdit, etc.

Is there a better way? Am I missing something? What would you do?

[Chicagoan2016]

I would still use the BusinessBase base class. 'Fetch' the message, process it and then call 'Save' (or whatever naming convention you prefer).
You could use Criteria object inherited from CriteriaBase but latest versions of Csla don't 'require' criteria classes.

[rockfordlhotka]

Keep in mind that the primary purpose of BusinessBase is to help you create a class that includes the full rules engine.

The data portal does treat CommandBase types differently from other types in terms of the ExecuteAsync method. Looking back, perhaps that wasn't the best design decision, but there's a (I think) reasonable solution.

What I do in this sort of situation is to use a BusinessBase subclass to collect and validate user input, then have a CommandBase subclass that contains the editable object to execute the command. Something like this:

[Serializable]
public class UserInput : BusinessBase<UserInput>
{
    // implement properties and rules

    // don't implement any data portal operation methods
}

[Serializable]
public class MyCommand : CommandBase<MyCommand>
{
    public static readonly PropertyInfo<UserInput> InputProperty = RegisterProperty<string>(c => c.Input);
    public UserInput Input
    {
        get { return GetProperty(InputProperty); }
        set { SetProperty(InputProperty, value); }
    }

    [Create]
    [RunLocal]
    private void Create()
    { }

    [Execute]
    private void Execute()
    {
        // execute the command based on info in Input
    }
}

[lwmorris067]

Thanks for taking the time to respond. I think I will do something similar.