Tibo, What you have described is basically exactly what we did. All, As one person already pointed out - and I'm sure more will, my example wasn't the best one. There are holes that can be poked in it that don't have to do with the topic at hand. All my real examples seemed particular to the project I Iam on, so didn't want to get into that kinda detail. Tibo here has better characterized what I am talking about.
Mike --- Thibault Cuvillier <[EMAIL PROTECTED]> wrote: > ** Mike, I send you my reply directly because my email address > changed, so I > cannot subscribe/unsubscribe/post anymore. If you find my reply > interesting, > you can forward it to the mailing list. Tks** > > Mike, > > In you mail, you compared OO versus SO (Service Oriented). In fact > you > should probably better to compare DOOD versus SOOD: Data Object > Oriented > Design versus Service Object Oriented design. SOOD and DOOD are > Object > Oriented: SOOD as well as DOOD uses polymorphisms, inheritance, > encapsulation (OO concepts). > > But you cannot put side by side SOOD and DOOD. The service > implementation is > based on a data layer (Business Objects), which is DOOD, but DOOD is > encapsulated by the service interface. > > ------------ > | Services | SOOD > ------------ <-- // May be more complex > | Data | DOOD > ------------ > | Storage | > ------------ > > Classes in the data layer are not only a passive state holder, but > may be an > intelligent state holder. Such an example, a PopCornBox object may > notify > **by itself** if it is close to be empty. But there usually no-or-low > Business objects to Business objects collaboration. The data may > contain > some simple business logic, but it's an encapsulated design choice. > > So what is the difference between a business object method and a > service > method? Service methods are usually coarser grained methods, and may > implement some workflow aspects. At the higher level of the > architecture on > the server side, a service object will supply atomic and > coarse-grained > transactions required by the client. > > System integration cannot be handled at the data level. Any change in > the > data model should impact the overall system. Service based > integration > creates a weaker system integration. WebServices is a good example: > this > high-level integration technology is service oriented, not data > oriented, > but you face the same issue when designing an EJB based system. > > My 2 euro-cents. > Tibo > Valtech - Consulting- Project-Training > "We create business value through technology" > > > -----Original Message----- > > From: Mike Dunbar [mailto:[EMAIL PROTECTED]] > > Sent: mercredi 15 mai 2002 16:57 > > To: [EMAIL PROTECTED] > > Subject: Off Topic: Architecture, Service-Based vs Classic OO [was > Re: > > date service] > > > > To me, this is brings up an interesting topic and I would love to > hear > > what others think about it. It reminds me of what someone recently > > presented to me as the "classic OO" approach versus a > "service-based" > > approach. > > > > They characterized the classic OO approach as putting each business > > logic method in the most fitting domain entity class (a domain > entity > > class being a data-encapsulating class, like Customer). They > > characterized the service-based approach as moving all business > logic > > methods into seperate service classes, and restricting the domain > > entity classes to get/set methods for the encapsulated data -like a > > JavaBean. > > > > I'll give a simplified example that will hopefully convey the > > difference. Assume a Customer class, containing name, address, etc. > > data for a customer. Also assume a getCustomersInRegion(Region r) > > method, returning all customers for a given region. > > > > Classic OO Approach: > > Place the get/set methods for name, address, etc. AND the > > getCustomersInRegion method in the Customer class. > > > > Service-Based Approach: > > ONLY place the get/set methods for name, address, etc. in a > > CustomerBean class, and place the getCustomersInRegion method - and > all > > other non get/set data methods - in a seperate CustomerService > class. > > > > Now, I consider myself an ardent lover of OO, my education > initially > > being Bertrand Meyer's OOSC2 > > (http://www.eiffel.com/doc/oosc/page.html). So, I initially wanted > to > > stick with alloting business logic methods to appropriate data > bearing > > classes. Isn't that what OO's about after all - marrying data and > > functionality? However, we have tried to more or less adopt this > > approach on my current project, and I kind of like it. You still > get > > benefits like information hiding, polymorphism, etc. The person who > > advocated it claims that it facilitates greater reuse, but I have > yet > > to pin them down for an explanation. Frankly, I don't see it > myself. > > > > So, I beg for some other opinions on this! > > > > TIA, > > Mike > [cut] > > > > ========================================================================= > > Ce message et toutes les pieces jointes sont propriete de VALTECH et > susceptibles de contenir des informations confidentielles a > l'intention > exclusive de ses destinataires. Si vous avez recu ce message par > erreur > ou si celui ci vous est parvenu incomplet ou altere, merci d'en > avertir > l'expediteur par retour.Toute utilisation, diffusion ou publication > non > expressement autorisee par nous par ecrit est strictement interdite. > > -------------------------------------------------------------------------- > > This message and any attachments are Valtech property and may contain > > iconfidential information intended solely for the addressees. If your > are > not the intended recipient of this message or if you have received it > > uncomplete or altered, please notify the author by replying to his > e-mail > immediately. Any unauthorised use, diffusion or dissemination not > expressly authorised by us in writing is strictly prohibited. > ========================================================================= > > Copyright Valtech 2002 > > > __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.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".
