Re: design question

• Previous message: Universe: "Re: Re: OO Design, Physical Implementation, DAOs"
• In reply to: Peter O'Connell: "Re: design question"
• Next in thread: H. S. Lahman: "Re: design question"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: 24 Oct 2004 23:26:25 -0700

"Peter O'Connell" <poconnell@NoSpam_worksonmymachine.com> wrote in message news:<1Wyed.38322$bk1.17034@fed1read05>...
> "oj" <oaguayo75@yahoo.com> wrote in message
> news:aba00e68.0410230903.dfd942@posting.google.com...
>
> >> Rather than passing an Employee to the Inbox, consider passing something
> >> like a DocumentFilter, or DocumentFilterCollection. The Employee class
> >> can
> >> build and return appropriate filter(s). This allows the Inbox to focus on
> >> getting the right documents according to any criteria without any
> >> knowledge
> >> of the Employee class. Since you already require at least three different
> >> sets of criteria, you might as well support an arbitrary number. What are
> >> the odds that VPs will want a filter of their own?
> >
> > Thanks for your reply.
> >
> > That makes sense. This way I can pass a document filter from a Program
> > object as well without the Inbox having to know anything about a
> > Program class.
>
> Exactly.
>
> >Now I am trying to determine if I even want the Inbox
> > to have any knowledge about the Document class.
>
> Probably not. (see below)
>
> >I need to pull a list
> > of documents into the Inbox and filter the collection but I'm not sure
> > the collection needs to be made up of Document objects. It seems like
> > a lot of overhead to just put together what is in a sense a pick list.
>
> You asked a similar question elswhere and the answer depends on what you
> mean by overhead as well as the specific objects. If you are referring to
> development overhead - there is none because you need the full object to
> display/edit its details in other parts of the app. Performance overhead
> depends on the specific objects. In your case, consider a DocumentSummary
> class or an InboxItem class. How much lighter would these be than your
> Document class? If they "save" a few strings or numerics you should probably
> just use the full class. If there is a huge data field or large heirarchy
> contained in your document a lightwieght summary class may be better. A
> "Lazy Loading" strategy can also be useful in these cases -- but the code
> can get complicated in a hurry.
>
> > Would it make more sense to make the Inbox a collection of dataRows
> > that can be filtered according the DocumentFilter criteria and
> > displayed to the GUI once filtered? This way I would avoid
> > instatiating an instance of a Document class until a user selected one
> > to work with from the list in their Inbox.
>
> <Disclaimer>
> I have a long standing bias against using Microsoft's data technologies
> anywhere near my Presentation or Domain logic -- so any time I see words
> like "dataRows" I hear warning bells.
> </Disclaimer>
>
> Your Inbox should be (or contain) a collection of InboxItem objects. Maybe
> InboxItem is a small class of its own, maybe it is an interface implemented
> by your Document class. I would start with an IInboxItem interface and make
> sure this was the only way items were referenced by the Inbox. I would then
> make the Document class implement IInboxItem and run some performance tests.
> If there is a performance problem, you can create an optimized
> DocumentSummary/InboxItem that also implements IInboxItem -- Your Inbox is
> already built to handle this.
> This approach might take more code than using a generic dataset - but it
> will perform better and is "more OO".

Thanks for your reply.

OJ

• Previous message: Universe: "Re: Re: OO Design, Physical Implementation, DAOs"
• In reply to: Peter O'Connell: "Re: design question"
• Next in thread: H. S. Lahman: "Re: design question"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]