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

IT>

IT>(from o in db.Orders where ... select o).
IT>Update(o => new Order
IT>{
IT>    Delayed  = true,
IT>    Discount = o.Discount + Consts.DelayDiscountRate
IT>});
IT>

Хм. А какова семантика? Ты предлагаешь делать разбор Expr и выделять присваивания свойствам?
Просто приведенный тобой new Order потеряет всю информацию о Customer, Manager, Region и так далее — в нём же будут проинициализированы только свойства Delayed и Discount.

IT>Во взрослом языке конструкция Update может быть встроена в синтаксис и сделана семантически правильной.
Это понятно. Осталось понять, как эта конструкция должна работать для не-SQL случаев.

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

L>Не получится.
L>Например, есть страница Customer. Не ней отображаются не только текущий Customer, но и всякие зависящие от него Location-ы, Department-ы, Person-ы и прочее. Как минимум кроме CustomerInfo придется заводить и *Info для всех остальны сущностей.
Зачем? Нужно заводить 1 (одну) сущность CustomerViewModel, в которой лежат не только текущий Customer, но и всякие зависящие от него Location-ы, Department-ы, Person-ы и прочее.
Большинство из них представлено в виде либо скаляров, либо коллекций скаляров, либо cловарей скаляров. Потому что полные объекты в ней нафиг не нужны.

L>А если учесть, что многие сущности выводятся на более чем одной странице и зачастую выводятся разные поля, то становится совсем весело.
Не вижу особенного веселья.

L>Эти плодящиеся CustomerInfo и есть он.
Конкретнее. Много места занимает декларация класса с автопропертями?

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

L>Ну так покажи как правильно. Вот входные данные:
L>Customer { ID, Name, Field1, Field2, Field3, [Audit Fields] },
L>Department { ID, CustomerID, Name, Address, Field1, Field2, Field3, [Audit Fields] }
L>Location { ID, CustomerID, Name, Address, Field1, Field2, Field3, [Audit Fields] }
L>Person { ID, DepartmentID, FirstName, LastName, Field1, Field2, Field3, [Audit Fields] }

L>На странице Customer-а нужно отображать информацию о кастомере (все поля за исключением аудит-полей) и его Department-ы (ID, Name, Address, Field1, кол-во Person), Location-ы (ID, Name, Address, Field2), Person-ы его Department-ов (ID, FirstName, LastName, Field3).
И всё это — на одной странице? Покажи скриншот.

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

A>>Я в своих рассуждениях ссылался минимум на 4 типа программ для систем с весьма разными бизнес-процессами, но ты видимо слишком неопытен чтобы это понять.
G>Можешь ссылаться хоть на 8 типов. Все равно они все сводятся к одному сценарию. А те которые не сводятся ты искусственно пытаешься свести к такому сценарию.

Вот это и есть твоя неопытность Для тебя вся торговля это ларёк, хотя только дисрибьюторы могут работать по трём кранйе различным схемам. А ещё есть магазины, сети магазинов, рестораны, гостиницы...

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

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

A>>>Я в своих рассуждениях ссылался минимум на 4 типа программ для систем с весьма разными бизнес-процессами, но ты видимо слишком неопытен чтобы это понять.
G>>Можешь ссылаться хоть на 8 типов. Все равно они все сводятся к одному сценарию. А те которые не сводятся ты искусственно пытаешься свести к такому сценарию.

A>Вот это и есть твоя неопытность Для тебя вся торговля это ларёк, хотя только дисрибьюторы могут работать по трём кранйе различным схемам. А ещё есть магазины, сети магазинов, рестораны, гостиницы...
Вау, круто.
А есть еще интернет-магазины, как для них твое кешрование работать будет?
Как там будет определяться адкеватное время устаревани кеша?

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

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

A>>>Я в своих рассуждениях ссылался минимум на 4 типа программ для систем с весьма разными бизнес-процессами, но ты видимо слишком неопытен чтобы это понять.
G>>Можешь ссылаться хоть на 8 типов. Все равно они все сводятся к одному сценарию. А те которые не сводятся ты искусственно пытаешься свести к такому сценарию.

A>Вот это и есть твоя неопытность Для тебя вся торговля это ларёк, хотя только дисрибьюторы могут работать по трём кранйе различным схемам. А ещё есть магазины, сети магазинов, рестораны, гостиницы...

