Подход к сервису и уровню dao в игровой инфраструктуре уменьшит основные функции игры?

Question

Я разрабатываю веб-приложение с использованием play framework 2.4.x, и я следил за уровнем уровня обслуживания и уровня DAO после контроллера. Оказывает ли этот подход какие-либо проблемы с основной функцией игры, такой как асинхронный и пул потоков и другие? Я наткнулся на множество примеров приложений, вызывающих соединения db от самого контроллера.

Могу ли я использовать вышеуказанный подход или нет?

Answer 1

Я использую DAO и т. Д., Без проблем. Убедитесь, что вы используете фьючерсы!

Например, не метод DAO, как List<Foo> findAll() - вместо этого, есть F.Promise<List<Foo>> findAll()

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

public class MyExecutionProvider implements Supplier<ExecutionContext> { 
    public ExecutionContext get() { 
     return HttpExecution.defaultContext(); 
    } 
} 

с необходимой привязкой, зарегистрированной для каркаса DI.

В результате DAO будет выглядеть что-то вроде

@Singleton 
public class FooDao { 

    private final Supplier<ExecutionContext> ec; 

    @Inject 
    public FooDao(final Supplier<ExecutionContext> ec) { 
     this.ec = ec; 
    } 

    public F.Promise<List<Foo>> findAll() { 
     return F.Promise.promise(() -> // some database call, 
           ec.get()); 
    } 
} 

Контроллер с помощью этого DAO затем можно использовать типичный асинхронный подход.

public class FooController extends Controller { 
    private final FooDao fooDao; 

    @Inject 
    public FooController(final FooDao fooDao) { 
     this.fooDao = fooDao; 
    } 

    public F.Promise<Result> getAll() { 
     return fooDao.findAll() 
        .map(Json::toJson) 
        .(Results::ok) 
    } 
} 

Настроить для Scala, использовать интерфейсы, предпочтительную архитектуру и т. Д. По мере необходимости.