Friday, May 12, 2006
« Developer Resources Update | Main | RegEx AND code is good »

If you haven't looked into CSLA yet, you need to.  Rocky has done a lot of thinking about the concept of business objects, and his stuff works great.  The framework he gives you really helps write clean, efficient, reusable code. 

Take his business rules model as an example.  Simply override "AddBusinessRules" (it is called when an object is instantiated) and add any combination of predefined rules from the "CommonRules" class or create your own (e.g. "ValidateGroupId" or "ValidateType").  This standardizes a way to get the business logic out of the UI and into the business object where it belongs.  The great thing is that the logic is reusable.  It can run on any tier - from the UI to the application server (potentially even in the DB - probably NOT recommended.)  You can use the same object to show errors to the end user in a Win/WebForm application, an Avalon app, or validate data from a Web Service.

Rocky, of course, does a much better job explaining this than I ever could, so go check him out: http://www.lhotka.net/

Get the full explanation in his latest book: Expert C#/VB 2005 Business Objects

Here's a snippet from one of my business objects to help you see how it all fits together:


    Protected Overrides Sub AddBusinessRules()

 

        With Me.ValidationRules

            ' "To" is required but max of 50

            .AddRule(AddressOf CommonRules.StringRequired, "To")

            .AddRule(AddressOf CommonRules.StringMaxLength, _

                New CommonRules.MaxLengthRuleArgs("To", 50))

 

            ' "From" is required, but max of 50

            .AddRule(AddressOf CommonRules.StringRequired, "From")

            .AddRule(AddressOf CommonRules.StringMaxLength, _

                New CommonRules.MaxLengthRuleArgs("From", 50))

 

            ' GroupID must be > 0

            .AddRule(AddressOf Me.ValidateGroupId, "GroupId")

 

            ' Message is not required but max of 500

            .AddRule(AddressOf CommonRules.StringMaxLength, _

                New CommonRules.MaxLengthRuleArgs("Message", 500))

 

            ' Apply custom "Type" rules

            .AddRule(AddressOf ValidateType, "Type")

        End With

 

    End Sub

 

 

 

    Private Function ValidateGroupId( _

        ByVal target As Object, ByVal e As RuleArgs) As Boolean

 

        If _groupId < 1 Then

            e.Description = "Invalid Group ID"

            Return False

        End If

        Return True

 

    End Function

 

 

 

    Private Function ValidateType( _

        ByVal target As Object, ByVal e As RuleArgs) As Boolean

 

        If Me._items.Count > 0 _

        AndAlso Me.Type <> RequestType.Reviewer Then

            e.Description = _

                "When group items are listed, type must be ""Reviewer"""

            Return False

        ElseIf Me._items.Count = 0 _

        AndAlso Me.Type = RequestType.Reviewer Then

            e.Description = _

                "Type cannot be ""Reviewer"" when group items are not listed"

            Return False

        End If

        Return True

 

    End Function

 

Friday, May 12, 2006 6:39:51 PM (Central Daylight Time, UTC-05:00)  #    Disclaimer  |  Comments [1]  |  Related posts:

Wednesday, May 17, 2006 5:53:55 PM (Central Daylight Time, UTC-05:00)
"probably NOT recommended" got me thinking...why not? Let's forget about the current mechanics, if you will, of databases. Our business objects usually end up matching our column widths, for example, and duplicate the logic of one-to-one or one-to-many, etc., relationships of our data. Why the duplication? Could all this business logic (i.e., reality) live together somewhere? What about expanding the definition of the OO database? My imagining is this: instead of object.save performing some interpretation to send it's properties via SQL into some plurality of tables, object.save just saves the object as is. Instead of laying out table structures, we write classes in the database. We instantiate an object *from the database*, fill it with data, and save it as is. Perhaps retrieving it could be as simple as passing-in a key upon instantiation: obj = New Object(key#). And perhaps our GUIs could read the logic in the DB objects, implementing it in the interface. The simplest case could be tying text box input lengths to objects’ properties. Instead of dragging and dropping (an aside: how can you drop something that you are merely dragging?) form controls only, we have the ability to drag and drop (onto a form) object properties, the definition of which is interpreted into an appropriate control. This could just be the tip of the iceburg...and perhaps this kind of crazed thinking is what turns normal, good folks into mad scientists and societal dangers.
Kaelin
Name
E-mail
(will show your gravatar icon)
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, strike, strong, sub, super, u)  

Enter the code shown (prevents robots):