Daniel wrote:
> > - Stateful Peers. In many cases the all-static Peers are
> just fine and very
> > convenient. However in quite a few cases stateful
> (instance) Peers would be
> > of great help. Probably the most common case is
> per-usersession Peers which
> > would keep link back to session info which would allow them
> to automatically
> > apply some filters ( such as only selecting current user's
> info or info for
> > the date of interest) instead of having this code
> duplicated all over the
> > application code. As both stateful and stateless Peers have
> their area of
> > application it seems that it makes sense to make this a
> generation option.
>
> I would very much like to see Peers move from all static methods to an
> instanc model. There should also be an easy way to get the same
> instance each time for cases where instances aren't actually
> necessary.
<code>
public static final XxxPeer instance = new XxxxPeer();
</code>
should do it.
The side effect of making Peers instances is that all those inheritance
tricks are no longer required.
>
> > - Move Peer's functionality into OM objects themselves. It
> makes fewer
> > classes and removes some duplication and seems to be
> overall more elegant. I
> > do not see any good arguement against this although I am
> not really sure
> > about this one. just a thought...
>
> I'm not too sure about this one.
it's just a wild thought.
It just appears to me that mapping object and peer share a lot and should
merge beautifully.
>
> > - better typing & exceptions. For example I would prefer
> doSelect to return
> > List rather than Vector. And for example a method doSelectDistinct
> > (doSelectUnique?) returning a Set and so forth. Also
> methods like one
> > returning Hashtable with PKs as keys and full objects as
> values would often
> > be handy... As to exceptions having all methods throw
> Exception is highly
> > annoying. A good exception hierarchy would be great.
>
> +1 to List over Vector (for the umpteenth time!). I think you've got
> some good typing ideas here, Mr. TypeSafe. Let's not go overboard on
> the exceptions, though. If you really want to add more, they should
> all subclass a common base class so those of us who aren't interested
> in specific exception types can easily ignore them when desired.
I said "hierarchy" :-)
Also "good" != "big"
fedor.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
