Methodology to find the right enitybean

Question

Hi,
There are many discussions of the benefit of using enity bean(CMP and BMP), can someone provide some clues/links about the methodology of identify entity beans give an existing database?
1. make each table an entity bean, certainly not
2. make an entity bean a group of join of tables, isn't that use cases driven? what if use cases change, the entity beans also have to be changed accordingly?
Thanks much

Answer 1

Greetings,
Only as a consequence if poor understanding ofEntity
Beans, their nature and purpose! Er, and, ofcourse,
poor application design... which, in turn, maydepend
on poor understanding of the businessrequirements...
which, hopefully, have been sufficiently
documented...Hmmm...you are saying that most J2EE applications,
particularily new ones do not end up doing exactly
that?No, nor can I say that - being able to speak
only out of my own experience...
In my experience, and from reading here, most solutions end up doing that (keep in mind that most mappings are in a single solution are 1 to 1 not all.)
I am not saying that that is necessarily correct for all of those solutions. But I am far from certain that many of them should have been using any entity beans at all.
What I was saying, however, is that a commonly held
misunderstanding of Entity Beans result too often in
their use as little more than elaborate "data
accessors" - Sun and the JCP did not need to reinvent
the wheel for data integration purposes! Even a
casual reading of the specification reveals their real
purpose to be to provide an object-oriented view of
enterprise data regardless of where that data
is stored! The specification is further careful to
qualify (on several occasions) a relational resource
as only the "typical" storage mechanism against
which to map Entity Bean<-->entity associations.
Object databases, legacy systems, and "applications"
are pointed to as additionally valid resource targets
for Entity Beans. Therefore, the practice of
"mapping one bean to one table" is merely one
technique for implementing Entity Beans in
"typical use" scenarios.Yes, but most scenarios are exactly that which is why I say "most".
I would still like to try something where a single entity maps to a complex external system. Perhaps using a screen scrape interface (not because I like screen scraping but rather because the interface seems so extreme.)
>
This is also, indeed, even a poorly conceived
technique since one "enterprise data" - a.k.a.
"entities" are often composed of a hierarchy of
abstracts - a "Customer" derives from a "Person" which
has an "Address" and "Contact Numbers" comprised of
"Cities", "States", "Countries", "Post Codes", "Area
Codes", etc... - all of which, in a relational model,
may be broken into multiple "tables" against which all
could have an Entity Bean mapping. Does that
mean, however, that all are appropriate for container
persistent existence?? In this scenario, the
application may indeed benefit from "Cities", "States"
and the like being accessible as shared, persistent,
objects, but does it, for example, really need
to make all "Contact Numbers" available the same way?
Ultimately, it, again, is dependent on the needs of
the application. The point is, however, blindly
"mapping 1 bean to one table" can, and usually does,
lead to quick bottleneck of resource and serious
degradation of performance - leaving the platform to
blame for the misunderstanding, or outright
ignorance, of that platform by the developer.
That is probably true. But I wonder how many applications end up with those sorts of hierarchies. From these forums certainly some do, but I have never worked on one.
...A closer review of the Entity Bean's lifecycle and
it should become clear-er that providing "an
object-oriented view of enterprise data" does NOT
necessarily translate into doing the same for ALL of
that data, nor is appropriate in all business
processes. Entity Beans provide a shared and (in
container) persistent object-oriented view of
enterprise data. The key words here are shared
and object-oriented. The first implies
multi-client or, at least, frequent single client,
access. The last implies in-memory residence, for
which the container must ensure proper loading of the
entity from it's resource. Mapping an Entity Bean to
the resource without considering the level of the
data's sharedness or the benefit of having it
in-memory resident often leads to a typical
cluttering of the application server and a huge waste
of resources. Further, doing so without considering
whether the business process requires every entity of
concern to be coincidentally loaded into an in-memory
object representation of in order to complete also
typically leads to a bottleneck at the resource
and a needless degradation of it's performance!
Yep.
So, again, no, I'm not saying that "most J2EE
applications ... do not end up [mapping 1 bean to
every table]" - rather, in fact, I'm saying that most
(especially "new ones", which likely start as a
consequence of reading the "hype" and "cool-ness"
surrounding J2EE, but not it's more boring technical
details(!)), unfortunately do do that and
inevitably end up undergoing "changes" thanks largely
to unexpectedly negative and grossly misunderstood
performance results...
Ok. But I would guess that the OP hasn't done this before. And I suspect that many problems which have an entity solution applied to them aren't going to suffer too terribly due to this, simply because they probably didn't need any entities in the first place, and/or because the project is likely to suffer from poor requirements/design which would impact performance far more than any technology would.
Multi-tier separation evolved as a development
paradigm largely because of this. More oftenthan
not, the application's user interface (i.e
it's
"views") change more frequently and rapidly - and
a-ffectively - than either it's business logic or
integrations. Business logic is usually next to
change - along with the "business" - but when the
change is large enough the existing applicationis
scrapped anyway... what always remains, however,is
the data. ;)In the non-trivial change orders I have worked onsome
existing entity beans are always impacted. Not to
mention the ripple effects that go along with thatand
with the new functionality. I haven't seenanything
You are referring to "requirements changes" which,
like requirements generally, involve the "data of
business" (which Entity Beans may, in turn, map); I
was referring to "business changes" which the
business logic models and the application
encapsulates. When "business" changes enough (to
which I personally have bore witness during my time at
MCI, Sun, and SAIC), prior "business logic" is no
longer valid and must be "re-evaluated". In these
cases, however, "business data" remains continually
relevant to the changing enterprise.
No I wasn't, although I was imprecise. I am referring to existing solutions which have to be changed because the business changed.