Hi,
Chapter 4 "Business Rules" of the E-book on CSLA 4: Creating Business Objects describes (p.83):
"You should use business rules to alter property values in your objects based on any sort of rule, algorithmic process, or calculation. Business rules can do something as simple as upper-casing a string value, or as complex as performing a tax, price, or discount calculation."
For read-only objects only authorization rules are called, but wouldn't it be perfectly valid to apply business rules (not validation rules!) on read-only objects as well, especially when it comes to presentation of data?
The example describes that it could be as simple as uppercasing a string. So as this is presentation only, why not support this in a read-only situation? This would allow changing the presentation without thinking about the data.
Wouldn't it make sense to separate business rules and validation rules?
Any thoughts?
Cheers,
Peter
No, I do not agree.
BusinessRules do add memory overhead and execution time overhead to data access. The RuleEngine as such treats all BusinessRules in the same manner nd ValidationRules is just one of the "variants" og BusinessRules.
The main principle is to keep the readonly objects as slim and fast as possible and only AuthorizationRules was added to this type (these will NOT add overhead on DataAccess and load time).
The idea is that if you _need_ display logic then you can either
You need to think of RO objects as immutable; nothing on them can change, so what would cause a recalculation? If you need some properties which are the result of a calculation, you'd do that while creating the RO instance and store it. The other thing to consider is sometimes you do want to refresh your RO objects; you can still have the calculation, the formula does not necessarily have be written directly into a business rule class, it can be done in another POCO class / static class.
Also, you can make RO only objects but subclass BusinessBase instead; you simply don't have any properties that are publically settable, and you would typically override SaveAsync to thrown an exception if Save is called; if you really wanted the scenario you describe, that would be the way to go.
Hi Jonny and Andy,
Thank you for the quick response!
Your answers are complementary and clear.
"Case closed"!
Cheers,
Peter
Copyright (c) Marimer LLC