I'm curious what others think about best approaches to J2EE dev as pertains to trying to avoid anemic data models. I'm under the impression that it's considered good by many, to implement biz logic in model object as much as makes sense, and this notion makes perfect sense to me if you're doing proper OOD. To use an example of how I understand this could come into play, imagine there's a class representing tasks to be done, and these tasks could be on target or delinquent to a status date. I might implement a method on this class which takes in a status date and returns whether the instance is delinquent to that date or not. Assuming it's agreed this might be an appropriate approach, a question arises... Now what happens if I want to pass a collection of these 'task' objects via web service, to some none Java process? It would be nice to have the status (delinq. or not) of each task, encoded in the serialized xml versions wouldn't it? But, since the status is calculated in real-time rather than stored as a dumb param of a task, it won't be serialized.
If we used an anemic model and implemented this biz logic in an external component, such as a service class, we'd get around this issue, but now we're in anemia-land.
Maybe I just have to think of the web service layer sorta like a crappy web presentation layer which has its own anemic DTO-like model which mirrors my biz domain model and copies important data from biz domain model to corresponding DTO objects, including run-time calculated values, effectively taking a snapshot of my domain model objects? The crappiness of this approach perhaps is the shallow duplication of classes. It smells a little wrong to me...