Re: P-EAA, .NET + Domain Model
From: Peter O'Connell (no_at_spam.please)
Date: 10/21/03
- Previous message: Uncle Bob (Robert C. Martin): "Re: Abstract Method w/o Factory"
- In reply to: Martin Fowler: "Re: P-EAA, .NET + Domain Model"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 21 Oct 2003 01:52:33 -0400
"Martin Fowler" <fowler@acm.org> wrote in message
news:3f9080d8$1@news.totallyobjects.com...
> > Now the way I see it, and correct me if I am wrong, the front end
> > should talk to a segment of the service layer to retrieve data to be
> > displayed. Now ado.net/asp.net allows datasets to be bound directly
> > to the user interface components which although is very nice doesn't
> > seem to fit my model.
> >
> > I want the business layer to return objects not datasets. The only
> > time The way I see it I should expose ADO is in my database layer and
> > data mapper. It does't feel write also allowing passing of ado.net
> > recordsets through the system to the presentation layer - they should
> > be seperated.
>
> Your thinking seems correct. If you're going to use a domain model, then
> I don't then you shouldn't be passing datasets from the domain model out
> to the UI. In the architectural design style of domain model / data
> mapper, the datasets would only be seen by the data mapper, not by the
> domain model let alone anything further up the layering.
>
> There may be an argument for creating new data sets to send up to the UI
> to take advantage of VS's nice controls - I haven't yet come across
> anyone who has done that.
>
> --
> Martin Fowler
> http://martinfowler.com
>
The only argument I have seen in favor of recreating datasets is in the
original post -- .Net makes it easy to bind them to GUI elements.
Fortunately, this argument is moot because .Net makes it just as easy to
bind to your own domain objects. Try creating an Arraylist filled with a few
of your favorite objects and binding the Arraylist to a Datagrid.
The arguments against allowing ADO out of the data layer are much stronger:
1) Connections - A datareader must maintain an open connection while it is
in use, so you can't let that anywhere near the UI.
2) Performance. A Dataset solves the connectivity issue but it is basically
a bunch of collections of generic objects and metadata. Filling your own
objects from the datareader will be at least as fast. (domainObj
<--DataMapper-->Datareader works very well)
3) Dependencies. Past upgrades of ADO have not been fully backwards
compatible. My goal is to completely encapsulate all ADO specifics in a
single class or assemble to guard against this.
Mark-- I am working through a similar exercise to that described in your
original post and can only say that you should read very carefully one of
the several times where Mr. Fowler encourages you to acquire an O/R mapping
tool rather than building your own. If you ignore that one piece of advice,
you had better be prepared to use every other trick in the PofEAA book.
Peter O'Connell
- Previous message: Uncle Bob (Robert C. Martin): "Re: Abstract Method w/o Factory"
- In reply to: Martin Fowler: "Re: P-EAA, .NET + Domain Model"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
