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?
> 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.
> 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).
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
-~----------~----~----~----~------~----~------~--~---
