RE: Separation of Objects from Logic 2004-12-10 - By Tim Weaver
Datasets have their uses, but for the most part they are too
heavy/slow for our needs. If all you are doing is moving data from the
DB to the UI a dataset is almost always serious overkill. Datasets are
easy to use so they tend (IMO) to get abused.
We create custom business objects/collections to hold our data. The
data is loaded via DataReaders into the custom objects. This approach
is faster/lighter than the Dataset approach. It is more code to write
and maintain, but performance is a critical factor for us.
On Fri, 10 Dec 2004 10:27:50 -0500, Crooks, David L. <dcrooks@(protected)> wrote:
> What is wrong with Datasets? Don't you deal with databases?
>
>
>
> -----Original Message-----
> From: Tim Weaver [mailto:icodemarine@(protected)]
> Sent: Friday, December 10, 2004 9:15 AM
> To: aspnet-architecture@(protected)
> Subject: [aspnet-architecture] RE: Separation of Objects from Logic
>
> 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
|
|
