Hi,
Very new to the framework. Still grappeling with it. In a web application, I have a need for a class the doesn't necessarily have any properites but possibly just some static methods that perform its business logic.
Something like:
public class SomethingI am trying to understand how best to accomplish this in CSLA. Going through the book, the model seems to be the "Exists" example for Project and Resource classes and using CommandBase. So each of my DoSomething methods above would be internal private command base classes that incorporate their logic.
Here is where it gets a little fuzzy for me.
1) What would the class (Something in the example above) inherit from in CSLA? Or wouldn't it inherit from anything?
2) How would I apply validation (or authorization for that matter) to these DoSomething methods?
I appreciate any direction you could give to this CLSA newbie.
Thanks
gb1:
1) What would the class (Something in the example above) inherit from in CSLA? Or wouldn't it inherit from anything?
2) How would I apply validation (or authorization for that matter) to these DoSomething methods?
1) The class inherits from CommandBase.
2) I'm not sure about validation, but for authorization you can check e.g.
[Serializable()]
public class CurrentAPPriceCommand : CommandBase
{
#region Authorization Methods
public static bool CanExecuteCommand()
{
// TODO: customize to check user role
//return ApplicationContext.User.IsInRole("");
return true;
}
#endregion
HTH some,
Mike
Hi,
Very new to the framework. Still grappeling with it. In a web application, I have a need for a class the doesn't necessarily have any properites but possibly just some static methods that perform its business logic.
...
public static void DoSomething1(int idToActUpon, int number)
...public static void DoSomething2(int IdToActUpon, string thing)
Here's my $0.02.
I wouldn't ever use a CommandBase (e.g. something like Exists) for business logic, because you lose much of the CSLA benefits (undo, validation rules, binding, authorization rules), and it seems to me like CSLA internally implements these as a specialized object much like BusinessBase (the command executes via a DataPortal_Update-like call).
The alternative I would suggest is to use a real BusinessBase derived class, where the input parameters to your "static" methods are instead properties of the a corresponding BO, and you do the same processing you'd do in the "Execute" method of a CommandBase type object in the DataPortal_Update() method of the BO.
This lets you validate the input, do data binding for the input, etc.
Any "method" you want to execute via CSLA can be almost by rote implemented as a BO where the parameters are instead properties and you execute the method logic when the BO is "saved". We are having great success with this technique as we port our existing legacy C++ applicaton to CSLA.
The DataPortal concept is very flexible.
Since you are new you may not be aware that there are many ways to branch your code in the DP.
1. I think you can use strongly typed Criteria objects and then pass them to the corresponding DP which takes that type of Criteria. Rocky's fraemwork then takes care of calling the right one.
e.g.
Protected Overrides Sub DataPortal_Fetch(ByVal criteria As MyCriteria1)
Protected Overrides Sub DataPortal_Fetch(ByVal criteria As MyCriteria2)
2. You can call the standard DP method:
Protected Overrides Sub DataPortal_Fetch(ByVal criteria As Object)
Inside this one method you can perform branching:
If TypeOf(criteria) Is MyCriteria1 Then
'do something
ElseIf TypeOf(criteria) Is MyCriteria2 Then
'do something else
End If
3. If you have 2 factory methods which both use the same criteria then you need another way to perform the branching. I added a String Parameter to my Criteria classes called MethodName.
If TypeOf(criteria) Is MyCriteria1 Then
Dim crit As MyCriteria1 = CType(criteria, MyCriteria1)
If crit.MethodName = "Method1" Then
'do something
ElseIf crit.MethodName = "Method2" Then
'do something else
End If
ElseIf TypeOf(criteria) Is MyCriteria2 Then
'do something else
End If
This should give you some ideas of the various ways you can branch your code.
Joe
...
rsbaker0. I like this idea. It would give me the flexibility to do all that CSLA brings (validation, auth, etc.) but upon looking at it, and using my example, wouldn't that turn each of my static DoSomething methods into separate classes. Otherwise how would DataPortal_Update() act upon the two differrent functions. If i have a couple of these situations it seems like it could get quite message fairly quickly.
...
Yes, this is exactly what happens. You can use several techniques to keep the scoping or organization similar to what you had before (e.g. use a namespace, nested classes, etc).
You'll find neat capabilities that you didn't anticpate by using BusinessBase derived objects rather than CommandBase objects. For instance, it becomes trivial to get the input onto a screen for testing, and you can even have "lists" of your "DoSomethings", etc.
It can also be easier to modify down the road if you find you need an additional input -- just add the new property and CSLA will take care of getting it server side for your update processing.
Copyright (c) Marimer LLC