I want to share and ask about any suggestions, or feedback about what i have already done with CSLA on my last several projects. ( about 3 / 4 projects ) So I still need a lot of learning.
What I have done in my projects are like these :
1. I identify user stories into use cases. Almost all ( not all ) use cases become or have User Interfaces.
This is help me to get a lot what users will doing with my application.
2. So I design CSLA Objects based on each use cases with behaviors concept not data centric concept.
=> In this step I fell that each use case become a user interface and then I design a CSLA objects based on those UIs.
3. As I said in the first step NOT ALL USE CASE become UI. ( From my 3 or 4 experiences ) several behaviors can't be implemented into interactivity Business Objects. I will tell in an example for people understand easier
ex : I have one project about Junior High School Academic System ( one module about Annual Report Calculation, in my country the final result is not in A, B, C, etc. BUT in number like 89, 77, 54, etc ).
And each subjects has a little different property value ( I stored on DB ) that make a calculation formula a little different.
And then the scenario is : a user choose from the UI which grade he / she will start calculation.
I implement this using server side business object ( CommandObject ) because I think business logic ( calculation ) is not an interactivity case.
I don't know why at this step I Fell that I tend to write a procedural code for calculation logic which is wrapped in the execute method of CommandObject !!!
My Point Is : What I actually want to do is I want to implement this calculation business logic in more object oriented manner for example I want to implement strategy pattern for this calculation logic. BUT currently I still not successful ( I don't how to implement this in CSLA or may be any better ways to doing this )
Because the calculation rule is often changed because of Government Regulation.
For the record : I'm reading a design pattern book I like the principles SOLID. I think in several business case I can used that to solve my problem which is more maintainable and then lower cost development ( Like the Goal of Behavior Design Concept , CSLA too ). But Currently I just used CSLA or Get benefit from CSLA in the area of DataPortal for server client comunication , BusinessBase ( for interactivity ), Business Rule Like Validation Rule, etc.
I hope anyone could give me any suggesstions :)
Thanks a lot
Sounds like you're on the right path. Csla based object typically are the ones your users interact with via your UI layer, and they enforce the same rules. You certainly will have other non-interactive cases, and your classes here may or may not be Csla based; it depends on if there is any value to be had from Csla. I've found even in a few non-interactive cases Csla is helpful. For example I have a synchronization service, and I create a Csla based object, set its properties, and then ask if its valid to synchronize. If it is, I Save it and in my logic figure out all the tables that need to have data changed. If its not, I log that fact to another table, with the description of each broken rule.
For your calculation, you may have a Command object that fetches the result of the calculation (assuming you need to hit the db, you'll need to have something that can cross the tier boundary if you have your layers on multiple physical tiers), but perhaps the logic to do so is implemented by non-Csla classes which the command just tells to execute.
Finally SOLID is a good set of principles to go by, but sometimes you need to decide to bend them, you'll normally need to be more pragmatic about it than just saying "we can't do that because it violates a SOLID principle." Csla actually makes a choice to violate Single Responsibility (in favor of keeping encapsulation) by having business logic enforcement and data access in the same class. But these are the kinds of trade off you need to consider for yourself and make the best choice appropriate to your situation.
Copyright (c) Marimer LLC