Brian Pontarelli wrote:
> No it is different. What I'm saying is that if you pass around a Cat
> whose contract has the fix method on it, that method must be usable no
> matter where the cat instance is currently residing (i.e. which server
> it is on). If you pass that Cat instance to another server via Java
> Serialization or some other Serialization, that Cat needs to be
> "fixable" on that new server. If the fix method uses a service or a
> database, you can't guarantee that the database will be reachable on the
> new server.
Are you talking about wanting to be able to represent a Cat with fix()
on the server and without fix() on the client because of business-logic?
Or are you saying that technical limitations might cause fix() to fail
on the client? If it's the latter I argue that it's no different from
the server because even there the DB might become unreachable. If you're
arguing the former, then I argue you need different client-side and
server-side Cat interfaces because they are not really the same.
> It doesn't require you to pass rich models across the wire and in fact
> you really shouldn't do this. In general Rich Domain doesn't separate
> state from behavior, so you need to do that by hand when you pass the
> state across the wire.
I guess I am saying that you shouldn't be passing Rich Domain Objects
over the wire because (from practical experience) the server-side and
client-side interfaces are almost always "different enough" that you
can't share the interfaces. Clients usually contain a subset of the
server methods and might contain some client-only methods. I believe
Rich Domain Objects still hold a lot of value on the server-end, even if
you can't pass them to clients. Clients and servers can both run their
own show (with RDO) and communicate over the wire by passing a subset of
the state (DTO, REST, whatever you want to call it).
I argue you always need to define the client-server interface by hand.
Serializing your state-only Object to the client is very poor practice.
One reason is that you're essentially exposing an interface to the
client and this needs to be designed and exposed very carefully. The
other reason is that you can't rely on having Java on both ends of the wire.
Gili
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
