Неужели Hibernate настолько тупая технология?

stm2388838

Вот пример из Demo Applications CaveatEmptor (Hibernate2)

		// Users

		u1 = new User("Christian", "Bauer", "turin", "abc123", "hibernate.org");

		u2= new User("Gavin", "King", "gavin", "abc123", "hibernate.org");

		// BillingDetails

		BillingDetails ccOne = new CreditCard("Christian  Bauer", u1, "1234567890",

		                                        CreditCardType.MASTERCARD, "10", "2005");

		BillingDetails accOne = new BankAccount("Christian Bauer", u1, "234234234234",

		                                        "FooBar Rich Bank", "foobar123foobaz");

		u1.addBillingDetails(ccOne);

		u1.addBillingDetails(accOne);

Уже же указали юзера в конструкторе BillingDetails, зачем еще addBillingDetails делать?
Может Hibernate3 это пофиксили? В “Introduction to Hibernate” пример связи многие-ко-многим, я не нашел примера наиболее часто встречающейся связи один-ко-многим.

stm2388838

что никто этим поспорит?

Dasar

Судя по примеру - скорее недоделанная, чем тупая.

Hastya

неужели все пользователи Hibernate настолько тупые?
RTFM.

pitrik2

неужели все пользователи Hibernate настолько тупые?
RTFM.

stm2388838

Судя по примеру - скорее недоделанная, чем тупая.

разработчики считают это недоделкой? и буду фиксить?
даже если это недоделка, она является следствием "object/relational mapping solution for Java"

stm2388838

неужели все пользователи Hibernate настолько тупые?

у пользователей не большой выбор

stm2388838

как вы реализуете связь один-ко-многим? приведите пример

Hastya

stm2388838

и Java код можно?

Hastya

Код тоже очень сложный:



public class Parent {

    private Set children;

    public void setChildren(Set children) {

        this.children = children;

    }

    public Set getChildren {

        return this.children;

    }

}

Dasar

Речь шла про bidirectional-связи и о том, что при такой связи надо руками устанавливать оба конца связи.
Имхо, это, именно, недоделка, но имеющая под собой реальные причины.
http://www.hibernate.org/116.html#A7

I'm having trouble with a bidirectional association.
When you update a bidirectional association you must update both ends.
parent.getChildren.add(child);
child.setParent(parent);

Dasar

> разработчики считают это недоделкой? и буду фиксить?
Скорее всего нет, т.к. есть объективные проблемы мешающие устранению такой недоделки

stm2388838

приведи, пожалуйста, весь код из реального приложения, касающийся одной связи,
как я это сейчас представляю:
1. мэпинг на стороне parent
2. мепинг на стороне child
3. добавить метод Parent.addChild(...)
это как в примерах. С точки зрения согласовоннсти данных, имхо, лучше делать в child-е приватным setParent и сделать в Child метод
public void setParent2(Parent parent) {
parent.getChilds.add(this);
setParent(parent);
}
недостаток только в том, что кривое название метода setParent2

stm2388838

приведенный код, обладает серьезным недостатком, содержимое внутренней коллекции children могут менять пользователи класса

stm2388838

если устранять этот недостаток, то еще надо добавлять один метод, который возвращает неизменяемую коллекцию.
Не много ли кода для одной связи? Архитектор эту связь рисует одной палочкой в Visio, а бедные кодировщики такой хуйней должны страдать. Редизайн будет тоже сложно делать.
P.S. в .NET DataSet-ах многих вышеописанных проблем нет

Hastya

> Не много ли кода для одной связи?
Не много ли кода для поддержания целостности объекта? Нет, не много. Бывает и больше. Только причем тут Hibernate? Он-то как раз ни в чем не ограничивает. Хочешь сделать метод private - сделай.
Почему нужно обновлять оба конца связи? А как ты себе представляет корректную реализацию каскадности, которая будет работать с "разорванным" графом объектов?
С ADO.NET не работал, но если уж там все это есть, почему бы тебе не использовать ADO.NET?

stm2388838

С ADO.NET не работал, но если уж там все это есть, почему бы тебе не использовать ADO.NET?

надо же было самому посмотреть, чтобы было что ответить на выебоны джавистов

но если уж там все это есть

там есть не всё, что есть в Hibernate

stm2388838

Почему нужно обновлять оба конца связи? А как ты себе представляет корректную реализацию каскадности, которая будет работать с "разорванным" графом объектов?

сформулируй более четко то, что ты имеешь ввиду, желательно с кодом. Пока я не вижу проблемы, каскадность обновления указывается отдельными атрибутами в файле мэпинга.

Hastya

В документации пять страниц текста по поводу каскадов, тебе скопировать?

обновления указывается отдельными атрибутами в файле мэпинга

Указывается. Только как ее Hibernate будет отслеживать, если ты потерял одну из ссылок в двунаправленной связи.

stm2388838

если ты потерял одну из ссылок в двунаправленной связи.

за связями должна следить фабрика объектов, а не пользователь объектов. В .NET фабрикак это DataSet. В Hibernate такая фабрика отсутствует, и это очень странно

, поэтому в теме и использовано резкое слово
P.S. каскадном обновлении это второстепенная проблема, хотя возможно и завязана на связи, но потерянные связи сами по себе хреновая ситуация

Dasar

В Hibernate-е нет менеджера связей - потому что он намного сложнее получается.
В DataSet-е такой менеджер есть - потому что DataSet-ы довольно простые: плоские (имеют табличный вид) и создание происходит одномоментно (без создания по требованию).

Hastya

>за связями должна следить фабрика объектов
Объекты никому ничего не должны. Кстати в Hibernate с самого начала отказались от пула объектов, и это сильно упростило жизнь любителей POJO.

stm2388838

создание происходит одномоментно (без создания по требованию).

с менеджером связей подгрузку по требованию было бы реализовать возможно даже проще. В ADO.NET нет подрузки по требованию из-за то, что Microsoft проповедует disconnected модель.

DataSet-ы довольно простые: плоские (имеют табличный вид)

а больше и не надо

Dasar

> а больше и не надо
Как минимум - еще бывают деревья - например, информация о файлах.

stm2388838

Как минимум - еще бывают деревья - например, информация о файлах.

по-моему дерево нормально укладывается в эту схему:
табличка



id(PK

parentId(FK

еще какие-то атрибуты

накладываешь Relation по полям id и parentId, и у тебя есть методы прохода по дереву DataRow.GetChildRows и DataRow.GetParetRow.
А если у Relation-а установить nested, то можно даже XPath пользовать, самому интересно стало, сейчас VS установится, попробую

Dasar

Добавление, удаление, изменения как будут выглядит?
Как будет выглядит - если файлы, например, должны быть в строго определенном порядке?

stm2388838

Добавление, изменения будут выглядит?

выглядят просто

удаление
Как будет выглядит - если файлы, например, должны быть в строго определенном порядке?

к сожалению, Microsoft не предоставила возможности наследования классов, относящихся к Dataset-ам, это и есть один из существенных недостатков DataSet-ов. Для небольших объемов данных есть простое решение, сделать обертки, свой обертку-менеджер над DataSet, и обертку над DataRow.

Оставить комментарий