Кстати. В каком из вариантов толстый клиент с удаленным сервреом при нестабиьном канале?
В ресторахнах, гостиница, магазинах связь с сервером есть всегда (lan, wifi), там рулят тонкие клиенты.

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

IT>>

IT>>(from o in db.Orders where ... select o).
IT>>Update(o => new Order
IT>>{
IT>>    Delayed  = true,
IT>>    Discount = o.Discount + Consts.DelayDiscountRate
IT>>});
IT>>

S>Хм. А какова семантика? Ты предлагаешь делать разбор Expr и выделять присваивания свойствам?
S>Просто приведенный тобой new Order потеряет всю информацию о Customer, Manager, Region и так далее — в нём же будут проинициализированы только свойства Delayed и Discount.

Приведённая конструкция разбирается элементарно, т.к. однозначно преобразуется в ExpressionType.MemberInit, которая в свою очередь раскладывается на Member и Assignment.Expression. Проще не придумаешь. Мы получаем Member, которому нужно что-то присвоить (SET Field = ) и выражение ( = Expression), которое может содержать как поля из UPDATE Table, так и из FROM AnotherTable. 'o' в данном примере можно расширить до двух параметров, один из которых будет соответствовать обновляемой записи, а другой результату предыдущего в цепочке запроса.

IT>>Во взрослом языке конструкция Update может быть встроена в синтаксис и сделана семантически правильной.
S>Это понятно. Осталось понять, как эта конструкция должна работать для не-SQL случаев.

Вопрос хороший, но меня в контексте linq 2 DB он мало интересует.

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

A>>Вот это и есть твоя неопытность Для тебя вся торговля это ларёк, хотя только дисрибьюторы могут работать по трём кранйе различным схемам. А ещё есть магазины, сети магазинов, рестораны, гостиницы...
G>Кстати. В каком из вариантов толстый клиент с удаленным сервреом при нестабиьном канале?
G>В ресторахнах, гостиница, магазинах связь с сервером есть всегда (lan, wifi), там рулят тонкие клиенты.

Я же говорю, что ты не опытный

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

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

A>>>Вот это и есть твоя неопытность Для тебя вся торговля это ларёк, хотя только дисрибьюторы могут работать по трём кранйе различным схемам. А ещё есть магазины, сети магазинов, рестораны, гостиницы...
G>>Кстати. В каком из вариантов толстый клиент с удаленным сервреом при нестабиьном канале?
G>>В ресторахнах, гостиница, магазинах связь с сервером есть всегда (lan, wifi), там рулят тонкие клиенты.

A>Я же говорю, что ты не опытный

Словами не кидайся. Высказывай свою точку зрения.

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

S>Здравствуйте, VladD2, Вы писали:
VD>>Набор, порядок следования, смещения, области видимости и имена полей.
S>Зачем имена полей?

Чтобы нельзя было по ошибке сравнить теплое с мягким.
В прочем — это можно контролировать на уровне языка.

VD>>2. Объекты должны быть помечены специальным атрибутом содержащим Guid.
S>Наверное, классы?

Да, конечно.

VD>>Это у CLR есть проблема в поддержке этих языков. И уж одно это является его недостатком.
S>Ну, теперь уже поздно отказываться от поддержки этих языков. Нужно какое-то другое решение этой проблемы.

Зачем другое? На мой взгляд разумно выполнить обещания и сделать CLR пригодным для хостинга любых языков. Шаги в этом направлении уже сделаны. Тот же DLR, например.

VD>>Ну, дык и гнат его из MVP.
S>Тогда много кого гнать придется.

Ну, дык не проблема. Остальные будут больше ценить данное им звание, и будут суетиться.

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

A>>Я же говорю, что ты не опытный
G>Словами не кидайся. Высказывай свою точку зрения.

Моя точка зрения — ты неопытный

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

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

A>>>Я же говорю, что ты не опытный
G>>Словами не кидайся. Высказывай свою точку зрения.

A>Моя точка зрения — ты неопытный
Ну не надо сливать так откровенно.

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

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

A>>>>Я же говорю, что ты не опытный
G>>>Словами не кидайся. Высказывай свою точку зрения.
A>>Моя точка зрения — ты неопытный
G>Ну не надо сливать так откровенно.
G>Может хоть одно доказательство своих слов в этой теме приведешь? А то все "может быть", "в некоторых случаях", "моя точка зрения".

Дистрибьюторы:

Клиент присылает заказ в виде файла в экселе.
Постоянная связь с сервером, тонкий клиент.

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

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

