I need a little help with designing a test application that I am writing.
I have created a "Policy" object that handles all of the CRUD operations for a policy. Now I want to add the ability to Transact a policy, and I'm not sure how to design this.
The first thought is to just add a few functions to the "Policy" object ("CanTransact" and " Transact") and put all the code in there. However, I think this breaks the single responsibility principle.
This leads me to believe that it should go into it's own class (e.g. "PolicyTransact"). If I do this what CSLA object does this use. Is it a command class or a businessbase? It won't have any data itself (just the policy object passed into it) so I'm thinking it will be a command class. Or would it not be a CSLA class at all?
Once that is created, how would I call this? Do I just have it seperate and pass in whatever policy object I want to transact, or do I still have a transact function on the Policy object that does it for me. I'm thinking of keeping it separate but using it in a public function might help keep this extra class more visible (to whoever is using the Policy class).
Any help will be appreciated. I'm just trying not to start doing something that will cause me more problems further down the line.
I recommend designing (not necessarily implementing) each user scenario (use case, user story, etc) independently.
So you apparently have an edit a policy user scenario, and your PolicyEdit (that's what I'd name it anyway) class supports that scenario - that's good. You probably also have PolicyList and PolicyInfo types so the user can select the policy to edit. Or something along that line anyway.
Now you have a transact a policy user scenario. Presumably you need PolicyList and PolicyInfo types so the user can select the policy to transact. And you need a PolicyTransactor class to transact the policy.
This PolicyTransactor class probably is a command stereotype, and its Transact method probably accepts a PolicyInfo object so it fits nicely into the object model.
The PolicyInfo class might be reused across these user scenarios. The PolicyList type might be different (or at least have two factory methods) because I assume the second user scenario would only retrieve policies that can be transacted.
Your actual user scenarios may vary, and therefore the specifics may vary - but hopefully this gives you some idea of how I'd approach the design anyway.
If the PoilcyTransact doesn't contain any data and simply process an action then I would use the command class. I'm assuming that your transact-policy action will do a database update; so by using a command class you automatically get all the CSLA goodness of a data portal, security and authorization. Rocky uses an OrderShipper command object to process an Order's shipping request in an example project for CSLA4. The OrderShipper command class has a Ship method that recevies an orderId and updates the invoice lines with a shipping date and returns a shipping number.
Copyright (c) Marimer LLC