Рассматривая множество веб-приложений в стиле MVC, я замечаю, что очень часто очень большой сервисный интерфейс находится перед бизнес-уровнем. Реализация этого интерфейса обычно включает в себя несколько DAO. Итак, у вас есть что-то вроде:
public class FoodServiceImpl implements FoodService {
private FruitDAO fruitDAO;
private VegetableDAO vegetableDAO;
private MeatDAO meatDAO;
// ... DAO injection stuff
public List<Meat> getMeat() {
return meatDAO.getMeat();
}
public void addMeat(Meat meat) {
meatDAO.add(meat);
}
public List<Fruit> getFruit() {
return fruitDAO.getFruit();
}
// ... tons of methods that mostly just delegate to DAOs
}
Если предположить, что ваши DAO изначально не конкретны, почему бы просто не открыть DAO на следующий уровень?
Так что вместо:
// assume foodService is injected at runtime
public void controllerMethod() {
foodService.getFruit();
foodService.getMeat();
}
У вас просто есть
// assume DAOs are injected at runtime
public void controllerMethod() {
fruitDAO.getFruit();
meatDAO.getMeat();
}
С одной стороны, выглядит неплохо, чтобы все функции приложения были объединены в одном интерфейсе ... с другой стороны, вы можете получить гигантский интерфейс, реализация которого не более чем делегирует DAO .
Я вижу, что приятно управлять всеми DAO в одном месте. Я также могу себе представить, что этот шаблон будет полезен, если одни и те же DAO будут использоваться через несколько служб.
Считается ли это "наилучшей практикой" при запуске веб-приложения или применяется только тогда, когда ожидается определенный уровень и тип сложности?