Магазины/Рестораны/Гостиницы:

Один.
Постоянная связь с сервером, тонкий клиент.

Сеть.
Периодическая связь с сервером, толстый клиент, двусторонняя синхронизация.

Системы безопасности и контроля доступа:

Не распределённые.
Периодическая связь с сервером, тонкий клиент.

Распределённые.
Периодическая связь с сервером, толстый клиент, двусторонняя синхронизация.

Список можно продолжать...

В общем понятно, что большой бизнес (распределённые географически сети) это всегда периодическая связь с сервером, потому что такова жизнь, толстый клиент и реплика БД, так как надо полноценно работать в офлайне.

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

L>>Ну так покажи как правильно. Вот входные данные:
L>>Customer { ID, Name, Field1, Field2, Field3, [Audit Fields] },
L>>Department { ID, CustomerID, Name, Address, Field1, Field2, Field3, [Audit Fields] }
L>>Location { ID, CustomerID, Name, Address, Field1, Field2, Field3, [Audit Fields] }
L>>Person { ID, DepartmentID, FirstName, LastName, Field1, Field2, Field3, [Audit Fields] }

L>>На странице Customer-а нужно отображать информацию о кастомере (все поля за исключением аудит-полей) и его Department-ы (ID, Name, Address, Field1, кол-во Person), Location-ы (ID, Name, Address, Field2), Person-ы его Department-ов (ID, FirstName, LastName, Field3).
G>Если списки похожи, то я бы для Department_ов, Location_ов и Person_ов сделал бы одну структуру отображения

Какую?

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

L>>Например, есть страница Customer. Не ней отображаются не только текущий Customer, но и всякие зависящие от него Location-ы, Department-ы, Person-ы и прочее. Как минимум кроме CustomerInfo придется заводить и *Info для всех остальны сущностей.
S>Зачем? Нужно заводить 1 (одну) сущность CustomerViewModel, в которой лежат не только текущий Customer, но и всякие зависящие от него Location-ы, Department-ы, Person-ы и прочее.
S>Большинство из них представлено в виде либо скаляров, либо коллекций скаляров, либо cловарей скаляров. Потому что полные объекты в ней нафиг не нужны.

А можно подробнее, как у CustomerViewModel будет выглядет свойство Locations? Уж не List<Dictionary<string, object>> ли?

L>>А если учесть, что многие сущности выводятся на более чем одной странице и зачастую выводятся разные поля, то становится совсем весело.
S>Не вижу особенного веселья.

Я тоже, потому и смайлик был неулыбающимся.

L>>Эти плодящиеся CustomerInfo и есть он.
S>Конкретнее. Много места занимает декларация класса с автопропертями?
Проблема не в том, что они занимают место, а в том, что их становится много.

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

L>>Customer { ID, Name, Field1, Field2, Field3, [Audit Fields] },
L>>Department { ID, CustomerID, Name, Address, Field1, Field2, Field3, [Audit Fields] }
L>>Location { ID, CustomerID, Name, Address, Field1, Field2, Field3, [Audit Fields] }
L>>Person { ID, DepartmentID, FirstName, LastName, Field1, Field2, Field3, [Audit Fields] }

L>>На странице Customer-а нужно отображать информацию о кастомере (все поля за исключением аудит-полей) и его Department-ы (ID, Name, Address, Field1, кол-во Person), Location-ы (ID, Name, Address, Field2), Person-ы его Department-ов (ID, FirstName, LastName, Field3).
S>И всё это — на одной странице? Покажи скриншот.

Да, на одной. Но скриншот не покажу.

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

A>Магазины/Рестораны/Гостиницы:
A>

Один.
A>Постоянная связь с сервером, тонкий клиент.
A>

Сеть.
A>Периодическая связь с сервером, толстый клиент, двусторонняя синхронизация.
В сети в каждом магазине свой сервак. Между серверами и центром — репликация.

A>Системы безопасности и контроля доступа:
Это что за зверь такой?

A>

Не распределённые.
A>Периодическая связь с сервером, тонкий клиент.
Тонкий клиент при периодической связи? Знатное издевательство над пользователями.

A>

Распределённые.
A>Периодическая связь с сервером, толстый клиент, двусторонняя синхронизация.

Вообще плавный переход от кеша к синхронизации мне нравится.
Исходный посыл был что нельзя сделать "кеш", который на самом деле локальная реплика, без создания графа объектов.
Только синхронизацию (репликацию данных) можно сделать вообще без объектов.


