The original design of the IDataProvider is essentially assuming the separation of concepts. It has the 2 methods iterator () and model (). This methods have different responsibilities. The generefication is breaking the design. Why in this case you wouldn't create the model for me automatically since you already have an object...
On Wed, Apr 23, 2008 at 11:50 AM, Jan Kriesten <[EMAIL PROTECTED]> wrote: > > hi sebastiaan, > > > > > Hmm.... I seriously doubt that 1 round trip for the entire object is > noticeably slower than 1 round trip for the PK's, even if you need to do > some joins (assuming of course that you have proper indexes etc). > > > > that might be - no question. > > but the programming model i have is somewhat simpler this way. to get into > details, i have the following implementation of an IDataProvider: > > class FilterDataProvider[T <: AnyRef]( dao: IFilterDao[T], defaultSort: > String, idLoader: Int => Option[T] ) > extends SortableDataProvider > with IFilterStateLocator > with IColumnVisibleState > > which encapsulates the handling of pk-lists and gets a dao and a loader > function. > > > > > Furthermore, the performance penalty for objects NOT in de database is > extremely large in your case (1 extra db round trip per object)! > > > > well - based on that the id's come from the database that shouldn't happen > - and if an id shouldn't exist any more, than this way at least it's made > sure that no wrong data is shown any more. > > best regards, --- jan. > > >
