RE: Separation of Objects from Logic 2004-12-10 - By Tim Weaver
I've done both. At one point I spent a considerable amount of time
comparing various metrics (lines of code/impact of changes, etc)
between both. What I found was that having "smart" domain object
actually created a lot less code and a lot less churn.
Martin Fowler has a rant about this on his wiki: Anemic Domain Model
is what he calls it. He isn't really a fan of #2 though he does
recognize that that there are situations where it is called for.
I think it is dangerous to make a blanket statement that one is better
than the other. In many situations I agree completely with Martin's
view. However, there are a lot of times when having a dumb container
is a requirement and there are well known patterns for dealing with
these types of objects.
We use a mix of both.
Datasets... we try to avoid like the plague.
On Thu, 9 Dec 2004 23:56:05 -0000, Phil Winstanley <phil@(protected)> wrote:
> Hello,
>
> I'm having a discussion with a colleague of mine at the moment about the
> benefits of differing architectures, specifically two different
> architectures: -
>
> 1. Where each object is responsible for loading and saving it's data so has
> both methods and properties. Intelligent objects one might say.
>
> I want to go in what I see as both the pros and cons for each, so here goes
>
> Advantages
>
> a) No need for a separate business logic layer.
> b) Logic for managing objects is always at hand as one of the methods of the
> object.
> c) Bindable.
>
> Disadvantages
>
> a) The methods are always there even when they're not used.
> b) ... erm ?
>
> 2. Where each object is just a class with properties, light weight, but
> completely dumb. All logic is performed through a separate Business Logic
> Layer.
>
> Advantages
>
> a) No tight coupling with the business logic layer, objects can be used
> independently.
> b) Objects serialize happily as they're just made up of simple types,
> string, int & Guid generally.
> c) Light weight and can be moved between layers very easily.
> d) Bindable
> e) It's the wasy Microsoft seem to do things looking at the Provider Models.
>
> Disadvantages
>
> a) The objects have no concept of how they should behave.
> b) You need to know what in the Business Logic layer to use for
> saving/loading your objects with data.
>
> Now, I'm a fan of #2 for the reasons outlined above, but I don't know enough
> about #1 to make an informed choice so would like to hear how others
> approach this.
>
> Datasets are not out of the question though I'd prefer to stay away from
> them and their typed brethren.
>
> What do you guys use and why? What do you think of the above two?
>
> Thanks,
>
> Phil.
>
> Need SQL Advice? http://sqladvice.com
> Need RegEx Advice? http://regexadvice.com
> Need XML Advice? http://xmladvice.com
>
Need SQL Advice? http://sqladvice.com
Need RegEx Advice? http://regexadvice.com
Need XML Advice? http://xmladvice.com
|
|
