On Nov 7, 2008, at 11:23 AM, Gili Tzabari wrote:
>
> Brian Pontarelli wrote:
>> and you have also
>> lost the state of the cat prior to it being fixed unless you clone it
>> in the client code.
>
> I don't understand this part of your reply. What do you mean?
If you have this code:
Cat cat = new Cat();
cat.fix();
You have lost the cat that wasn't fixed. You can remedy this by making
Cat immutable:
Cat cat = new Cat();
Cat fixed = cat.fixed();
// cat is the original unfixed cat
Or by cloning:
Cat cat = new Cat();
Cat old = cat.clone();
cat.fix();
>
>
>> Anemic model can fix this situation easily. Plus,
>> in a distributed system, if I'm passing around a non-anemic Cat, the
>> fix method might not be guaranteed to work if the remote CatService
>> isn't reachable or the EntityManager can't connect to the database
>> from that server. Therefore, the contract is broken.
>
> I don't agree with this statement. This is no different from you
> trying
> to reach the database on the server end and it not being reachable
> for a
> different reason (i.e. you've surpassed the maximum number of
> connections or the database went down). In both cases your contract
> needs to allow for failure when interacting with the database.
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.
>
>
>> This means you
>> need an on-the-wire representation of the Cat (SDO, XML, value-
>> object,
>> transfer-object) and a DDD representation inside the tiers of the
>> system. This requires some data translation between the transfer-
>> object and the DDD once the remote server receives the message.
>
> I don't agree that Rich Domain Models (non-amnemic in your
> terminology)
> require you to pass rich models to the client. For example, you can
> use
> ROA/REST for client-server communication and in that paradigm you only
> pass the state back and forth. While it is true that ROA separates
> state
> from behavior it is worth noting it eliminates the service layer
> altogether (you're forced to use the same methods across all
> resources).
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. It gets even more interesting if you are
passing behavior across the wire (oh fun!). Let's do a simple example
so we are on the same page with this distributed model:
Client ----> Server
- Client creates a Cat
- Client passes Cat to Server to be "fixed"
This is a standard distributed computing approach whether it is via a
bus, service, tuple-space, whatever.
RDO approach
--------------------
Okay, if you pass the Cat to Server, the Server can't call the fix
method on the Cat, unless the service has been injected into the Cat
such that it works on the Server (using my DDD code from previous
post). Therefore, you probably want to have two Cat classes, one on
the client and one on the server like this:
Client ----> Server
(Cat1) (Cat2)
Then you need to pull the data out of the Cat1 and bundle it into
another object to be passed across the wire. This might be an HTTP
object, a XML object, SDO, whatever. I'll use Java Serialization and a
transfer-object:
Client -------------------> Server
(Cat1 into CatTO) (CatTO) (CatTO into
Cat2)
Okay, so now we have our RDO model that will correctly ensure that the
Cat's contract is always correct because the fix method on Cat2
doesn't make a remote call, but instead writes out the Cat to the
database.
Anemic approach
------------------------
The anemic approach ensures that the domain objects only contain data.
Therefore, we can bundle up the Cat and just toss it across the wire
since it is just a data holder (this gets tricky with versioning, but
ignore that for now). This will look like this:
Client ----> Server
(Cat) (Cat)
Since the client is simply invoking a service on the Server that takes
a Cat, all is well. That Service can return a new Cat or something
else entirely, doesn't matter because that object also only contains
data.
-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
-~----------~----~----~----~------~----~------~--~---
