Well, I have a similar class called DetachableEntityModel (Entity is
an interface we devised to mark something as a persistent entity):
public class DetachableEntityModel<T extends Entity> extends
LoadableDetachableModel<T>
{
private Repository<T> repository;
private String id;
public DetachableEntityModel(Repository<T> repository, String id)
{
this.repository = repository;
this.id = id;
}
public T load()
{
return repository.getById(id);
}
}
This way, my model isn't tied to the ORM implementation at all. I
just code to the Repository interface which can be implemented using
any ORM technology you like (Hibernate, JPA, iBATIS, etc.). I
understand that most folks aren't as "religious" as me about this, but
I have learned that when I go away from my "best practices" my code
becomes more difficult to unit test (I still stray from time to time,
though :).
On Thu, May 8, 2008 at 10:16 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> im not that religious about this. i dont like to pass daos around or
> have to look them up, not when i am using a central persistence tech
> like hibernate/jpa. so i think of my entitymodel as a repository for a
> single object :) you can give it the object or the class and id and it
> knows how to load it. the need to create a loadable detachable model
> for a persistent object is way too common to neglect such a
> convenience. entitymodel encapsulates the lookup so nothing leaks, but
> thats just me :)
>
> -igor
>
>
> On Thu, May 8, 2008 at 5:14 PM, James Carman <[EMAIL PROTECTED]> wrote:
>> I typically don't like to have my UI code directly interact with the
>> ORM implementation (hibernate in this case). For my applications, I
>> pass a Repository (think DAO) object and the object's id into the
>> LoadableDetachableModel.
>>
>>
>>
>> On Thu, May 8, 2008 at 6:33 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>> > you can pass in the id if you want, i prefer to work with objects...so
>> >
>> > class entitymodel extends ldm {
>> > private final String cn;
>> > private final Serialializable id;
>> >
>> > public entitymodel(class cl, serializable id) { cn=cl.getName();
>> this.id=id; }
>> > public entitymodel(identifiable entity) {
>> > cn=hibernateutils.unproxy(entity).getclass().getname();
>> > id=entity.getid(); }
>> > public object load() { session.get(class.forname(cn), id); }
>> > }
>> >
>> > this is just more convinient, obviously identifiable is an interface
>> > we use here internally.
>> >
>> > -igor
>> >
>> >
>> >
>> >
>> > On Thu, May 8, 2008 at 3:10 PM, Mathias P.W Nilsson
>> > <[EMAIL PROTECTED]> wrote:
>> > >
>> > > Thanks Igor!
>> > >
>> > > So if I use the sample code you gave me and, when getting the Object
>> from
>> > > the constructor
>> > > on the response page I will have a detached object.
>> > >
>> > > Do I have to load the object from database here? When looking at the
>> Phone
>> > > book example I see you pass id instead of object. Is this more
>> lightweight
>> > > or is it better practice to just pass the id and not the whole object?
>> > >
>> > >
>> > > --
>> > > View this message in context:
>> http://www.nabble.com/Detached-models-tp17136199p17137533.html
>> > >
>> > >
>> > > Sent from the Wicket - User mailing list archive at Nabble.com.
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
