2015-07-01 4 views
1

Так недавно началось новое веб-приложение, которое будет использовать Play 2.4. Я использую JPA для многих проектов, но я решил дать Ebean на этот раз.Play 2.4: Как разделить проблемы с Ebean?

Однако мне интересно, как разделить проблемы. В JPA я обычно создавал модели, службы и DAO для сохранения. С Ebean я понимаю, что есть поддержка статических методов на моделях (см. http://ebean-orm.github.io/quickstart «Создать модель»).

Я видел немало примеров, где все, кажется, входит в эти статические методы, сидящие в моделях; бизнес-логика, логика настойчивости, а что нет. Является ли это лучшей практикой при использовании Ebean, которую я должен просто принять? Или все же имеет смысл отделить логику с помощью сервисов и DAO, и кто бы я мог сделать это наилучшим образом?

ответ

3

Вы можете делать вещи, точно так, как вы делали с JPA, а также создавать объекты DAO и т.д.

Если проверить статические методы в Ebean примеров, вы увидите, что они обычно используют Finder. Для таблицы Country, чей первичный ключ является Stringiso2, вы бы класс модели, как это:

@Entity 
public class Country extends Model { 
    @Id 
    public String iso2; 

    // other stuff 
} 

В качестве примера Ebean ActiveRecord стиле кода, будет какая-то дополнительные вещи.

@Entity 
public class Country extends Model { 

    private static final Finder<String, Country> FIND = new Finder<>(String.class, Country.class); 

    @Id 
    public String iso2; 

    public static List<Country> findAll() { 
     return FIND.all(); 
    } 

    // other stuff 
} 

Если вы хотите изменить это подход DAO-стиле, вам просто нужно, чтобы переместить Finder код из информации о связанных из Country.

public class CountryDao { 
    private static final Model.Finder<String, Country> FIND = new Model.Finder<>(String.class, Country.class); 

    // not static if you don't want it to be 
    public List<Country> findAll() { 
     return FIND.all(); 
    } 
} 

Какой подход вы используете становится на территорию мнение, но DAO подход имеет много, чтобы рекомендовать его, особенно теперь Play поддерживает DI из коробки. Вместо того, чтобы иметь контроллер, который делает жестко закодированные ссылки на классы моделей, вы можете просто ввести свои DAO.

// direct reference to the Country class 
public class ControllerWithActiveRecord extends Controller { 
    public F.Promise<Result> getAllCountries() { 
     return F.Promise.promise(() -> Country.findAll()) 
         .map(Json::toJson) 
         .map(Results::ok); 
    } 
} 

Альтернативный вариант использования DI.

public class ControllerWithInjectedDAO extends Controller { 

    private final CountryDAO countryDAO; 

    @Inject 
    public ControllerWithInjectedDAO(final CountryDAO countryDAO) { 
     this.countryDAO = countryDAO; 
    } 

    public F.Promise<Result> getAllCountries() { 
     return F.Promise.promise(() -> countryDAO.findAll()) 
         .map(Json::toJson) 
         .map(Results::ok); 
    } 
} 
+1

Спасибо, что очень помогает! Прямо в этот момент я на самом деле смотрю на некоторые классы в базе кода примера для проверки подлинности воспроизведения, которая выглядит так, как вы писали в 2012 году :-) – Daniel

+0

Если вы проверите последний код Deadbolt, он обновлен для Play 2.4. Игра сильно изменилась с 2012 года! –

+0

Спасибо, я буду! Я больше смотрю на код, чтобы попытаться понять, как реализовать аутентификацию воспроизведения, к сожалению, документация не такая полная, как, например, Безопасный социальный. – Daniel

Смежные вопросы