>> Exactly! 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. If your EJB server does not include
>> one, then your group could create one without too much trouble.
> Having to write a tool to generate my code tells me the model is broken.Having to
>write a tool to > generate my code tells me the model is broken.
I prefer not to write out all of the boilerplate for the objects to work
with the EJB Container by hand. There is a long history of good tools
to help implement or deploy classes into a component model (like
visigenics' tool, or the COM ATL wizard, etc.).
> This is fine, as long as it covers the majority of cases. However, it
> is overshadowed by any fatal flaw of the model.
>> The issues that you brought up exist in every component model.
> Every component model fails to support inheritence?
Sure. How do you subclass a COM object? Or a CORBA server impl class?
I'm not sure that I would call the JavaBeans construct a component
model, but if we did, then you could use inheritance there. I have been
told that Delphi controls also support inheritance, but we think that
this was implemented through code generation so I might retract 1/2 my
statement.
I didn't mean to start a philosophical sidebar, I just am facing many of
the same domain/component model mapping problems as the other posters
and am interested in finding a solution. It doesn't really bother me if
the solution isn't a PURE and RIGHT construct, neither is the domain
model usually.
Thanks for the discussion,
Noah
S/MIME Cryptographic Signature
