Модель DAO по сравнению с ORM (спящий режим)

Ответ 1

ORM и DAO являются ортогональными понятиями. Один из них связан с тем, как объекты сопоставляются с таблицами базы данных, а другой - шаблон проектирования для записи объектов, которые обращаются к данным. Вы не выбираете между ними. Вы можете иметь ORM и DAO - это одно и то же приложение, так же как вам не нужно ORM для использования шаблона DAO.

Тем не менее, пока вам действительно ничего не нужно, вы должны использовать DAO. Шаблон поддается модульному коду. Вы сохраняете всю свою логику настойчивости в одном месте (разделение проблем, борьба с аблациями). Вы позволяете себе проверять доступ к данным отдельно от остальной части приложения. И вы позволяете себе тестировать остальную часть приложения, изолированную от доступа к данным (т.е. Вы можете издеваться над своими DAO).

Плюс, после шаблона DAO легко, даже если реализация доступа к данным может быть затруднена. Так что это очень мало (или ничего), и вы получаете много.

РЕДАКТИРОВАТЬ - Что касается вашего примера, ваш метод входа должен быть в виде AuthenticationService. Вы можете обрабатывать исключения там (в методе входа). Если вы использовали Spring, он мог бы управлять множеством вещей для вас: (1) транзакции, (2) инъекции зависимостей. Вам не нужно будет писать свои собственные транзакции или фабрики dao, вы можете просто определить границы транзакций вокруг своих методов обслуживания и определить свои реализации DAO как beans, а затем подключить их к вашей службе.

EDIT2

Основная причина использования шаблона - разделить проблемы. Это означает, что весь ваш код настойчивости находится в одном месте. Побочным эффектом этого является тестируемость и ремонтопригодность, а также тот факт, что это облегчает замену реализации позже. Если вы создаете DAO для Hibernate, вы можете абсолютно управлять сеансом в DAO, это то, что вы должны делать. Анти-шаблон - это когда код, связанный с сохранением, происходит за пределами уровня персистентности (закон абсорбированных абстракций).

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

Но обратите внимание, что транзакции могут быть независимыми от вашей реализации - вам нужны транзакции независимо от того, используете ли вы спящий режим. Также обратите внимание, что вам не нужно использовать механизм транзакций спящего режима - вы можете использовать транзакции на основе контейнеров, транзакции JTA и т.д.

Без сомнения, если вы не используете Spring или что-то подобное, транзакции будут больно. Я настоятельно рекомендую использовать Spring для управления вашими транзакциями или спецификацию EJB, где я считаю, что вы можете определять транзакции вокруг своих сервисов с помощью аннотаций.

Ознакомьтесь со следующими ссылками для транзакций на основе контейнеров.

Операции, управляемые контейнером

Сессии и транзакции

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

Другая (менее элегантная) альтернатива заключается в том, чтобы положить все атомные единицы работы в DAO. У вас могут быть CRUD DAO для простых операций, а затем более сложные DAO, которые выполняют более одной операции CRUD. Таким образом, ваши программные транзакции остаются в DAO, и ваши службы будут обращаться к более сложным DAO, и вам не придется беспокоиться о транзакциях.

Следующая ссылка является хорошим примером того, как шаблон DAO может помочь вам упростить код

Рисунок AO против ORM (hibernate)

(thanx @daff)

Обратите внимание, как определение interace делает это так, чтобы ваша бизнес-логика заботилась только о поведении UserDao. Это не волнует реализацию. Вы можете написать DAO, используя спящий режим, или просто jdbc. Таким образом, вы можете изменить реализацию доступа к данным, не затрагивая остальную часть вашей программы.

Ответ 2

Позвольте мне представить пример исходного кода для хорошего ответа hvgotcodes:

public class Application
{
    private UserDao userDao;

    public Application(UserDao dao)
    {
        // Get the actual implementation
        // e.g. through dependency injection
        this.userDao = dao;
    }

    public void login()
    {
        // No matter from where
        User = userDao.findByUsername("Dummy");
    }
}


public interface UserDao
{
    User findByUsername(String name);
}

public class HibernateUserDao implements UserDao
{
    public User findByUsername(String name)
    {
        // Do some Hibernate specific stuff
        this.session.createQuery...
    }
}

public class SqlUserDao implements UserDao
{
    public User findByUsername(String name)
    {
        String query = "SELECT * FROM users WHERE name = '" + name + "'";
        // Execute SQL query and do mapping to the object
    }
}

public class LdapUserDao implements UserDao
{
    public User findByUsername(String name)
    {
        // Get this from LDAP directory
    }
}

public class NoSqlUserDao implements UserDao
{
    public User findByUsername(String name)
    {
        // Do something with e.g. couchdb
        ViewResults resultAdHoc = db.adhoc("function (doc) { if (doc.name=='" + name + "') { return doc; }}");
        // Map the result document to user
    }
}

Итак, как уже упоминалось, DAO представляет собой шаблон проектирования для минимизации сцепления между вашей заявкой и вашим бэкэндом, тогда как ORM имеет дело с тем, как отображать объекты в объектно-реляционную базу данных (что уменьшает связь между базы данных и вашего приложения, но, в конце концов, без использования DAO ваше приложение будет зависеть от используемого ORM или более высокого уровня стандарт, такой как JPA).

Поэтому без DAO было бы очень сложно изменить ваше приложение (например, переходить в базу данных NoSQL вместо JPM-совместимой ORM).

Ответ 3

Нет, я не думаю, что это правильно. ORM - один из способов реализации DAO; вы можете выбрать DAO без ORM.

У вас есть это в обратном направлении: я бы подумал, что ORM будет тяжелее DAO, потому что зависимости больше. Я могу написать DAO в прямом JDBC без ORM. Это легче, ИМО.

Согласны или нет, зависит от того, как мы определяем "свет" и "тяжелый". Я перехожу к зависимостям - количество дополнительных JAR, требуемых над самим JDK.