Dear ladies and sirs.
What is the rationale for removing this method? We found it very useful and used it very much. It allows to pass one command to the server and get back another command, which we think of as a command result.
Take for instance, we have a LogOnCommand. It carries the user credentials, but what gets back is LogOnCommandResult, which has a different set of properties.
The non generic method made this easy. What was the issue with it, that made it incompatible with the CSLA 4 scheme of things?
Thanks.
How did you do that? The design of Execute() is to round-trip one object from client to server to client.
Easy. This works fine when ObjectFactory is used.
Imagine MyCommand and MyCommandResult both deriving from CommandBase.
Then the following code works in CSLA 3.8:
CommandBase myCmd = new MyCommand(....);
var myCmdResult = (MyCommandResult)DataPortal.Execute(myCmd);
The respective object factory execute method can be declared like so:
private MyCommandResult ExecuteMyCommand(MyCommand cmd)
{
.....
return new MyCommandResult(...);
}
That's it.
Interesting. That is certainly an unintended consequence of the object factory. I'll have to think about whether I want to open that door officially or not.
Can you share the reasons why not?
Copyright (c) Marimer LLC