isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: Designing a CRUD Repository interface
Date Sun, 26 Feb 2012 12:55:37 GMT
On 24 February 2012 19:29, Vineet Reynolds <vineet.reynolds@gmail.com>wrote:

> Hi,
>    I've been using Apache Isis for quite some time now, and I'm hugely
> impressed with some of the work in this framework.
>
Hi Vineet,

Welcome to the isis-dev mailing list.  I'm cc'ing this reply to isis-users,
because I think it's more of a user issue than a contributors issue.



>    I have a problem in designing my Repository interfaces, and I'd like
> some advice on how I ought to be addressing it. The problem in general is
> that my repositories for the default object store, implement interfaces
> that are similar to the CrudRepository interface in Spring-JPA (1). The
> CrudRepository has a method of signature "T save(T entity)", which is
> responsible for creating new persistent instances. My repositories
> implement a similar method, like the following:
>
> @Named("Chart of Accounts")
> public class AccountRepositoryDefault extends AbstractFactoryAndRepository
> implements AccountRepository
> {
>
>    // {{ Create new (already persisted) Account
>    @Override
>    public Account newAccount(Account newAccount)
>    {
>        Account account = newTransientInstance(Account.**class);
>        copyProperties(newAccount, account); // Hack. Copy properties from
> the argument to the transient instance.
>        persist(account);
>        return account;
>    }
>    // }}
>
>
>   ... other methods
>
> }
>
> When I attempt to perform this action (of saving/creating a new entity)
> exposed by the repository, both in the default Swing viewer as well as the
> HTML viewer, I'm presented with a dialog requesting an input of an already
> created instance of <T>, i.e. Account in this case. While this behavior of
> the Isis viewers is understandable, this is quite contrary to my
> expectation that I would be presented with a dialog listing all the enabled
> properties of an Account that would allow for creation of a new instance on
> the fly.
>

It sounds instead as though you need to break this down into two.

The first step is that you want a representation of a transient Account
domain object: this would be the "dialog" that you are referring to.  You
could do this using:

@Named("Chart of Accounts")
public class AccountRepositoryDefault extends AbstractFactoryAndRepository
implements AccountRepository
{
    // {{ Return a (still transient) Account
    public Account newAccount() {
        return newTransientInstance(Account.class);
    }
    ...
}

The viewers should render this as you expect; because the object is still
transient, it should have a 'save' button.

The viewers will then automatically call getContainer().persist(theAccount)
for you.

If you don't like this approach, an alternative is to define your own save
action on the Account class.  You could then simply call
getContainer().persist:

public class Account extends AbstractDomainObject {

    public void save() {
        getContainer().persist(this);
    }
    // don't show the save action for persisted objects.
    public boolean hideSave() {
        return getContainer().isPersistent(this);
    }

   ...
}


or, if you want to follow the Spring-style CRUD repository pattern a little
more closely, then you could delegate off to an injected AccountRepository:

public class Account extends AbstractDomainObject {

    public void save() {
        accountRepository.save(this);
    }
    public boolean hideSave() {
        return getContainer().isPersistent(this);
    }

   ...
}


where:

public class AccountRepositoryDefault extends AbstractFactoryAndRepository
implements AccountRepository {

    @Hidden  // only intended to be called programmatically.
    public void save(Account transientAccount) {
        getContainer().save
    }
}

Does that make sense?



>
> To explain my predicament further, I am attempting to use the domain model
> constructed with Isis, in a Java EE 6 app


As a separate thread, I'd like to explore this further; I'll reply on
isis-dev for that one since it's more contributor focused.



> Thanks,
> Vineet
>

Cheers
Dan



>
> Links:
> 1. https://github.com/**SpringSource/spring-data-**
> commons/blob/master/spring-**data-commons-core/src/main/**
> java/org/springframework/data/**repository/CrudRepository.java<https://github.com/SpringSource/spring-data-commons/blob/master/spring-data-commons-core/src/main/java/org/springframework/data/repository/CrudRepository.java>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message