On Fri, 26 Jun 2015, Marcos Douglas wrote:
On Fri, Jun 26, 2015 at 10:06 AM, Michael Van Canneyt
<[email protected]> wrote:
On Fri, 26 Jun 2015, Marcos Douglas wrote:
Things start to get messy when you start thinking about functionality.
So that comes next, and the business classes reflect functionality, and
consequently more susceptible to change.
Luckily the persistence layers I use are flexible enough to allow any
mapping between data and business objects,
so the above approach has always worked for me.
I'm tempted to say that working the other way round is bound to lead to
confusion.
Confusion... That depends if you work using a data-driven design or
behavior-driven design.
Always data. Data exists on itself. Behaviour never exists on itself.
The moon is there, whether you look at it or not.
So, you use the data-driven design and nothing is wrong with it... but
behavior-driven design is another approach to resolve problems too.
Sure.
I was just commenting on why I personally think data-driven design is more
"correct" than behaviour.
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
