Невозможно выбрать между Hibernate и iBatis только с этой информацией. Количество объектов здесь не важно (на самом деле мой подход окупается больше, если объектов много). Более уместна сложность графов объектов, которыми манипулируют в ваших сервисных методах, необходимость обнаружения «грязных» дочерних объектов и т. Д. IBatis более легкий / простой / низкоуровневый, чем Hibernate / JPA, и это всегда имеет свои преимущества ( легче понять и поддерживать; меньше сюрпризов или таинственных ошибок) и недостатков (требуется больше программного кода, меньше мощности и возможностей, которые трудно реализовать в сложных случаях использования)

я есть очень простой объектный граф, который я хочу сохранить в базе данных, используя MyBatis. Если я создаю новый граф объектов (BatisNode с двумя деталями), как мне написать код, чтобы убедиться, что дочерние объекты созданы? Вот подробности:


public class BatisNode {
    protected int id;
    protected List details;
    protected String name;
        //Constructor and getters.
}

public class BatisNodeDetail {
    protected int id;
    protected BatisNode parent;
    protected String name;
        //Constructor and getters.
}

Схема:

CREATE TABLE node (
    node_id int auto_increment primary key,
    name varchar(255)
);

CREATE TABLE node_detail(
    node_detail_id int auto_increment primary key,
    name varchar(255)
);

Mapper:

    
        
INSERT INTO node (
  name
)
SELECT #{name};
        

        
SELECT node_id id,
name
FROM node
WHERE node_id=#{id};
        

        
        


Ответы на вопрос(1)

а просто DataMapper, и эта простота / ограничения особенно четко проявляются в этих сценариях (графе объектов): он (в основном) не знает о графе объектов.

Один подход, который я выбрал, заключается в следующем:

У меня есть:

слой легких объектов POJO («объекты DTO»), каждый из которых соответствует таблице базы данных (один объект <-> одна запись таблицы БД), у них немного больше свойств (как в ваших примерах BatisNode и BatisNodeDetail)

уровень DAO, один объект службы для каждого DTO (скажем, BatisNodeDAO и BatisNodeDetailDAO) с внедренным источником данных, и стандартные методы insert / loadById / delete и select (iBator могу помочь тебе здесь)

уровень обслуживания, помимо наличия типичных классов обслуживания (обычно одиночных), определяет также некоторые тяжеловесные объекты («доменные объекты»), с которыми они имеют дело, и которые обычно соответствуют графу объектов DTO (в вашем примере, BatisNodeWithDetails ). Эти доменные объекты знают, как загрузить / сохранить граф обернутых DTO, вызывая DAO (и заботясь о транзакциях, обнаружении «грязных» объектов и т. Д.). Обратите внимание, что может быть несколько «классов доменов», которые заключают в себе один и тот же DTO (то есть разные графы), для разных методов обслуживания или вариантов использования.

 leonbloy25 янв. 2011 г., 15:45
Невозможно выбрать между Hibernate и iBatis только с этой информацией. Количество объектов здесь не важно (на самом деле мой подход окупается больше, если объектов много). Более уместна сложность графов объектов, которыми манипулируют в ваших сервисных методах, необходимость обнаружения «грязных» дочерних объектов и т. Д. IBatis более легкий / простой / низкоуровневый, чем Hibernate / JPA, и это всегда имеет свои преимущества ( легче понять и поддерживать; меньше сюрпризов или таинственных ошибок) и недостатков (требуется больше программного кода, меньше мощности и возможностей, которые трудно реализовать в сложных случаях использования)
 User125 янв. 2011 г., 15:25
Спасибо за совет. Это мой первый батис-проект. Это звучит как довольно много работы для двух объектов .. У меня есть больше в реальной жизни. Будет ли спящий режим лучшим выбором здесь?

Ваш ответ на вопрос