>> What's wrong with handing off your partially implemented
>> domain, letting the consultant subclass some of the classes for
>> white-box reuse and then GENERATE THE ENTITY BEANS using a tool? From
>> my reading of this list, it seems that many people feel that the best
>> thing is for the Entity bean to wrapper the domain object anyway, so
>> this would lend itself to tool use.
>Nothing is really wrong with it, in the sense that that will certainly
>work. It's more work for the consultant than other framework-based
>solutions I've given in the past, where the consultant subclasses maybe
>2 out of every 10 classes of a set of, say, 200 to implement custom
>behavior--in which he only typically overrides two methods. In your
>example, lots of what the consultant will have to do is boring, tedious,
>entirely avoidable work if only EJBs could inherit from one another.
The first part (the tool generation) part really refers to how to keep
implementation inheritance from the model into your Entities. From
re-reading your post, I see that you are not so much facing that problem
(I am, so perhaps I was projecting).
The second part of what I was getting at is that the Entity Bean does
not have to map one-to-one to a domain class. Some might use the Entity
as a factory for the domain class. If you use an PartyBean as an
wrapper for your domain object, the client that is referencing the the
Party remote interface does not know whether they are referencing an Org
or an Individual (using the previous example). All that you have to do
is implement your findByPrimaryKey (and create) in a way that knows how
to get the correct domain object.
In terms of inheriting an Entity Bean directly, how would the container
know which subclass to instantiate?
Great topic! Thanks.
Noah
S/MIME Cryptographic Signature
