Как соотносятся AX Data Entity и Entity framework?

[mazzy]

Цитата:

Сообщение от Alex_KD

Представь если в AX данный можно изменить только через Data Entity. Клево, а?

Дык, и я про то.
И никаких проблем с RecID, никаких идиотских структур типа DirParty.
Вместо понятия Relations - понятие Принадлежит.
Ляпота. Программистская.

Чего ж реализация то такая странная?

Цитата:

Сообщение от Alex_KD

Повторю еще раз, EF и oData это не одно и тоже. С одной и той же версией EF можно сделать разные oData с разным поведением.

Дык, я и не спорю. Не одно и тоже.
И как раз предлагаю обсудить - а почему собственно?
Какие могут быть рациональные причины для изобретения собственного велосипеда в Аксапте?
Понятно, что "как всегда"... Но вдруг таки можно найти рациональное зерно?

[belugin]

Цитата:

Сообщение от mazzy

Вместо понятия Relations - понятие Принадлежит.
Ляпота. Программистская.

"Пинадлежит" концептуально одно из видов Relations. Просто в аксапте Relations не дотупны их запросов. Нельзя написать.

select PurchaseOrder where exists(PurchaseOrder.markup.Code == 'x') && exists(PurchaseOrder.lines.markup.code == 'x');

Я как программист вообще не хочу задумываться как именно реализовано Relation - естественным ключем, искусственным или еще как-то.

[mazzy]

Цитата:

Сообщение от belugin

"Принадлежит" концептуально одно из видов Relations

все это указатели )
но на практике программисты всевозможными путями пытаются избавиться от указателей в пользу ссылок.

казалось бы - пустая смена терминологии.

но в результате современные программные библиотеки навязывают стиль мышления "содержит", а не "указывает".
объект "содержит" другой объект
объект "принадлежит" другому объекту.
хотя в реальной памяти конечно же работают указатели.

так и relations - это указатели в области баз данных
relations требуют суррогатных ключей.
relations требуют внимания от программиста

если же перейти на уровень "принадлежит", то получим структуры типа xml/json
где никаких суррогатных ключей (указателей) не требуется.

но зато такая абстракция "протекает", если объект может принадлежать нескольким объектам. что в программировании ссылок, что в программировании баз данных.

примерно так.

==========================
поэтому я и считаю, что переход с абстракции relation на следующий уровень абстракции "принадлежит" сильно упрощает программирование в большинстве случаев.

но именно из-за "протекания" абстракции и вводят такое понятие как "бизнес-данные"

[belugin]

Цитата:

Сообщение от mazzy

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

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

Не пустая. У ссылок нет арифметики указателей. У ключей есть такая арифметика - можно сделать recid++ или accountname + 'a'

Цитата:

Сообщение от mazzy

но в результате современные программные библиотеки навязывают стиль мышления "содержит", а не "указывает".
объект "содержит" другой объект
объект "принадлежит" другому объекту.
хотя в реальной памяти конечно же работают указатели

Прочитай семантику uml - "содержит" - лишь один из видов отношений.

Цитата:

Сообщение от mazzy

и relations - это указатели в области баз данных
relations требуют суррогатных ключей.
relations требуют внимания от программиста

Не требуют relation суррогатных ключей - открой морпхикс и простой рилейшен на любых ключах.

Это ключи а не релейшены указатели. Это они требуют внимания программиста. Проблема аккаунты в том, что нельзя в запросах использовать рилейшены аи не ключи.

Цитата:

если же перейти на уровень "принадлежит", то получим структуры типа xml/json
где никаких суррогатных ключей (указателей) не требуется.

Требуется как только надо изобразить что-то сложнее иерархии.

[mazzy]

Цитата:

Сообщение от belugin

Прочитай семантику uml - "содержит" - лишь один из видов отношений.

ну да, ну да... использует, наследует...
но со ссылками почти все превращается в семантику "содержит".

