Добпый вечер
Никто с данным зверем но имени XPO дела не имел?

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

Это про eXpress persistent objects?
Что хотелось бы узнать?

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

А>Здравствуйте, NetStyler, Вы писали:
А>Это про eXpress persistent objects?
А>Что хотелось бы узнать?
Как через Remoting XPCollection перетаскивать? Ибо после обращения выд\летает со страшным эксепшином.

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

NS>Здравствуйте, <Аноним>, Вы писали:
NS>Как через Remoting XPCollection перетаскивать? Ибо после обращения выд\летает со страшным эксепшином.

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

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

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

странно, т.е.
1) создаём на сервере сессию
2) передаём ещё по ссылке на клиент
3) на клиенте создаём коллекшн с нужными критериями отбора, он вызывает обьект сессии на сервере, он (этот обьект сессии) выполняет запросы к базе, создаёт список наших сущностей, формирует коллекцию.
Всё правильно?
Но ведь сущности тоже MarshalByRefObject, получается коллекции полюбому за ними на сервер мотаться

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

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

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

D>странно, т.е.
D>1) создаём на сервере сессию
D>2) передаём ещё по ссылке на клиент
D>3) на клиенте создаём коллекшн с нужными критериями отбора, он вызывает обьект сессии на сервере, он (этот обьект сессии) выполняет запросы к базе, создаёт список наших сущностей, формирует коллекцию.
D>Всё правильно?
D>Но ведь сущности тоже MarshalByRefObject, получается коллекции полюбому за ними на сервер мотаться

Да, все верно но такой сценарий не приемлем по производительности. Таким образом, единственным нормальным вариантом использования может быть создание и сессии и коллекции только на клиентской стороне и ремоутным коннешеном к базе (что не очень хорошо по секурити).
В версии 2.0 будет вынесеный DAL, который можно будеть создавать удаленно и работать только через него, навешав желаемое секурити.
Session — это по сути кеш объектов плюс методы выборки, так что создание ее удаленно имеет мало практической ценности.

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

А>Да, все верно но такой сценарий не приемлем по производительности. Таким образом, единственным нормальным вариантом использования может быть создание и сессии и коллекции только на клиентской стороне и ремоутным коннешеном к базе (что не очень хорошо по секурити).
А>В версии 2.0 будет вынесеный DAL, который можно будеть создавать удаленно и работать только через него, навешав желаемое секурити.
А>Session — это по сути кеш объектов плюс методы выборки, так что создание ее удаленно имеет мало практической ценности.

спасибо за рабьяснение
только не понятно, что собственно для сервера остаётся
У меня ещё вопрос небольшой.
В коллекшене можно указать поля, которые она будет предоставлять для биндинга и можно указывать поля вложенных сущностей, но только 1 уровня, т.е.
//пусть сущность — заказ
Num, Date, Customer.Name, Supplier.Name, OrderItems // список
Соответственно, биндим к гриду, и навигейтимся по ссылке OrderItems — список содежимого заказа. Но отображение полей вложенного списка мы настроить не можем! Т.е. пусть OrderItem содержит вложенную сущность Product, тогда ни в коллекции, ни в гриде мы не сможем указать, что нам надо показывать Product.Name, будет вызываться Product.ToString(). Его конечно можно переопределить, но только один раз, а хотелось бы явно выбирать поля. Как поступаете вы?

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

D>только не понятно, что собственно для сервера остаётся
Только сокрытие коннекшенов к базе и управление ими, плюс секурити если надо

D>У меня ещё вопрос небольшой.
D>В коллекшене можно указать поля, которые она будет предоставлять для биндинга и можно указывать поля вложенных сущностей, но только 1 уровня, т.е.
D>//пусть сущность — заказ
D>Num, Date, Customer.Name, Supplier.Name, OrderItems // список
D>Соответственно, биндим к гриду, и навигейтимся по ссылке OrderItems — список содежимого заказа. Но отображение полей вложенного списка мы настроить не можем! Т.е. пусть OrderItem содержит вложенную сущность Product, тогда ни в коллекции, ни в гриде мы не сможем указать, что нам надо показывать Product.Name, будет вызываться Product.ToString(). Его конечно можно переопределить, но только один раз, а хотелось бы явно выбирать поля. Как поступаете вы?

Соображения:
1) Список полей у датасоурса определяется через интерфейс ITypedList. Выбрать сразу все дерево возможных полей не реально из-за его потенциальной бесконечности. У PropertyDescriptorCollection есть метод Find дернув который можно добавить соответствующее поле. К сожалению не все гриды дергают этот метод для получения ProprtyDescriptor если им явно задали имя поля.
Теоретически можно повесится на какой-нибудь евент источника и дергать Find, но намой взгляд сие очень гимороидально.
2) У колеккции есть проперти DisplayblePropersies для задания списка доступных полей. Можно на геттере коллекшн свойства его присваивать, конечно, идея связывания бизнес-логики и гуйни никого не радует, но вобщем больше ничего не остаётся.

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

А>Соображения:
А>1) Список полей у датасоурса определяется через интерфейс ITypedList. Выбрать сразу все дерево возможных полей не реально из-за его потенциальной бесконечности. У PropertyDescriptorCollection есть метод Find дернув который можно добавить соответствующее поле. К сожалению не все гриды дергают этот метод для получения ProprtyDescriptor если им явно задали имя поля.
А>Теоретически можно повесится на какой-нибудь евент источника и дергать Find, но намой взгляд сие очень гимороидально.
А>2) У колеккции есть проперти DisplayblePropersies для задания списка доступных полей. Можно на геттере коллекшн свойства его присваивать, конечно, идея связывания бизнес-логики и гуйни никого не радует, но вобщем больше ничего не остаётся.

тнкс, буду пробовать

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

А>В версии 2.0 будет вынесеный DAL

А когда будет версия 2.0?

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

F>А когда будет версия 2.0?

Где-то в декабре-январе