Fedor Karpelevitch <[EMAIL PROTECTED]> writes:
> I'd like to ignite a little discussion on the future of Peer system. Here
> are some ideas which have beed brewing in my mind lately. Some depend on
> each other, some are mutually exclusive:
>
> - New Query Model (whatever that is). It's a long overdue..
Yes, save us!
> - 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.
> - 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.
> - 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.
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
