Richard Monson-Haefel wrote: >How about an example of your approach? I
�ve heard a few people talk about >coarse-grained entities that encapsulate business object graphs, but I don't >have a clear idea of how this would work. I tend to believe that this would >lead to an inflexible manifestation of the business model. Of course >fine-grained objects like Address should not be entities -- even the >specification states that (dahh!), but your approach advocates encapsulate >coarser grained business objects within an entity bean? What Java classes >(objects), for example, would a Customer bean encapsulate? Pick a customer >from any domain. Try this example of a couple of beans dealing with orders: In our model, an Order contains (OrderNumber, CustomerName, DeliveryAddress, PaymentDetails). An OrderItem contains (ItemNumber, Quantity, OrderNumber, ProductCode, DeliveryDate). A Product contains (Price, ProductCode, ProductDescription, NumberInStock). The OrderBean controls customers orders for products. It would contain (CustomerName, DeliveryAddress, PaymentDetails, list of (ItemNumber, Productcode, ProductDescription, Quantity, Price, DeliveryDate)) The ProductReplenishBean controls whether stock is reordered from suppliers. It would contain (ProductCode, ProductDescription, NumberInStock, plus a list of (OrderNumber, Quantity, DeliveryDate). Both OrderBean and ProductReplenishBean use OrderItem, so if the application was developed using OO modelling, code generated from the model of the OrderItem would appear in both. This is AD-time-reuse. Order bean was developed for use by the call centre taking orders over the telephone and was reused to develop the direct web ordering system. This is Run-time-reuse. This difference between AD-time-reuse and Run-time-reuse is why there is a difference between objects and components. I hope this helps. Ian McCallion CICS Business Unit IBM Hursley [EMAIL PROTECTED] Tel: ++44-1962-818065 Fax: ++44-1962-818069
