-Harish
Harish Krishnaswamy wrote:
I totally agree with you on separating the data access service out from the actual business object, in fact this is exactly what I have done previously in one the projects. But I had not separated the business logic and data, instead we had a data transfer object which was primarily an aggregation of the required data for a particular client. But I see your point about scalability, so does the data access service now wrap the data object with the business object when asked for an entity? That actually really sounds cool, 'cuase conceptually it is still one object just physically separated out for scalability and maintenance, am I right?
-Harish
Howard M. Lewis Ship wrote:
What your are describing is pretty close to J2EE dogma.
A service facade (stateless session bean) is a business process concerning Employee.
An additonal service, behind the facade, provides persistancy for Employee objects, i.e., its a Data
Access Object (really, a Data Access Service).
There's nothing inherently wrong with this model, and much that is right.
I've used other systems, including Apple's Enterprise Objects Framework, that merges the Value
object (called an EO, or "Enterprise Object") with its business logic. This is attractive, but
doesn't scale well ... it works out to be nice to seperate the data aspects (the value object and
the data access service) from the business logic, because business logic is much more likely to
change over time ... or even be quite dynamic (for example, driven by a flexible workflow engine).
Once you start thinking about externalizing business logic, it ends up making sense (to me) to
externalize all of it, for consistency.
Good, workable, scalable OO is more about aggregation than about inheritance. Coming out of the
Objective-C/Apple/NeXT world initially, my early work on Tapestry reflects an overuse of inheritance
over aggregation (even today), a mistake I'm not making with HiveMind.
Where HiveMind rocks over J2EE is that it is much, much, much easier to create new services and make
them seemlessly work together.
-- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com
-----Original Message-----
From: Harish Krishnaswamy [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 9:39 PM
To: 'Jakarta Commons Developers List'
Subject: [HiveMind] Basic questions about Service
I am a little confused now. I am confused as to what the boundaries of a service are. Is there even a distinction between a Service and a domain object? I start seeing people actually suck out the behavior of domain objects into services and have the domain object as a simple JavaBeans data object. I literally saw an example that had an Employee object which represented the database table and an EmployeeService which represented the behavior for the Employee object. To me this sounds like its against the principles of OO (assign the responsibility to the information expert). So this leads to a more basic question - what is a Service? I think we need a technical definition for Service. I thought of the Service as an interface to a subsystem / a specific function. Am I missing something?
-Harish
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