A>Список можно продолжать...
Ага, давай продолжим.
Остались "мелочи":
Документооборот,
Учетные системы (бухгалтерия, склад),
ERP,
CRM,
B2B системы,
электронная коммерция

A>В общем понятно, что большой бизнес (распределённые географически сети) это всегда периодическая связь с сервером, потому что такова жизнь, толстый клиент и реплика БД, так как надо полноценно работать в офлайне.
Бред, в "большом бизнесе" интернет есть в кажом офисе.

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

A>>Периодическая связь с сервером, толстый клиент, двусторонняя синхронизация.
G>В сети в каждом магазине свой сервак. Между серверами и центром — репликация.

В сети в каждом магазине клиент back-office, и сервер front-office. Вотбщем, ты не в курсе, что меня не удивляет.

A>>Системы безопасности и контроля доступа:
G>Это что за зверь такой?

Карты на проходной, отпечатки пальцев.

A>>Периодическая связь с сервером, тонкий клиент.
G>Тонкий клиент при периодической связи? Знатное издевательство над пользователями.

При нераспределённой системе (одно здание или несколько зданий рядом) отказ сети не лишает тонкий клиент функциональности, а преводит его в аварийный режим с минимальнйо функциональностью.

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

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

G>Только синхронизацию (репликацию данных) можно сделать вообще без объектов.

Удивлю, всё можно делать без объектов. Вопрос в том, какой ценой.

G>Остались "мелочи":
G>Документооборот,
G>Учетные системы (бухгалтерия, склад),
G>ERP,
G>CRM,
G>B2B системы,
G>электронная коммерция

Какая интересная классификация, бухгалтерия и склад вне ERP. Я уже понял, что ты со всем этим дела не имел, не надо мне это ещё раз доказывать.

A>>В общем понятно, что большой бизнес (распределённые географически сети) это всегда периодическая связь с сервером, потому что такова жизнь, толстый клиент и реплика БД, так как надо полноценно работать в офлайне.
G>Бред, в "большом бизнесе" интернет есть в кажом офисе.

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

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

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

A>>>Периодическая связь с сервером, толстый клиент, двусторонняя синхронизация.
G>>В сети в каждом магазине свой сервак. Между серверами и центром — репликация.

A>В сети в каждом магазине клиент back-office, и сервер front-office. Вотбщем, ты не в курсе, что меня не удивляет.
Я видел в магазине один сервер, который через веб-сервисы общался с центральным.


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

Интресно, а как же кешироване в HTTP работает? Причем работает в разы лучше любой схемы с локальной репликой и синхронизацией, которую ты можешь придумать.

G>>Только синхронизацию (репликацию данных) можно сделать вообще без объектов.
A>Удивлю, всё можно делать без объектов. Вопрос в том, какой ценой.
Ну если совсем без объектов, то цена очень низкая: merge replication в самой СУБД, или Sync Services в .NET.


G>>Остались "мелочи":
G>>Документооборот,
G>>Учетные системы (бухгалтерия, склад),
G>>ERP,
G>>CRM,
G>>B2B системы,
G>>электронная коммерция

A>Какая интересная классификация, бухгалтерия и склад вне ERP. Я уже понял, что ты со всем этим дела не имел, не надо мне это ещё раз доказывать.
Этор не классификация, а примеры.
Я как раз со всем этим дело имел.

A>>>В общем понятно, что большой бизнес (распределённые географически сети) это всегда периодическая связь с сервером, потому что такова жизнь, толстый клиент и реплика БД, так как надо полноценно работать в офлайне.
G>>Бред, в "большом бизнесе" интернет есть в кажом офисе.
A>Большой бизнес делается не только в офисе, это раз, и не может полагаться на работоспособность интернета, это два.
А где же еще делается "большой бизнес" ? И почему не может полагаться на работоспособность инета?
Интернет — самая надежная сеть на сегодняшний момент.

Здравствуйте, Lloyd, Вы писали:
L>А можно подробнее, как у CustomerViewModel будет выглядет свойство Locations? Уж не List<Dictionary<string, object>> ли?
Скорее всего — Dictionary<Guid, string>. Потому что очень вряд ли на одной странице нужны ОО-детали от Location. Вот когда они понадобятся для конкретного Location, вот тогда и затащишь туда нужный по месту LocationInfo.