Atong,
| >Well, you need to build some sort of persistence layer, otherwise
| >you end up with SQL everywhere which will kill you in
| >maintenance. We use CMP for the basic object retrival and
| >persistence and BMP for complex lists, tree tables and such.
| >
| >I also like to have all validation logic and core business logic
| >once in the business object (rather than all over the shop).
| >
Read on, you don't have to throw in the towel on this!!
| I have a few issues with EJB's persistence. In fact, the first one of these
| problems is not even unique to EJB, but OO paradigm in general. Many of
| objects has many columns of data (over 100 columns). When an application is
| running, the user typically works only with only a handful of these columns
| (human beings are not equipped to deal with 100's of pieces of info all at
| once).
|
| So, different applications ('modules' to be exact) work on different subsets
| of this large number of columns. Yet, the business logic must be
| centralized and managed in the context of one object class (like you
| mentioned).
What you need is a SQL-based "View Object" that lets your client
(Swing or JSP or Servlet or XML) work just with the bits of information,
ideally taking full advantage of the power of SQL joins, SQL query
projection, order by, subselects, and any database-vendor-specific SQL
construct that you choose to make your application perform best.
These "View Objects" should seamlessly coordinate with your underlying
centralized business logic in your entities so that updating information
through any "view shape" engages the single-source-of-truth validation
rules that you've written.
| The problem is that OO paradigm wants the entire object to be realized in
| memory before anything happens. This causes memory usage problems,
| scalability problems, and performance problems. Previously, we've attempted
| to implement 'partially initialized' object, but, like you said, this ended
| up strewing bits of SQL in many places--maintenance problems.
This is only if you do things the "textbook way", just using Entity Beans
in the way that EJB textbooks talk about them. If you make smarter use
of the parts of the EJB spec that allow for coarse-grained Session Bean
Facades to access local data access objects, you can have what you want.
The EJB spec allows this, but most people follow what they read in
the EJB books until they start hitting performance problems, or needing
to join SQL data, or other things.
Inside Oracle, we have over 20 large development teams building J2EE
business applications, and they had all of these same requirements.
So we built a framework called "Business Components for Java" that
automated all the necessary aspects of implementing this architecture
on top of the J2EE/EJB deployment platform so they could focus on
writing business logic and building great web UI's instead of on
figuring out how to (and then writing code to implement) a bunch
of J2EE Design Patterns application plumbing code. Yuck.
| For this kind of problems, EJB CMP is inappropriate. With BMP, we are
| likely to end up with SQL spread out. Is there something in EJB to help out
| with this kind of problem?
Yes, it's called BMP, but BMP used with a framework so you don't
have to end up strewing SQL all about or hand-writing JDBC code hoping
that you're using JDBC in the most efficient way...
| Also, we find that even for simple objects, we need to optimize SQL a great
| deal. We would end up adding many access plan and query optimization
| details to our SQL statements. This means we need to resort to BMP.
Amen. But if you use an metadata-driven framework to assist you with
your BMP implementation, then as far as developer productivity and
portability, you can have the same benefits as CMP if the framework
offers you these. You also can tweak the SQL to your needs.
| I understand your desire to stick with standards. But, are you concerned
| that EJB can survive and stay a viable standard (I am) for years to come?
| We've been burnt by CORBA once before and so are a bit gun-shy about
| emerging, new standard.
I'd suggest having a read of my technical whitepaper that
describe's our "Business Components for Java" J2EE application
framework. It delivers a set of off-the-shelf building blocks
that let you combine the full power of SQL with the central
encapsulation of business logic in lightweight, local entities
for deployment *either* straight to the J2EE Web Tier or
to the J2EE EJB Tier at your choosing (and you can try both ways
and measure the performance to see which you want to deploy in
production).
Visit: http://otn.oracle.com/products/jdev
and click on the link for the "Simplifying J2EE and EJB Development
with BC4J" whitepaper toward the middle of the page.
Hope this gives you some ideas to work with...
_____________________________________________________________________
Steve Muench - Developer, Product Manager, XML Evangelist, Author
"Simplifying J2EE and EJB Development with BC4J"
http://otn.oracle.com/products/jdev/htdocs/j2ee_with_bc4j/j2ee_with_bc4j.html
"Building Oracle XML Applications" - www.oreilly.com/catalog/orxmlapp
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
