>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 =========================================================================== 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".
