I think you are being very reasonable here when considering VOs, as a
lot of people tend to use them blindly, esp. people coming from Java
backgrounds. A thing I hear very often is "with VOs you can be sure what
data you receive", which is true in a typed language, but in a dynamic
language, that's just not right.
Consider for example:
void addComments(CommentVO[] commentVOs) (Java)
Versus:
function addComments($commentVOs) (PHP)
Of course in Java, if a user tried to send an array of UserVO to
addComments in the first parameter, it would throw an error. In PHP
however, because it is untyped, no error is thrown, so you have to
manually check if you get the right type. Now if UserVO and CommentVO
both define an add() method, you can see that your addComments methods
could also be used to add users. Of course if users have administrative
rights, someone might use this to inject a new user with admin rights in
the db, and could wreck havoc on your system. The difference between
this and spoofing a call is that this is a really subtle security hole,
so you might not think about it. Honestly, it's not a huge hole, you
could definitely do a lot worse (I've seen people send SQL over the
wire, unencrypted, and unsecured), but I don't think trying to make PHP
into Java is a great idea (if so, why not use Java in the first place?)
I really see no issue in sending VOs back to Flash, because Flash runs
in a sandbox, so the worst that can happen is that the hacker's app
stops functioning. But sending them to the server... not the greatest idea.
Now I've seen a lot of code that looks like this:
$rs = mysql_query("SELECT * FROM the_table");
while($row = mysql_fetch_assoc($rs))
{
$vo = new UserVO();
$vo->id = $row['id'];
$vo->name = $row['name'];
$results[] = $vo;
}
return $results;
How is this any better than:
return mysql_query("SELECT * FROM the_table");
...I'm not sure... seems like it's quite a bit more code to add that
doesn't really serve that much of a purpose. Sure, you'll get VOs on the
Flash side, but if they are dumb VOs... what's the point?
Now if you actually want to send more complex data to Flash, for
example, if you wanted to send back a PostVO that includes an array of
CategoryVO, then since you're going to have to traverse the MySQL data
set anyway, you'd be justified in adding typing in as well. So basically
I'd say if you need simple data, stick with plain arrays and objects, if
you need more complex things, then VOs are cool. Right tool for the
right job, basically.
About ORM, the next version of amfphp will support Zend DB, so I'd
recommend trying out Zend_Db_Table, I looked at the docs yesterday and
it's pretty sweet. Doesn't handle associations or anything but it's
still cool. There's also Propel/Creole.
Kevin a écrit :
> On Jan 17, 2007, at 10:27 AM, Patrick Mineault wrote:
>> So you either have to make sure you do receive the VO type
>> you expect, using instanceof or is_a, or you should only use "dumb" VOs
>> which don't have any methods.
>
>
>
> I think that this is an important point, so I want to make sure
> I understand what you are saying since I have been debating whether to
> use VO's in my PHP.
>
> I can create dummy VO's as you suggested (which is essentially what my
> Flex VO's are), but I have been wondering what advantage I get from
> using VO's at all in PHP unless I attempt to implement an ORM approach
> and actually map the PHP VO directly to the MYSQL tables and abstract
> my SQL into these objects. I have been a little wary of this approach
> (for reasons other than security) since I need a more flexibility in
> my inserts, AND it sounds like you would not recommend this either due
> to the security holes it could reveal.
>
> However, the other advantage of VO's on the PHP side is to allow them
> to manage the deserialization of my MySQL results, and thus fully
> organize them into objects that can be easily mapped back to Flex. So...
>
> a) Does this present as big a security issue?
>
> b) Is a good way to approach the mapping of PHP to Flex? How are
> others solving this problem.
>
> c) If one could spoof a VO, wouldn't it be just as easy to spoof a
> method call (assuming I take a more procedural approach).
>
> I guess I don't fully understand why the procedural approach is more
> secure than the VO approach.
>
> I am new to understanding web security, so forgive me if I am being
> naive...
>
> thanks, Kevin
>
>
>
>
>
