Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Недавно, иначе кеш не имеет смысла. Причём настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора. G>>Ну, конкретнее, сколько времени оценка будет правильной? A>Я уже написал, ты не удосужился прочесть. "настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора".
Критерий полезности в студию. Работа с деньгами в программе должна быть точной, иначе проблема может быть очень много.
G>>Что делать если в один прекрасный момент появится необходимость это время увеличить в 2 раза? A>А в чём проблема-то? Кеш обновляется не по таймеру.
И как же он обновляется? Вытягиванием changeset с сервера при каждом обращении?
A>>>Это можно сделать только на сервере. G>>Тогда зачем что-то делать на клиенте, если корректный результат возможен только при вычислении на сервере? G>>Ведь все эти кеши, запреты удаления, прочая муть только от того что хочется что-то безопасно делать на клиенте. A>Нет. Запрет удаления с кешем совсем не связан. Ты ничего не понял и решил свалить всё в кучу. В Active Directory, например, объекты удаляются в распределённой системе. И ничего, всё работает. Запрет удаления это не ограничение вызванное использованием кеша, это совершенно отдельная песня.
Ну и чем же запрет удаления вызван? Судя по твоим ответам выше единственная причина для такого поведения — желание работать якобы без потери целостности данных, а это желание как раз возникает из-за работы с локальной репликой там где не надо.
A>Далее. Корректный результат при добавлении данных всегда возможен на сервере. Для некоторых задач он возможен и на клиенте. Кроме того есть отчёты которые можно снимать с кеша (история операций). Кроме того, постоянное соединение с сервером никто не обещал.
Так если постоянного соединения нет, то локальная копия БД и репликация изменений, других вариантов понка не придумали. Решения я уже писал выше.
G>>Или можно просто откзаться от идеи безопасности операций на клиенте, а сразу предполагать что любая операция на клиенте может происходить на уже недействительных данных. A>Не любая, потому что не все данные можно редактировать, но некоторые могут. И, кстати, часто возможность продолжить работу важнее, чем возможность продолжить её корректно. Например, если филиал магазина с двухтысячным ассортиментом отрубился от сети, а в центре обновили цены на три товара, лучше продолжить продавать по старым ценам, а не закрывать филиал.
Угу, опять сведение к разделению данных между пользователями.
Здравствуйте, Sinclair, Вы писали:
S>Читать здесь. Creator/Owner подчеркнуть, или сам найдешь? S>Посмотри также насчет того, что поменяли в висте на эту тему. Аналогичная фигня — дефолтные DACL подправили так, чтобы соответствовать реальным сценариям.
Из твоих ссылок следует, что в Висте перестали использовать CREATOR_OWNER. Это, по-твоему, подтверждает твои слова?
A>>Ну да, до вас прав доступа вообще не было. S>Головой просто думать надо, головой.
Здравствуйте, gandjustas, Вы писали:
G>А самое главное что ты даже толком не можешь сказать зачем тебе локальная реплика, только пытаешься свести все к одному сценарию — "каждый пользователь работает только со своим куском данных".
Это, как минимум, приводит к хорошему повторному использованию кода между клиентом и сервером.
Здравствуйте, gandjustas, Вы писали:
A>>Я уже написал, ты не удосужился прочесть. "настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора". G>Критерий полезности в студию. Работа с деньгами в программе должна быть точной, иначе проблема может быть очень много.
Критерий полезности зависит от конкретной задачи, так что не надо заниматься демагогией.
G>>>Что делать если в один прекрасный момент появится необходимость это время увеличить в 2 раза? A>>А в чём проблема-то? Кеш обновляется не по таймеру. G>И как же он обновляется? Вытягиванием changeset с сервера при каждом обращении?
Не при каждом, в том то и суть. когда, зависит от задачи. Можно по запросу пользователя, можно при указании со стороны сервера на передачу устаревших данных.
G>Ну и чем же запрет удаления вызван?
Накопленным опытом. Часто, удалённые данные тоже нужны, хотя бы чтобы точно знать что именно удалили.
A>>Не любая, потому что не все данные можно редактировать, но некоторые могут. И, кстати, часто возможность продолжить работу важнее, чем возможность продолжить её корректно. Например, если филиал магазина с двухтысячным ассортиментом отрубился от сети, а в центре обновили цены на три товара, лучше продолжить продавать по старым ценам, а не закрывать филиал. G>Угу, опять сведение к разделению данных между пользователями.
Нет, в данном случае разделение не при чём. Дело в реальных потребностях бизнеса. От того что что-то не обновилось нельзя всё останавливать.
Здравствуйте, Sinclair, Вы писали:
IT>>нечего лишнего не напишешь. Компилятор всё проверит и далее прямая трансляция в SQL в самом лучшем виде. Единственный косяк, который может быть, это вместо класса Person анонимный тип или ещё какая неуставная хрень. S>Именно. А теперь приведи мне в этом стиле пример с Delayed и Discount, а то я што-то не проникся способом оставить другие свойства ордера в неизменности.
(from o in db.Orders where ... select o).
Update(o => new Order
{
Delayed = true,
Discount = o.Discount + Consts.DelayDiscountRate
});
Для усиления контроля можно придумать что-нибудь вроде:
(from o in db.Orders where ... select o).
Update(db.Orders, o => new Order
{
Delayed = true,
Discount = o.Discount + Consts.DelayDiscountRate
});
IT>>Здесь нужно писать дополнительные неочевидные методы. Нафиг такое счастье? S>Ну, я бы ожидал от взрослого языка или макрогенератора наличия этих методов забесплатно. Чё там, если уж мечтать так мечтать, не так ли?
Во взрослом языке конструкция Update может быть встроена в синтаксис и сделана семантически правильной.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Я уже написал, ты не удосужился прочесть. "настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора". G>>Критерий полезности в студию. Работа с деньгами в программе должна быть точной, иначе проблема может быть очень много. A>Критерий полезности зависит от конкретной задачи, так что не надо заниматься демагогией.
Так это ты демагогию разводишь. Есть конкретная ситуация со скидками, ты можешь сказать как будет осщуствляться кеширование в таком случае? Конкретно время и условия устаревания, способ обновления кеша.
G>>>>Что делать если в один прекрасный момент появится необходимость это время увеличить в 2 раза? A>>>А в чём проблема-то? Кеш обновляется не по таймеру. G>>И как же он обновляется? Вытягиванием changeset с сервера при каждом обращении? A>Не при каждом, в том то и суть. когда, зависит от задачи. Можно по запросу пользователя, можно при указании со стороны сервера на передачу устаревших данных.
Ну по запросу пользователя — это понятнно, зачасту такой подход гораздо менее эффективен, чем передача только нужных данных по запросу пользователя.
А вот насчет указания сервреа я не понял. Нету ведь постоянной связи с сервером, да и как будет выполняться оповещение?
G>>Ну и чем же запрет удаления вызван? A>Накопленным опытом. Часто, удалённые данные тоже нужны, хотя бы чтобы точно знать что именно удалили.
Большенство твоего опыта — следствие архитектурных ошибок.
A>>>Не любая, потому что не все данные можно редактировать, но некоторые могут. И, кстати, часто возможность продолжить работу важнее, чем возможность продолжить её корректно. Например, если филиал магазина с двухтысячным ассортиментом отрубился от сети, а в центре обновили цены на три товара, лучше продолжить продавать по старым ценам, а не закрывать филиал. G>>Угу, опять сведение к разделению данных между пользователями. A>Нет, в данном случае разделение не при чём. Дело в реальных потребностях бизнеса. От того что что-то не обновилось нельзя всё останавливать.
Можешь не доказывать, я уже понгял с какими программами ты работаешь. Такой подход применим в очень небольшом количестве случаев.
Здравствуйте, Sinclair, Вы писали:
S>И всё это накроется в одночасье, как только анонимусы станут туплами. Потому, что "Beverages" превратятся в string Value1, а Page — в int Value2. S>Альтернативой могло бы быть наследование анонимуса от тупла. А еще лучше — неявная реализация интерфейса ITuple<T1, T2, T3,...>, чтобы банальный рефлекшн вообще не находил унаследованных ValueN. Но там — свои приколы, связанные с совместимостью по присваиваниям. В том смысле, что мы вроде как ожидаем возможности неявно сконвертировать любой Tuple<string, int> в тип объекта, заданного new {Category="Beverages", Page=12}.
Не понял что тут накроется. В принципе достаточно иметь обратную конверсию.
S>Сценарий конверсии — очень простой. Вот мы берем и получаем откуда-нибудь (например, из линка) некий ICollection<T>, где T — унаследован от Tuple<string, int>. S>А в параметр нашего метода приезжает честный Tuple<string, int> (аноним, ессно, приехать не может — он невыносим за пределы метода). И мы его хотим к этой коллекции приклеить. Упс! Налицо жосткое нарушение type safety — некорректный даункаст. Потому что мало ли кто приехал к нам под видом Tuple<string, int>. Может, я там наследника передал.
Что-то ты тут недописал. Есть
Tuple<string, int> (абстрактный класс к примеру) и
ConcreteTuple<string, int> : Tuple<string, int>, а также метод
Foo(ICollection<Tuple<string, int>> c)
мы в Foo передаём List<Tuple<string, int>> в которм лежат ConcreteTuple<string, int>.
Никакого нарушения type safety здесь нет.
S>Возможное решение — при конверсии конструировать новый экземпляр. Но это, опять же, чревато граблями из-за того, что преобразование перестанет сохранять идентичность.
Такое лекарство хуже болезни.
S>Возможное решение этой проблемы — отказаться от идентичности, т.е. перейти к value-типам. В принципе, желание логичное, т.к. туплы по семантике и должны себя вести как value-типы. S>Но тогда мы теряем (по крайней мере в текущем CLR) возможность наследоваться от них.
А накой от них наследоваться? Вот мы от value types в C# наследоваться не можем, хотя CTS это допускает, вроде никто не ноет.
По уму кортежи должны быть неизменяемыми. S>В общем, получается какая-то дупа. Связанная, очевидно, именно с тем, что структурные типы не были включены в рассмотрение при проектировании CLR c самого начала. S>Впрочем, я тут не самый умный — в CLR уже работает достаточно злая магия типа неявной реализации большого количества интерфейсов массивами, занятные правила ко/контравариантности для массивов и делегатов (а теперь и для интерфейсов), шаманства с Nullable... Так что, возможно, и придумают злую магию, которая сделает туплы рабочими.
Идея Влада делать тонкий тюнинг атрибутами позволяет закрыть подобные corner cases.
Здравствуйте, vdimas, Вы писали:
V>>>Да, хаскелисты тоже так считают. Хотя, полиморфизм по алгебраическим типам — это опять же и снова классика динамической типизации. EC>>Это в каком месте полиморфизм по алгебраическим типам динамически типизирован?
V>В месте определения значения дискриминатора, вестимо. Конкретно в Хаскеле — в соотв. строке матчинга.
Т.е. у нас может быть ошибка типизации времени выполнения?
Ты уверен, что имеешь в виду именно динамическую типизацию, а не диспетчеризацию?
now playing: Dubfire — I Feel Speed (Dubfire Original Club Mix)
Здравствуйте, Lloyd, Вы писали:
L>Меня смущает то, что со временем эта куча превращается в помойку, т.к. никакой внятной схемы именования подобных классов мне придумать не удалось.
Здравствуйте, Sinclair, Вы писали:
L>>Меня смущает то, что со временем эта куча превращается в помойку, т.к. никакой внятной схемы именования подобных классов мне придумать не удалось. S>Ну, идеально было бы их вообще не именовать.
И как же их не именовать?
L>>Был бы аналог удобного глобального вывода типов для анонимных классов, было бы удобно. А так приходится созерцать эти унылые CustomerInfo... S>Называй класс по имени View.
Не получится.
Например, есть страница Customer. Не ней отображаются не только текущий Customer, но и всякие зависящие от него Location-ы, Department-ы, Person-ы и прочее. Как минимум кроме CustomerInfo придется заводить и *Info для всех остальны сущностей.
А если учесть, что многие сущности выводятся на более чем одной странице и зачастую выводятся разные поля, то становится совсем весело.
L>>PE = Presentation Entity
L>>Удобно, если ID и Name. Но если полей становится больше 2-3-х, то получаем кучу унылого говно-кода. S>Откуда взялся говнокод?
Здравствуйте, EvilChild, Вы писали:
L>>Меня смущает то, что со временем эта куча превращается в помойку, т.к. никакой внятной схемы именования подобных классов мне придумать не удалось.
EC>А если творчески применить пространства имён?
Тогда будет помойка, размазанная по пространствам имен.
Здравствуйте, Lloyd, Вы писали:
L>>>Был бы аналог удобного глобального вывода типов для анонимных классов, было бы удобно. А так приходится созерцать эти унылые CustomerInfo... S>>Называй класс по имени View.
L>Не получится.
Неправльно формируешь PE.
L>Например, есть страница Customer. Не ней отображаются не только текущий Customer, но и всякие зависящие от него Location-ы, Department-ы, Person-ы и прочее. Как минимум кроме CustomerInfo придется заводить и *Info для всех остальны сущностей. L>А если учесть, что многие сущности выводятся на более чем одной странице и зачастую выводятся разные поля, то становится совсем весело.
Presentation Entity надо формировать не на основе сущностей, а на основе отображаемых полей. Часто оказывается что набор полей при отображении разных сущностей семантически совпадает.
Судя по тем проектам, которые я делал, количество Presentation Entity классов не больше 1/3 количества вьюх. При этом 90% вьюх — отображение. При значиетльном количестве crud операций количество кастомных PE уменьшается.
Здравствуйте, gandjustas, Вы писали:
L>>>>Был бы аналог удобного глобального вывода типов для анонимных классов, было бы удобно. А так приходится созерцать эти унылые CustomerInfo... S>>>Называй класс по имени View.
L>>Не получится. G>Неправльно формируешь PE.
Конечно, неправильно, раз помойка получается.
L>>Например, есть страница Customer. Не ней отображаются не только текущий Customer, но и всякие зависящие от него Location-ы, Department-ы, Person-ы и прочее. Как минимум кроме CustomerInfo придется заводить и *Info для всех остальны сущностей. L>>А если учесть, что многие сущности выводятся на более чем одной странице и зачастую выводятся разные поля, то становится совсем весело. G>Presentation Entity надо формировать не на основе сущностей, а на основе отображаемых полей. Часто оказывается что набор полей при отображении разных сущностей семантически совпадает.
На странице Customer-а нужно отображать информацию о кастомере (все поля за исключением аудит-полей) и его Department-ы (ID, Name, Address, Field1, кол-во Person), Location-ы (ID, Name, Address, Field2), Person-ы его Department-ов (ID, FirstName, LastName, Field3).
Как в этом случае будет выглядеть правильные PE?
G>Судя по тем проектам, которые я делал, количество Presentation Entity классов не больше 1/3 количества вьюх. При этом 90% вьюх — отображение.
Хорошо вам.
G>При значиетльном количестве crud операций количество кастомных PE уменьшается.
Здравствуйте, gandjustas, Вы писали:
G>Так это ты демагогию разводишь. Есть конкретная ситуация со скидками, ты можешь сказать как будет осщуствляться кеширование в таком случае? Конкретно время и условия устаревания, способ обновления кеша.
gandjustas ты о кешировании и его назначении имеешь понятия ноль, я просто устал бороться с твоей полнейшей безграмотностью.
G>А вот насчет указания сервеа я не понял. Нету ведь постоянной связи с сервером, да и как будет выполняться оповещение?
При синхронизации. Например взял заказ на 50 банок, на складе реально 48 (2 списали как разбитые), при синхронизации попросят заказ скорерктировать, так как остатки склада устарели.
A>>Накопленным опытом. Часто, удалённые данные тоже нужны, хотя бы чтобы точно знать что именно удалили. G>Большенство твоего опыта — следствие архитектурных ошибок.
Очень громкое утверждение для человека, который не привёл ни одного конкретного решения поставленных задач. В своих фантазиях можешь быть крутым, я не против.
A>>Нет, в данном случае разделение не при чём. Дело в реальных потребностях бизнеса. От того что что-то не обновилось нельзя всё останавливать. G>Можешь не доказывать, я уже понгял с какими программами ты работаешь. Такой подход применим в очень небольшом количестве случаев.
Я в своих рассуждениях ссылался минимум на 4 типа программ для систем с весьма разными бизнес-процессами, но ты видимо слишком неопытен чтобы это понять.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Так это ты демагогию разводишь. Есть конкретная ситуация со скидками, ты можешь сказать как будет осщуствляться кеширование в таком случае? Конкретно время и условия устаревания, способ обновления кеша. A>gandjustas ты о кешировании и его назначении имеешь понятия ноль, я просто устал бороться с твоей полнейшей безграмотностью.
G>>А вот насчет указания сервеа я не понял. Нету ведь постоянной связи с сервером, да и как будет выполняться оповещение? A>При синхронизации. Например взял заказ на 50 банок, на складе реально 48 (2 списали как разбитые), при синхронизации попросят заказ скорерктировать, так как остатки склада устарели.
Ты изобретаешь велосипед. Его давно уже сделали, Sync Services называется.
Только это далеко не единственный и далеко не всегда самый эффективный вариант кеширования.
Но до тебя это не доходит никак.
A>>>Нет, в данном случае разделение не при чём. Дело в реальных потребностях бизнеса. От того что что-то не обновилось нельзя всё останавливать. G>>Можешь не доказывать, я уже понгял с какими программами ты работаешь. Такой подход применим в очень небольшом количестве случаев. A>Я в своих рассуждениях ссылался минимум на 4 типа программ для систем с весьма разными бизнес-процессами, но ты видимо слишком неопытен чтобы это понять.
Можешь ссылаться хоть на 8 типов. Все равно они все сводятся к одному сценарию. А те которые не сводятся ты искусственно пытаешься свести к такому сценарию.
L>>>Например, есть страница Customer. Не ней отображаются не только текущий Customer, но и всякие зависящие от него Location-ы, Department-ы, Person-ы и прочее. Как минимум кроме CustomerInfo придется заводить и *Info для всех остальны сущностей. L>>>А если учесть, что многие сущности выводятся на более чем одной странице и зачастую выводятся разные поля, то становится совсем весело. G>>Presentation Entity надо формировать не на основе сущностей, а на основе отображаемых полей. Часто оказывается что набор полей при отображении разных сущностей семантически совпадает.
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).
Если списки похожи, то я бы для Department_ов, Location_ов и Person_ов сделал бы одну структуру отображения L>Как в этом случае будет выглядеть правильные PE?
G>>При значиетльном количестве crud операций количество кастомных PE уменьшается. L>Из-за чего?
Из-за того что для crud используются непосредственно сущности БД.
Здравствуйте, EvilChild, Вы писали: EC>Не понял что тут накроется. В принципе достаточно иметь обратную конверсию.
Не всегда, но я сходу пример не напишу.
S>>Сценарий конверсии — очень простой. Вот мы берем и получаем откуда-нибудь (например, из линка) некий ICollection<T>, где T — унаследован от Tuple<string, int>. S>>А в параметр нашего метода приезжает честный Tuple<string, int> (аноним, ессно, приехать не может — он невыносим за пределы метода). И мы его хотим к этой коллекции приклеить. Упс! Налицо жосткое нарушение type safety — некорректный даункаст. Потому что мало ли кто приехал к нам под видом Tuple<string, int>. Может, я там наследника передал. EC>Что-то ты тут недописал. Есть EC>Tuple<string, int> (абстрактный класс к примеру) и EC>ConcreteTuple<string, int> : Tuple<string, int>, а также метод EC>Foo(ICollection<Tuple<string, int>> c) EC>мы в Foo передаём List<Tuple<string, int>> в которм лежат ConcreteTuple<string, int>. EC>Никакого нарушения type safety здесь нет.
А в обратную сторону? Если Foo() принимает Tuple<string, int>, а внутри он получает коллекцию {string Name, int Age}.
Добавить в эту коллекцию принятый аргумент он не может. Единственное, что можно сделать — это искусственно повысить тип коллекции до ICollection<Tuple<string, int>>, чтобы она была совместима с обоими потомками. Но это — потеря имен мемберов в элементах коллекции.
EC>А накой от них наследоваться? Вот мы от value types в C# наследоваться не можем, хотя CTS это допускает, вроде никто не ноет.
Разве допускает? А по-моему наследование от value-types запрещено на уровне CLR.
EC>По уму кортежи должны быть неизменяемыми.
Ага. EC>Идея Влада делать тонкий тюнинг атрибутами позволяет закрыть подобные corner cases.
Посмотрим.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали: VD>Набор, порядок следования, смещения, области видимости и имена полей.
Зачем имена полей?
VD>В прочем, учитывая проблемы с видимостью членов возможно должно быть полное совпадение интерфейса: полей, публичных методов и свойств, реализуемых интерфейсов. VD>Для реализации записей достаточно будет если у объекта все поля будут публичными (доступными только на чтение). В прочем, у анонимных типов это уже не так. В них проявляется весь маразм ООП. Наружу торчат свойства, а свойства скрыты. Но это уже детали реализации. Если принять правила: VD>1. Структурно-эквивалентными объектами могут быть объекты одного супер-типа (struct, class и т.п.). VD>2. Объекты должны быть помечены специальным атрибутом содержащим Guid.
Наверное, классы?
VD>3. У объектов должны полностью совпадать структура полей и интерфейс (возможно можно наплевать на не публичные методы и своейства). VD>4. Тип должен быть запечатанным (sealed). VD>то можно прозрачно обеспечить структурную эквивалентность для весьма разных типов.
Нуу... Может быть, оно и сработает.
VD>Это немного другое. Там проблемой было неинтуитивная семантика. В случае структурной эквивалентности таких проблем нет. Кстати, в ML-клонах решена проблема null. Это исключает целый класс ошибок. Очень советую познакомиться.
Ок.
VD>Это отдельный разговор. Ты изобрел велосипед.
Кто бы сомневался VD>В ML-клонах есть подобная функциональность. Выглядит немного по другому, но суть та же.
Ок. посмотрим.
VD>Это у CLR есть проблема в поддержке этих языков. И уж одно это является его недостатком.
Ну, теперь уже поздно отказываться от поддержки этих языков. Нужно какое-то другое решение этой проблемы.
VD>Ну, дык и гнат его из MVP.
Тогда много кого гнать придется.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Если нам не помогут, то мы тоже никого не пощадим.
