Здравствуйте, IT, Вы писали:

ANS>>Связи между объектностью модели и типизируемостью нету.

IT> А что по твоему есть типизируемость в C#?

По твоему объектаная модель может быть только в C#?


IT>тебе домашнее задание — найти связь между типизацией и объектной моделью

нельзя найти то, чего нет

ORM появились появились еще в Smalltalk, где проверка типизированности данных не требование. А появился потому, что из ОО программы удобнее работать с "объектной формой" чем с реляционными данными. Т.е. конвертация данных в объектную модель — цель существования ORM.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>По твоему объектаная модель может быть только в C#?

Ты о чём? Посмотри на название темы.

IT>>тебе домашнее задание — найти связь между типизацией и объектной моделью

ANS>нельзя найти то, чего нет

Или то, чего в упор не хочешь видеть. Или видишь, но очень хочется поспорить и единственный шанс — это свести всё к терминологической грызне.

ANS>ORM появились появились еще в Smalltalk, где проверка типизированности данных не требование. А появился потому, что из ОО программы удобнее работать с "объектной формой" чем с реляционными данными. Т.е. конвертация данных в объектную модель — цель существования ORM.

Всё когда-то появилось. Лямбды появились ещё в лиспе, а в мэйнстрим попали только сегодня. Не прошло и 50-ти лет. У современных ORM, которые узурпировали этот термин в сегодняшнем его понимании, довольно незатейливая история развития, которой пока ещё не более 10 лет. Не важно когда впервые появился этот термин, главное что им теперь обзывают. На самом деле ORM вообще сегодня не отражает полностью суть того, чего им именуют. А ты тут про Smalltalk вспоминаешь

Здравствуйте, Aikin, Вы писали:

C>>Кстати, он ещё и противоречит принципу, что методы класс должны заниматься только тем, что требует доступа к его приватным данным.
A>1) Каким это образом? Тем, что он не запрещает?
Таким. Метод Object.AddItem — избыточен, если есть публичная коллекция Object.Items.

A>2) Что это за принцип-то такой? Не мог бы ты полнее его озвучить?
Да очень простой принцип, неоднократно обсуждали в форуме по архитектуре. См.: http://www.martinfowler.com/bliki/AnemicDomainModel.html (правда, Фаулер считает это антипаттерном).

Здравствуйте, Aikin, Вы писали:

A>Cyberax, я его превел не в контексте спора, а сам по себе. Очень правильный закон ограничивающий связность системы. Не стоит о нем забывать.
Чем правильный? Да ещё и хватило наглости назвать это "законом".

A>В частности закон деметры запрещает проектировать классы с вложенными коллекциями в виде: order.Items.Add(newItem) предлагая в замен order.AddItem(newItem).
Вот это и есть неправильно.

A>P.S. Тем более никаким образом он не ограничивает запросы из двух таблиц
Ограничивает. Так как join двух таблиц — тоже нарушение принципа Деметры.

И вообще, можешь показать мне как будет выглядеть "деметрированый" метод, который будет переводить студента в группу к другому студенту?

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Полей — может и ерунда. А отсутсвие необходимости декларировать используемые сущности приводит к тому, что невозможно понять какому куску кода какие данные нужны и когда они будут загружены. Значит нельзя вычленить кусок кода которому для работы доступ к БД не нужен. Это приводит к принципиальной немногопоточности.
То что ты рассказывал как у вас там всё работает — это чистый антипаттерн использования Hibernate. У каждого потока должна быть своя сессия со своим графом объектов, иначе будем натыкаться на сплошные проблемы.

Здравствуйте, <Аноним>, Вы писали:

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

А>поэтому продолжайте господа, вас приятно слушать!

+1.

Все равно мы все понимаем, что каждой технологии свое место .

Кстати, приятно отметить, что это-таки не священные войны, а вполне аргументированная дискуссия (нуу, на 70%).

Так что, продолжайте, господа! Мы очень внимательно вас слушаем.

Здравствуйте, Cyberax, Вы писали:

ANS>> А отсутсвие необходимости декларировать используемые сущности приводит к тому, что невозможно понять какому куску кода какие данные нужны и когда они будут загружены. Значит нельзя вычленить кусок кода которому для работы доступ к БД не нужен.
C>У каждого потока должна быть своя сессия со своим графом объектов, иначе будем натыкаться на сплошные проблемы.
Каким образом создание отдельной сессии на поток позволит разобраться, кода какие данные нужны и когда они будут загружены?

Здравствуйте, Cyberax, Вы писали:

C>Таким. Метод Object.AddItem — избыточен, если есть публичная коллекция Object.Items.
Ну, скажем, если эта коллкеция выставлена наружу, как readonly, то не избыточен...

C> См.: http://www.martinfowler.com/bliki/AnemicDomainModel.html
Ну, не совсем, это все-таки более общий принцип и имеет отношение не только к данным. Фаулер сосредоточился на частном случае, причем как-то совсем не убедительно.

C> (правда, Фаулер считает это антипаттерном).
Это исключительно проблемы Фаулера. =)

Здравствуйте, IB, Вы писали:

