Business Objects - Containers or functional?
Posted
by
Walter
on Programmers
See other posts from Programmers
or by Walter
Published on 2010-10-06T09:39:57Z
Indexed on
2012/11/14
23:18 UTC
Read the original article
Hit count: 491
business-logic
|business-rules
This is a question I asked a while back on SO, but it may get discussed better here...
Where I work, we've gone back and forth on this subject a number of times and are looking for a sanity check. Here's the question: Should Business Objects be data containers (more like DTOs) or should they also contain logic that can perform some functionality on that object.
Example - Take a customer object, it probably contains some common properties (Name, Id, etc), should that customer object also include functions (Save, Calc, etc.)?
One line of reasoning says separate the object from the functionality (single responsibility principal) and put the functionality in a Business Logic layer or object.
The other line of reasoning says, no, if I have a customer object I just want to call Customer.Save and be done with it. Why do I need to know about another class to save a customer if I'm consuming the object?
Our last two projects have had the objects separated from the functionality, but the debate has been raised again on a new project.
Which makes more sense and why??
© Programmers or respective owner