Flex Part 02+: A Better Model Object

Published
by
T. Scot Clausing
on February 15, 2008
in ActionScript and Flex
. Tags: , , , , .

This post is an extension of an earlier post entitled "Flex Part 02: Value Objects & Model Objects".

Recap: Model Objects are similar to Value Objects in that they hold the same data, except that the Model Object is responsible for making sure that no 'bad' data gets into the VO. The Model Object enforces business rules like, "phone must be at least ten digits long" which a VO cannot do on its own. A Model Object may even include methods for easily manipulating properties.

In the earlier post I presented some example code for a Model Object. It turns out that what I provided is a pain to maintain over time. There's just too much duplication and poor use of public properties. Continue reading for my attempt at a better, easier Model Object ...

What's better?

This approach should help simplify the use of Model Objects. If you notice any pitfalls with this approach, please let me know. On to the benefits:

  • Requires accessor methods instead of public properties = Best practice
  • Dynamically create VO's and MO's = Less duplication
  • Less duplication = Easier to maintain
  • Easy to maintain = More likely to actually be used.

Continue reading to view the code. The example is drawn from School.as in the previous post. The new class is named SimpleSchool.

PLAIN TEXT
Actionscript:
  1. /**
  2. * Filename: SimpleSchool.as
  3. */
  4. package com.domain.project.model
  5. {
  6.     import com.domain.project.vo.SchoolVO;
  7.     import mx.utils.ObjectUtil;
  8.    
  9.     [Bindable]
  10.     public class SimpleSchool
  11.     {
  12.         /**
  13.          * Private instance of a School Value Object
  14.          */
  15.         private var vo:SchoolVO = new SchoolVO();;
  16.        
  17.        
  18.         /**
  19.          * Bindable accessor methods to enforce business logic
  20.          */
  21.         public function set id    (value:uint):void { vo.id = value; }
  22.         public function get id    ():uint { return vo.id; }
  23.        
  24.         public function set name    (value:String):void { vo.name = value; }
  25.         public function get name    ():String { return vo.name; }
  26.        
  27.         public function set phone   (value:String):void {
  28.             (value.length>= 10) ? vo.phone = value : trace('Phone number is too short');
  29.         }
  30.         public function get phone   ():String {
  31.             return vo.phone;
  32.         }
  33.        
  34.        
  35.         /**
  36.          * Return a new SchoolVO instance from the private instance 'vo'
  37.          */
  38.         public function toVO():SchoolVO
  39.         {
  40.             var newVO:SchoolVO  = new SchoolVO;
  41.             var oldVO:Object    = ObjectUtil.copy(vo);
  42.             for (var property:String in oldVO) {
  43.                 newVO[property] = oldVO[property];
  44.             }
  45.             return newVO;
  46.         }
  47.        
  48.        
  49.         /**
  50.          * Return a SimpleSchool instance with values from a SchoolVO instance
  51.          */
  52.         public static function fromVO(vo:SchoolVO):SimpleSchool
  53.         {
  54.             var newMO:SimpleSchool  = new SimpleSchool();
  55.             var oldVO:Object        = ObjectUtil.copy(vo);
  56.             for (var property:String in oldVO) {
  57.                 newMO[property] = oldVO[property];
  58.             }
  59.             return newMO;
  60.         }
  61.     }
  62. }

Hey, that is better

Instead of redefining the VO's properties, we use accessor methods to enforce business logic and update the value of a private VO instance. And when it's time to get a VO from the Model Object (or create a Model Object from a VO), it's done automatically without having to list all the VO's properties again.

So, if you add a property to your Value Object ... just add the get and set accessor methods to the Model Object and it's good to go. Plus the structure is already in place to add logic/validation/formatting etc through the setter methods without having to think about it.

Thank you for reading. Your comments are very much appreciated. Remember that these posts are living documents and will be updated over time as input is received and new ideas emerge. So, please, consider your comment a contribution.

7 Responses to “Flex Part 02+: A Better Model Object”

Feed for this Entry Trackback Address
  1. 1 T. Scot Clausing
    February 23, 2008 at 1:58 pm

    Note:
    If your Value Objects use RemoteClass meta data (to map to a server side VO), the toVO() method may simply return the result of ObjectUtil.copy(_vo). However, the fromVO() implementation will need to change.

    fromVO() needs an array of property names which can be either obtained with ObjectUtil.getClassInfo(vo).properties OR you will need to declare a private static array in the Model Object which holds an array of the VO's property names. The fromVO() method will loop through the values in the array instead of using ObjectUtil.copy() implementation shown above.

    When using meta data to map to a server side object, ObjectUtil.copy() returns a normal class instance instead of a dynamic Object class instance. Only dynamically added properties can be looped through in the way shown above. If you would like to see an example, let me know! I still very much favor this solution.

  2. 2 dsissoko
    March 23, 2008 at 3:48 pm

    Thanks thor this post.
    i'm interested in the solution for the issue about RemoteClass meta data usage.
    Can you post some sample code for the toVO and fromVO methods ?

  3. 3 T. Scot Clausing
    March 23, 2008 at 7:50 pm

    Yes. I actually have updated code for this post. I'll post it as soon as I can - (on vacation for a couple days).

  4. 4 Derek Basch
    April 22, 2008 at 12:14 pm

    I was bugged by the inability to enumerate static Value Objects too. I found a good solution here:

    http://www.lynchconsulting.com.au/blog/index.cfm/2008/2/6/AS3--Looping-over-properties-of-a-class

    flash.util.describeType() returns an XML Object with static members and can be nicely enumerated.

  5. 5 Gordon
    November 2, 2008 at 5:13 am

    Hi.

    I think I follow the logic of this "better" method. And your example at
    http://blog.tsclausing.com/post/9 was really, really, really useful to me as a flex noobie. However, I don't quite see how this "better" way of doing models would work in actual code. Maybe it is that I am still fuzzy on setters and getters. Can you provide an example of the model locator code where you use the SimpleSchool model instead of the School model? Just something that shows the setters and getters working and value object properties emerging in the code.

    Everything else has been great in this series. Reading your first example of Value Objects and the table row analogy was a total "Aha" moment for me. Keep up the good work.

  6. 6 prashanth
    December 16, 2008 at 11:51 am

    Hi,
    Can't the Model Object and Value Object be the same Object? We can define say the phone accessor in VO as well. Is there a reasoning to use VO and convert it to Model object?

  7. 7 T. Scot Clausing
    December 17, 2008 at 8:47 am

    Sure. And in most cases that is probably the quickest way to get up and running and may be entirely sufficient for your project. I just like to keep the VO's as light as possible for remoting.

    Value Object: Represents only the data (values) that are persisted or retrieved.

    Model Object: Enforces business rules through accessor methods, handles copying and comparing custom object equality, and may contain convenience methods for various tasks (like a getter for "fullName" that returns a concatenated first and last name).

    There's no right or wrong way to do it - just personal preference.

Leave a Reply