Hehe, you bring up an interesting point.

GoF is indisputably OO. But the problem with OO is that it is large, and
varied and full of conflicting opinions and ideas.

My focus in the book is very much on constructing objects that not only
model the entities in the problem domain, but also model their
relationships. However, there's nothing stopping someone from using the
same basic concepts to only model the entities, leaving the relationship
modelling for workflow/process/controller code - which might also be in
'objects'.

Of course objectively, the workflow/process/controller code tends to be
pretty procedural or linear, so then you can get into religious
arguments about the nature of a 'true' object and so forth... A great
way to spend (waste?) a lot of time :)

There's no doubt that there is good value in MVC, workflow or business
fa=E7ade style architecture - but they all rely on underlying data. My
primary contention is that the data should never be 'raw' or
unintelligent (such as you'd find in a DataSet or XML document). The
data should be intelligent - wrapped by business logic - which to me
means that the data should be contained within business objects.

The more logic you can put into the business objects, the less chance
you have of someone misusing the data at some point later.

Of course, as Kevin pointed out, if you tightly couple the objects to
model the problem domain itself rather than just the entities, then you
run the risk of making the object model more fragile.

So it is a tradeoff between this type of fragility and the decreased
consistency (and thus maintainability) you get when you pull business
logic (such as relationship information) out of the objects and put that
logic into some other location (such as the UI, a workflow object, etc).

No easy answers...

Rocky


> -----Original Message-----
> From: Anton van der Merwe [mailto:antonvdmerwe@h...]
> Sent: Thursday, February 27, 2003 3:04 PM
> To: expert_vb_business_objects
> Subject: [expert_vb_business_objects] RE: Workflow/Business
> Process Objects
>
>
> Thanks very much Rocky and Kevin for your comments.  I
> basically wanted to
> know if you recommend one or more approach in your CSLA.NET
> book, and if
> not, what your personal comments were on this subject.
>
> I agree, there isn't just one solution that fits all, it needs to be
> handled on a case-by-case basis.  Most arguments agree that
> you should use
> the pure OO approach (and I agree).  The problem with that is
> just that it
> means different things to different people, e.g. MVC is based on GoF
> design patterns, which should surely be considered to be pure OO.
>
> Something that I like to add to whichever OO approach you consider
> appropriate for the different types of applications, or types
> of functions
> inside an application, is the importance of Encapsulation -
> As long as you
> do not duplicate logic, and try to keep it in one place, and
> the place
> that makes most sense, then you will be fine. With the first
> option always
> to keep it inside the BO. Hope you agree...?
>
> Thanks again Rocky for the time and effort you put in to
> repsond so quick
> to any comments and questions, appreciated a lot, looking
> forward to the
> book!
>