кроме того, мы же находимся в контексте data entity.
а в этом контексте даже навигационные свойства к внешним data entity превращаются в "принадлежит".

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

Цитата:

Сообщение от belugin

Не требуют relation суррогатных ключей - открой морпхикс и простой рилейшен на любых ключах.

да, ты прав. это я неточно сформулировал.

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

в аксапте это DimId, системная номерная серия и прочие
для таких ключей в номерной серии безболезненно можно использовать & вместо # - пользователи этого не заметят.

так вот, data entity полностью устраняют потребность в таких технических ключах.

Цитата:

Сообщение от belugin

Это ключи а не релейшены указатели. Это они требуют внимания программиста. Проблема аккаунты в том, что нельзя в запросах использовать рилейшены аи не ключи.

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

да, сформулировано было коряво.
надо подумать

Цитата:

Сообщение от belugin

Требуется как только надо изобразить что-то сложнее иерархии.

ну да, ну да - "если объект может принадлежать нескольким объектам".
другими словами, граф, содержащий хотя бы один нетривиальный цикл. (не дерево)

[belugin]

Цитата:

Сообщение от mazzy

кроме того, мы же находимся в контексте data entity.
а в этом контексте даже навигационные свойства к внешним data entity превращаются в "принадлежит".

Это как? У энтитей могут быть и другие отношения.

Цитата:

в которых связь технически нужно реализовать, но отражения на реальный мир эта связь не имеет.

Мне это тоже непонятно. Нельзя ли увидеть пример. Как правило у таких таблиц эта связь является отражением чего-то в предметной области (например обобщения). Но при этом платформа не содержит удобного способа работы с такими связями.

Цитата:

такие relation как правило реализуются суррогатными ключами.

в аксапте это DimId, системная номерная серия и прочие
для таких ключей в номерной серии безболезненно можно использовать & вместо # - пользователи этого не заметят.

так вот, data entity полностью устраняют потребность в таких технических relation.

Relation есть в предметной области. Entity для потребителя представляет такой relation как отсутствующий, как я понял. То есть вместо "У строки есть набор аналитик" получается "У строки есть подразделение". А сама группировка некого набора признаков в понятие "набор аналитик" исчезает.

[mazzy]

Цитата:

Сообщение от belugin

Это как? У энтитей могут быть и другие отношения.

какие?

Цитата:

Сообщение от belugin

Мне это тоже непонятно. Нельзя ли увидеть пример. Как правило у таких таблиц эта связь является отражением чего-то в предметной области (например обобщения). Но при этом платформа не содержит удобного способа работы с такими связями.

я ж приводил.
DimId - очень древний пример
DirParty - не очень древний.

Цитата:

Сообщение от belugin

Relation есть в предметной области. Entity для потребителя представляет такой relation как отсутствующий, как я понял. То есть вместо "У строки есть набор аналитик" получается "У строки есть подразделение". А сама группировка некого набора признаков в понятие "набор аналитик" исчезает.

угу.
только стоит отметить, что "исчезает" из логических рассуждений.
исчезает из концептуальной модели.
технически все остается на месте.

[belugin]

Цитата:

Сообщение от mazzy

Какие могут быть рациональные причины для изобретения собственного велосипеда в Аксапте?

Как ORM это vietnam of computer science так и создание бизнесобъектов это Вьетнам Аксапты. В итоге решили вырастить из того, что есть. Инкрементно. Добавить во view возможность обновления данных и постепенно наращивать возможности.

[mazzy]

Цитата:

Сообщение от belugin

Как ORM это vietnam of computer science так и создание бизнесобъектов это Вьетнам Аксапты. В итоге решили вырастить из того, что есть. Инкрементно. Добавить во view возможность обновления данных и постепенно наращивать возможности.

это ты серьезно сейчас?

[belugin]

Цитата:

Сообщение от mazzy

это ты серьезно сейчас?

А похоже на шутку?