Interesting example. You're striking a compromise between a small-object hierarchy (good OO design, from a purist's perspective) and better performance. You're considering the database layer's performance in the design of your object model.
This gets to the heart of EJB's value. EJB (and CMP in particular) is an abstracting technology that takes you out of the details of managing (and persisting) your objects at runtime. You are free to align your object model with your business logic, blissfully ignorant of performance at runtime. Performance is tuned at runtime, after the beans are deployed, in a very similar way to an RDBMS. This is a very attractive idea in many corporate IT settings. That's the theory, anyway. Both the spec and the vendors add lots of features designed to give you more control over performance *that gets built into the beans*, which violates the underlying philosophy. But we've been violating encapsulation since the early days of OO, so why stop now? ;-) If you are comfortable ignoring most performance issues in your business logic, EJB will support you in that. You can build clean, readable, maintainable object hierarchies, and let the app server worry about performance. If you want to tweak and tune things, you will find your hands tied in important ways with J2EE, or you'll have to make the sorts of compromises you discuss. But that's not uncommon in software projects today, is it? TG --- Atong Appa <[EMAIL PROTECTED]> wrote: > > >Two observations: > > > >1. Objects with 100's of attributes are a red flag > for me. It suggests > >the object model may need refactoring. Doing so > may improve the > >maintenance and performance issues you face, using > EJB or not. > > > > Take an order fulfillment line info for an example. > It needs a few columns > to identify itself (which order it belongs, an id > for identification). You > need a handful of information about when/how the > line was created: what was > the quote, how the line will be fulfilled, who will > be responsible for > tracking it. You need info on the item itself > (description, measture, > quoted process, currency conversion for the line, so > on). Since multiple > lines from multiple order will be lumped together > for fulfillment, you need > info on procurement. You need about 20 columns to > deal with internal > bookkeeping issues and stored calculations (so that > you wouldn't have to > compute these values every time). > > For each of these categories, you need some > audit-trail: when was it last > updated, has there been changes, who changed it, > why, etc. > > You would probably assert that these should all be > refactored into smaller > objects. Theoretically, it makes a lot of sense. > However, when it comes to > performing validation and actual processing of this > object, separating them > into say 6 objects means you have to manage > relationships among them and > manage caching of these objects. > > The tradeoff one has to make is where you define the > object class boundary. > You want the object to be self-contained enough that > you will not thrash > (keep bringing objects in and out) and that you > would spend too much time > modeling and managing relationships between objects, > BUT want the object > small enough to keep it maintainable would not > violate data integrity model > (in relational speak, be reasonably normalized). > > OO tends to force you to go small objects with lots > of relationships which > works well only if the cost of relationship > traversing is close to zero > (which it isn't). > > > >2. It is possible to avoid the object-relational > mapping problem > >altogether with non-relational database technology, > such as that available > >from Object Design or Versant. You give up SQL > access to your data with > >these databases, but you gain a simpler > architecture and better performance > >in applications where speed is critical. All the > SQL queries and O-R > >mapping code goes away, and you store your beans, > references and all, > >directly in the database. > > I am somewhat familiar with object databases and (no > offense) would stay > away from them for query-intensive apps. The main > trouble with odbs is > pretty much the same problem I described re: OO > paradigm above. It needs to > realize the entire object. So, if I want to project > and join, etc. (which > are all value-based operations), it falls flat on > its face. If you need to > manipulate the data and partition processing of data > between client and > server, odbs don't perform. If your objects don't > need manipulations like > projection and join, it works well. > > > Atong > > > > > >Why use EJB? You may or may not need it. Atong, > you might want to explain > >your application in further detail, and get > feedback on EJB's applicability > >from the list. It's difficult to discuss the > generic benefits of EJB > >beyond what you will find on Sun's web site. A > specific project discussion > >would make an interesting thread! > > > >[clip] > > > > > >Tom Groot > > > >=========================================================================== > >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". > > > > > _________________________________________________________________ > Join the world?s largest e-mail service with MSN > Hotmail. > http://www.hotmail.com > __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ =========================================================================== 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".
