PureMVC Architects Lounge

Announcements and General Discussion => General Discussion => Topic started by: wssbwssb on May 14, 2009, 07:23:27



Title: Where to put the enumerated VO?
Post by: wssbwssb on May 14, 2009, 07:23:27
Hi,

    when I study the employeeadmin demo. I see the enum package. The author wrote two classes named RoleEnum and DeptEnum. He declared some static variable to hold the data.

    In my application, I also need some enum data like the employeeadmin demo does.But the data will retrieve through a remote service.So I'm confused that where to put these enum data.
   
    i'm thinking put them into a Proxy. But I still need some static identifier to retrieve them.I don't know where to put these identifier.It's strange to put them in Proxy class.

Thanks.
Daniel


Title: Re: Where to put the enumerated VO?
Post by: puremvc on May 14, 2009, 08:10:50
Enums are generally written as you see them in the EmployeeAdmin demo. You don't create them from a database on the fly. The reason is if you're going to use static constants to refer to these values in your app, they can't be dynamic.

Like VOs, you typically write a client side version and a serverside version so that RemoteObject calls can pass them back and forth.

But the enumeration values don't change just because a new record is added to a lookup table in the DB. Unless you have middleware generating your enums and VOs, this is a manual task.

Adding new values to an enum class is just like adding new properties to a VO. It usually has three steps: database 'alter table', server class edit, client class edit.

Otherwise you're just dealing with rows of anonymous data and shouldn't be making any assumptions in your code about what the records contain. (i.e. making constants that refer to som data you expect to fetch).

-=Cliff>


Title: Re: Where to put the enumerated VO?
Post by: wssbwssb on May 14, 2009, 10:20:28
Hi,
   
    Thanks a lot,Cliff. This really help me a lot.Now it's clear to me to declear those Vos.
    Thank you very much:)

Thanks,
Daniel