> 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.
What I'm saying is that the fix method must be different on the client
and server. This generally means a different class for the client and
server. If it was the same class on the client and server, all the
logic would need to be pull out into a well known interface and that
interface would need to be different implementations on the client and
server, making the domain just a proxy and not very rich.
>
> 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).
Yeah, we agree on this. You shouldn't be passing around rich domain
objects because they don't work that way. This incurs a lot of code
overhead though.
>
> 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.
Not sure what you mean by this. You definitely have to define how your
client talks to the server and what your server responds with, since
that is the standard remoting paradigm. In terms of serializing a
state only object as poor practice, I think you might be confused,
because that's what you said you should do above with the DTO/REST/
whatever. DTOs are state objects.
Again, here's a concrete example so we are on the same page:
RDO
-------
public class ClientCat {
@Inject RemoteCatService cs;
boolean fixed;
public void fix() {
CatDTO dto = new CatDTO();
dto.fixed = this.fixed;
this.fixed = cs.fixTheCat(dto);
}
}
public class ServerCat {
@Inject EntityManager em;
boolean fixed;
public void fix() {
this.fixed = true;
em.persist(this);
}
}
public class CatDTO {
boolean fixed;
}
public class Client {
public void fixTheCat() {
ClientCat cat = DI.makeCat();
cat.fix();
}
}
// This class runs on a different server
public class RemoteCatService {
public void fixTheCat(CatDTO dto) {
ServerCat cat = DI.makeCat();
cat.fixed = dto.fixed;
cat.fix();
}
}
Anemic
----------
public class Cat {
boolean fixed;
}
public class Client {
@Inject RemoteCatService cs;
public void fixTheCat() {
Cat cat = new Cat();
cat = cs.fixTheCat(cat);
}
}
// This class runs on a different server
public class RemoteCatService {
@Inject EntityManager em;
public Cat fixTheCat(Cat cat) {
cat.fixed = true;
em.persist(cat);
return cat;
}
}
I like the second one personally. Less code and easy to manage. Plus,
I can pass my Cat around anywhere I want without transforming it into
other objects. In n-tiered systems, you could potentially pass the Cat
all the way from the front-end to the last tier and then back up. This
is how we built most stuff at Orbitz.
-bp
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