C>>Таким. Метод Object.AddItem — избыточен, если есть публичная коллекция Object.Items.
IB>Ну, скажем, если эта коллкеция выставлена наружу, как readonly, то не избыточен...
Ну да. Но по моему опыту — тогда просто получаем нагромождение простых методов типа AddItem/RemoveItem/RemoveAllItems, не дающих чего-либо особого.

C>> См.: http://www.martinfowler.com/bliki/AnemicDomainModel.html
IB>Ну, не совсем, это все-таки более общий принцип и имеет отношение не только к данным. Фаулер сосредоточился на частном случае, причем как-то совсем не убедительно.
C>> (правда, Фаулер считает это антипаттерном).
IB>Это исключительно проблемы Фаулера. =)
Ну да, тут совершенно согласен.

Здравствуйте, IB, Вы писали:

C>>У каждого потока должна быть своя сессия со своим графом объектов, иначе будем натыкаться на сплошные проблемы.
IB>Каким образом создание отдельной сессии на поток позволит разобраться, кода какие данные нужны и когда они будут загружены?
У товарища ANS проблема в том, что граф объектов одновременно обходится из нескольких потоков. При этом попытки сделать lazy-loading сразу из двух потоков вызывают недоумение со стороны Hibernate.

Если бы каждый поток работал со своими личными объектами — такой проблемы не было бы.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS> ORM появились появились еще в Smalltalk, где проверка типизированности данных не требование.
А динамическая типизация, за типизацию уже не катит?

ANS> А появился потому, что из ОО программы удобнее работать с "объектной формой" чем с реляционными данными.
Это заблуждение, к сожалению довольно популярное. Корни его, на самом деле, проистекают из другого, еще более популярного заблуждения — интуитивно-ошибочной интерпретации понятия "ОО программа".

ANS> Т.е. конвертация данных в объектную модель — цель существования ORM.
Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.

Здравствуйте, IB, Вы писали:

ANS>> Т.е. конвертация данных в объектную модель — цель существования ORM.
IB>Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.
Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.

Здравствуйте, Cyberax, Вы писали:

IB>>Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.
C>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.

Это не более, чем слова, т.к. альтернативы RDB пока не существует. В отличии от ORM.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, IB, Вы писали:

C>У товарища ANS проблема в том, что граф объектов одновременно обходится из нескольких потоков.
Это-то понятно. Тем не менее, вопрос был задан совершенно четко — что делать с тем, что непонятно, когда какие данные нужны и когда они будут загружены?
Собственно, это порождает целый ворох проблем, как с производительностью, так и с поддержкой кода...

C>Если бы каждый поток работал со своими личными объектами — такой проблемы не было бы.
Стоп — стоп. Это я что, вынужден в прикладном коде разруливать с какой сессией какой поток работает?!! Афигеть удобство.

Здравствуйте, IB, Вы писали:

C>>У товарища ANS проблема в том, что граф объектов одновременно обходится из нескольких потоков.
IB>Это-то понятно. Тем не менее, вопрос был задан совершенно четко — что делать с тем, что непонятно, когда какие данные нужны и когда они будут загружены?
Использовать ленивую загрузку.

C>>Если бы каждый поток работал со своими личными объектами — такой проблемы не было бы.
IB>Стоп — стоп. Это я что, вынужден в прикладном коде разруливать с какой сессией какой поток работает?!! Афигеть удобство.
А так ведь всё равно придётся, хоть ты с напрямую в сетевой провод биты насвистывай. Так как множество wire-протоколов баз данных — не threadsafe и не параллельные. Ну и JDBC-драйверы, соответственно, тоже не-threadsafe.

Здравствуйте, IT, Вы писали:

C>>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.
IT>Это не более, чем слова, т.к. альтернативы RDB пока не существует. В отличии от ORM.
Существуют: разные OODB, для мелких БД — Prevayler.

Здравствуйте, Cyberax, Вы писали:

C>>>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.
IT>>Это не более, чем слова, т.к. альтернативы RDB пока не существует. В отличии от ORM.
C>Существуют: разные OODB, для мелких БД — Prevayler.

То что они существуют совершенно не означает, что это альтернатива.

Здравствуйте, IT, Вы писали:

C>>Существуют: разные OODB, для мелких БД — Prevayler.
IT>То что они существуют совершенно не означает, что это альтернатива.
RDB сейчас выигрывают только за счёт удобных инструментов и навороченности самих баз. Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.

Просто так получилось.

Здравствуйте, Cyberax, Вы писали:

C>>>Существуют: разные OODB, для мелких БД — Prevayler.
IT>>То что они существуют совершенно не означает, что это альтернатива.
C>RDB сейчас выигрывают только за счёт удобных инструментов и навороченности самих баз. Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.

Ты знаешь чем теория отличается от практики?

C>Просто так получилось.

Да хоть как. Главное, что альтернативы RDB сегодня нет.

Здравствуйте, IT, Вы писали:

C>>RDB сейчас выигрывают только за счёт удобных инструментов и навороченности самих баз. Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.
IT>Ты знаешь чем теория отличается от практики?
Тем что в теории не отличается

C>>Просто так получилось.
IT>Да хоть как. Главное, что альтернативы RDB сегодня нет.
Я лично сделал пару мелких проектов на db4o. Всё без особых проблем работает, инструменты удовлетворительны. Так что альтернативы есть, если посмотреть.

Для больших проектов пока просто боюсь использовать.