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

VD>Это миф.

Это реальность.

VD>Зайди на баг-треккер Майкрософт и убедись сам сколько багов годами не исправляются.

При чем тут багтрекер?

VD>Скажем пользователей Гибернэйта на сегодня сильно больше чем линка.

С чего ты это взял? (hint: учитываем только NHibernate)

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

A>>Каким образом интеснивность работы пользователя зависит от размера кеша?
S>Ну так обновление кэша зависит от интенсивности работы других пользователей. Вот у меня стоит янус со своим кэшем. Объем скачиваемых им изменений зависит, Рома, не от моих усилий, а от твоих. И чем на большее количество форумов я подпишусь, тем больше будет трафик.

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

A>>Нет. Мы говорим об клиенте и апп-сервере
S>Ну, тогда я не уверен, что понимаю что и зачем мы пытаемся изобрести. Какой тут нафиг ORM вообще? Зачем он нужен?

Позволяет легко и качественно писать то что ты называешь толстым клиентом.

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

Нет большого смысла использовать Linq, когда все нужные объекты помещаются в ОЗУ. Нет, конечно есть Linq2Objects, но лично мне это показалось не очень адекватным решением.
Современный, так называемый, тонкий клиент это 400МГц процессора, 256Мб памяти, 300Мб свободных на флешке и Windows XP Embedded. То есть тонкий клиент в обычном понимании программиста (что-то типа браузера) и тонкий клиент сходящий с заводов несколько разные вещи.

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

S>Простые. Будет ли верифицироваться операция подписки на событие, если аргументом делегата выступает один из структурно-совместимых типов, а аргументом события — потомок другого.

Запрети для них наследование. Оно им на фиг не упало. Это не ООП-инструмент.

Смотри. Мне структурная идентичность нужна для воспроизведения записей.
Запись — это кортеж с именованными значениями, то есть запись так же не имеет типа.
Можно рассматривать запись как анонимный тип который можно описать с помощью одной из следующих нотаций:

Age : int * FirstName : string // в стиле Nemerle
Anonimus< int Age; string FirstName; > // в стиле C# ()

VD>>Тут много вариантов решения. Самое простое решение — обязать помечать типы помечаемые атрибутом структурной идентичности модификатором sealed.
S>Или, что в принципе то же самое, реализовать их как value-типы. Один хрен reference-семантика им только мешает.

Она им монопенисуальна. Например, кортежи в Nemerle до 3 элементов включительно являются типами-значениями, а после трех ссылочными типами. Когда тип не изменяемый — это не является особой проблемой. Главное, чтобы сравнение работало корректно (по значениям полей).

VD>>Не выдумывай. Данная возможность реализована в большинстве ФЯ. Так что все проблемы надуманы. Просто не надо жить в догмах системы типов донета. Надо ее немного расширить.
S>В большинстве ФЯ не заморачиваются интероперабельностью с существующей системой типов CLR. Исключений, в общем-то, два: F# и сами-знаете-кто. Поэтому от мажорного контрибутора в один из них я инстинктивно ожидаю более развернутых комментариев

Ты смотришь не с той колокольни. F# и Nemerle вынуждены ограничиваться системой типов дотнета и эмулировать функциональные типы на том, что есть. Большую часть сэмулировать удалось. Но вот записи, которые были бы очень нужны без поддержки в CLR не сделать (качественно не сделать). Именно поэтому анонимные типы такие убогие. Ведь им мешали те же проблемы. Интересно, что для интефейсов в МС что-то сделали. Но это что-то вряд ли подойдет для реализации записей.

S>В таком случае полезность от анонимных типов резко уменьшится. Смотри: наследоваться ты им только что запретил; интерфейсы в них никак не реализуешь.

Остается только отвечать так же как ты...


S>Это означает, что надо быть крайне осторожным при изготовлении кода. Уже не получается сделать метод AddFinancialSecurityCheck, который гарантирует запрет доступа младшего персонала к любым документам с суммой больше $5000 USD. Этот метод будет гвоздями прибит к совершенно конкретному типу результата.



S>Это, конечно, не так плохо, как сведение всех запросов к небольшому набору full-blown classes с ORM, но всё равно снижает возможности по декомпозиции.

Это другой подход. Подход где нет ОП, наследования и полиморфизм если и есть, то другой.

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


VD>>Они различны. Имена полей — это дополнительная информация о типе. Если разрешить плевать на нее, то могут вылезать неприятные ошибки.
VD>>Опять же есть туча языков где есть и кортежи, и записи. Они четко демонстрируют, что ничего лишнего в этом нет. Более того их системы типов проектировались серьезными людьми и долго продумывались.
S>Ну, я-то мало с этим знаком.

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

S>Если есть какие-то письменные источники, то я бы почитал. А то приходится выдумывать велосипеды, глядя на конкретные проблемы конкретного фреймворка.

В форуме "Декларативное программирвоание" несколько раз давали ссылки на серьезные работы по системам типов. Я не имею подборки ссылок. Зайди туда и попроси ссылок. Уверен, что их тебе быстро дадут.
Если не ошибаюсь, много работ по системам типов было на http://lambda-the-ultimate.org. Попробуй погулить там.

S>Это понятно. Я не про это, а про то, что если у типа reference семантика, то программист получит весьма неожиданный результат при попытке выполнить сравнение через ==.

Достаточно просто определить соответствующие операторы. Для строк же таких проблем нет?

VD>>Откровенно говоря не понимаю причем тут приведение IEnumerable<T> и T[]. Я, видимо, потерял ход мысли.
S>Про массивы ты уже высказался. Осталось понять, должен ли IEnumerable< { string Name, int Age} > быть автоматически приводимым к IEnumerable<Tuple<string, int>>.

Это было бы полезно. Не уверен на счет обраного. Впрочем явное приведение было бы тоже полезно.
Проблем с реализацией быть не должно. Разве что нельзя делать структурно идентичными типы-значения и ссылочные типы. Но это не сложно проверить.
Написал и подумал. Если типы будут не изменяемыми, то можно просто производить копирование в нужный тип если предлагается преобразовать ссылочный тип в значение или наоборот.

VD>>Куда? Меня в группу разработки CLR никто не завл. И даже мнения не спрашивал.
S>Зато я могу написать гадостей в csharp-insiders mailing list. Что я и делаю, но у меня не хватает компетентности.

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


VD>>В прочем, я там и н нужен. Меера достаточно. Просто нужно постараться понять то, что он говорит.
S>

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

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

ЗЫ

Задай в закрытой группе такой вопрос:
Будет ли в следующей версии C# возможность возвращать анонимные типы из функций? Если, да то каких, публичных или только в рамках сборки? Если нет, то будет ли возможность структурной совместимости типов, чтобы полноценные анонимные типы (записи) можно было реализовать в других языках (например, в F# и Nemerle)?
Если "нет" ответят на все вопросы, то хорошо бы услышать обоснование.

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

A>>И там тоже можно забыть.
S>Рома, ты наверное плохо понимаешь. Все запросы, которые ты пишешь в линке, проходят через один и тот же енжин. Поэтому можно поставить эту проверку ровно в 1 (одном) месте, и больше никогда не бояться что-то пропустить.

У етбя получится очень сложная проверялка ссылочной целостности.

A>>Это не те права доступа, о которых я говорил.
S>Ну так понятно — ты говорил о каких-то других правах доступа, чем те, которые реально нужны.

Э нет, я говорю о тех правах, которые все только обещают сделать и оставляют на потом, а в итоге так и не делают нормально. То что ты говоришь надо в одном месте, для одногоо бизнес-процесса. То о чём говорю я, нужно всегда. Я уже насмотрелся как кассир в Батуми принимал деньги от доставки Кутаиси в кассу Телави. Ссылочная целостность прав доступа — очень важная вещь.

Здравствуйте, adontz, Вы писали:
A>Ага, только вот между чтениями может пройти существенное количество времени (минуты). Не вариант.
А по-другому никак.
A>Ты не обеспечиваешь целостность данных, ты просто позволяешь эффективно читать обновления. Это вообще другая задача.
А ты как-то по-другому обеспечиваешь "целостность данных"? Нет, нифига ты не обеспечиваешь.
Целостность данных иначе как транзакционным чтением и не обеспечишь.

Здравствуйте, adontz, Вы писали:
A>Они не порождаются just-in-time
В таком случае где же "прозрачность"? Прозрачность должна обеспечивать независимость клиента от того, успел ли сервер прогнать скрипты обновления для нужной версии.

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

VD>>Это миф.

T>Это реальность.

С подобной аргументацией лучше в споры не влезать.

VD>>Зайди на баг-треккер Майкрософт и убедись сам сколько багов годами не исправляются.

T>При чем тут багтрекер?

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

VD>>Скажем пользователей Гибернэйта на сегодня сильно больше чем линка.

T>С чего ты это взял? (hint: учитываем только NHibernate)

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

На сегодня linq (EF) движется в сторону NHibernate. И на мой взгляд — это совершенно не верное направление.

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

C>>Нет, ты это сам придумал, что объект штата будет большим из-за того, что программа предназначена для работы с географией.
C>>Если программа для работы с географией не предназначена, то раздувание объекта типа "штат" — это плохой дизайн.
G>все что не укладывается в ORM — плохой дизай, ага.
Ага.

C>>Для редких случаев, когда overhead от ORM слишком велик — используем DTO.
G>Нормальные люди используют запросы и не парятся с DTO, ORM и другими трухбуквенными сочетаниями.
В том числе и с SQL?

C>>Ситуация примерно как с ассмеблерными вставками раньше — оптимизируем только узкие места.
G>Неверная аналогия. SQL обладает большими возможностями, чем GetById, FindByName и прочее.
Что ты привязался к FindByName?? В нормальных ORM есть свой язык запросов, кроме того, есть ещё навигационный доступ.

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

A>>Ты не обеспечиваешь целостность данных, ты просто позволяешь эффективно читать обновления. Это вообще другая задача.
S>А ты как-то по-другому обеспечиваешь "целостность данных"? Нет, нифига ты не обеспечиваешь.

Я уже показал как, но ты видимо так и не понял. Начнём с основных тезисов

В базе данных можно выделить такое подмножество записей, что любая из этих записей будет ссылаться (foreign key) только на записи того же подмножества.
Добавление записей не входящих в данное подмножество непосредственно, не расширяет его.
Множество записей необходимых для работы (кроме отчётов) конкретному пользователю значительно, на порядки, меньше общего количества записей.
В кеше клиентского ПО можно хранить только вышеупомянутое подмножество.

S>Целостность данных иначе как транзакционным чтением и не обеспечишь.

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

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

IT>>А как для двух полей?
S>Ну так это ж бубльг... то есть fluent interface:
S>

S>(from o in orders where o.OrderDate < xxx select o).Update(o => o.SetDelayed(true).SetDiscount(o.discount + Consts.DelayDiscountRate);
S>

Т.е. нужно будет писать ещё по одному методу на каждое поле? Не, это даже хуже чем ==. Компилятор тут мало чем помогает плюс дополнительная писанина. Я думаю, всё же надо делать через MemberInit.

Здравствуйте, adontz, Вы писали:
A>У етбя получится очень сложная проверялка ссылочной целостности.
При чем тут RI? Она ортогональна безопасности.


A>Э нет, я говорю о тех правах, которые все только обещают сделать и оставляют на потом, а в итоге так и не делают нормально. То что ты говоришь надо в одном месте, для одногоо бизнес-процесса. То о чём говорю я, нужно всегда.
A>Я уже насмотрелся как кассир в Батуми принимал деньги от доставки Кутаиси в кассу Телави. Ссылочная целостность прав доступа — очень важная вещь.
Непонятно, о чем ты говоришь. Ограничения на то, кто где должен иметь право принимать деньги — это как раз бизнес-логика. И именно ее лучше делать так, как я говорю.

Здравствуйте, Cyberax, Вы писали:
C>Что ты привязался к FindByName?? В нормальных ORM есть свой язык запросов, кроме того, есть ещё навигационный доступ.
Надо отличать язык объектных ограничений от языка структурированных запросов, в котором есть вывод типов и прочие нюансы.

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

S>Альтернативный подход построен на Expr<Action<T>>, и выковыривании изменений, примененных к объекту "по месту". (...UpdateAll(o=>{o.Name = "Vasya";})).

Это не будет компилироваться.

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

A>Я уже показал как, но ты видимо так и не понял.
Нет, ты не показал. Потому что в твоем примере могло изменится ещё много чего, но никакой гарантии актуальности результата у тебя нет.
A>Начнём с основных тезисов
Ок.
A>В базе данных можно выделить такое подмножество записей, что любая из этих записей будет ссылаться (foreign key) только на записи того же подмножества.
Это да. Можно выделить связный подграф.
A>Добавление записей не входящих в данное подмножество непосредственно, не расширяет его.
Этого утверждения я не понял. Добавление куда? Не расширяет кого?

A>Множество записей необходимых для работы (кроме отчётов) конкретному пользователю значительно, на порядки, меньше общего количества записей.
Ок, от подграфа мы отошли к каким-то "необходимым для работы" записям.

A>В кеше клиентского ПО можно хранить только вышеупомянутое подмножество.
Какое из двух? Необходимых или таких, котор
ые в связном подграфе?
Или ты намекаешь на то, что можно начать с тех записей, которые заказал для работы пользователь, и построить транзитивное замыкание по FK? И ты, надо полагать, собираешься доказать два утверждения:
1. Этих записей значительно, на порядки, меньше общего количества записей.
2. Обеспечение актуальности кэша именно этих записей обеспечивает ссылочную целостность всей БД
3. Обеспечение актуальности кэша именно этих записей менее затратно, чем обеспечение актуальности кэша результатов конкретных запросов.
Давай, доказывай.

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

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

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

IT>>>А как для двух полей?
S>>Ну так это ж бубльг... то есть fluent interface:
S>>

S>>(from o in orders where o.OrderDate < xxx select o).Update(o => o.SetDelayed(true).SetDiscount(o.discount + Consts.DelayDiscountRate);
S>>

IT>Т.е. нужно будет писать ещё по одному методу на каждое поле?
Не понял фразу. Писать где? В запросе? Ну так он и так не намного многословнее, чем присваивания вида o.Delayed = true; o.Discount = o.Discount + Consts.DelayDiscountRate.
А если еще и Linq-синтаксис будет так и вообще, он же будет SQL-like set clause превращать в эту цепочку автоматически.
IT> Не, это даже хуже чем ==. Компилятор тут мало чем помогает плюс дополнительная писанина.
но ведь code completion работает
IT>Я думаю, всё же надо делать через MemberInit.
Я против.

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

IT>>Т.е. нужно будет писать ещё по одному методу на каждое поле?
S>Не понял фразу. Писать где? В запросе?

Вне запроса. Кто этот метод будет объявлять?

S>Ну так он и так не намного многословнее, чем присваивания вида o.Delayed = true; o.Discount = o.Discount + Consts.DelayDiscountRate.

В данном случае компилятор на 100% проверяет правильность запроса. А с дополнительными методами, да ещё в цепочке прямо в Expression можно такого понаписать и потом долго тупить от выкидышей в рантайме.

S>А если еще и Linq-синтаксис будет так и вообще, он же будет SQL-like set clause превращать в эту цепочку автоматически.
IT>> Не, это даже хуже чем ==. Компилятор тут мало чем помогает плюс дополнительная писанина.
S>но ведь code completion работает

Работает. А если ты случайно объявишь не SetDelayed, а SetDelayd?

IT>>Я думаю, всё же надо делать через MemberInit.
S>Я против.

Напрасно. Мне это тоже не нравится, но отсальное не нравиться ещё больше.

Здравствуйте, VladD2, Вы писали:
VD>Запрети для них наследование. Оно им на фиг не упало. Это не ООП-инструмент.
Ок.

VD>Запись — это кортеж с именованными значениями, то есть запись так же не имеет типа.
VD>Можно рассматривать запись как анонимный тип который можно описать с помощью одной из следующих нотаций:
VD>

VD>Age : int * FirstName : string // в стиле Nemerle
VD>Anonimus< int Age; string FirstName; > // в стиле C# ()
VD>

Я это понимаю и полностью согласен.

VD>Она им монопенисуальна. Например, кортежи в Nemerle до 3 элементов включительно являются типами-значениями, а после трех ссылочными типами. Когда тип не изменяемый — это не является особой проблемой. Главное, чтобы сравнение работало корректно (по значениям полей).
Ну вот собсно основная штука в value-семантике — именно "сравнение работало корректно (по значениям полей)". Или я неправильно понимаю разницу между value- и reference- семантиками?

VD>Ты смотришь не с той колокольни. F# и Nemerle вынуждены ограничиваться системой типов дотнета и эмулировать функциональные типы на том, что есть.
Ну, я что вижу — то пою. Вот ты ссылку дал про ML — надо будет посмотреть.

VD>Я вообще не понимаю, почему ты не критикуешь скажем анонимные типы C#-а. Ведь они не допускают наследования.
Как это не критикую? Собсно, все мои потребности в записях связаны именно с убогостью существующих анон.типов.
VD>А главное они являются приговором декомпозиции, так как вернуть их из функции уже нельзя. Вот почитай, что тут рядом Лойд пишет. Он совершенно резонно спрашивает как ему производить декомпозицию запросов если анонимные типы нельзя возвращать из функций, а кортежи теряют информацию об именах полей.
Ну, так я согласен. Осталось понять, как решить эту проблему.

VD>В форуме "Декларативное программирвоание" несколько раз давали ссылки на серьезные работы по системам типов. Я не имею подборки ссылок. Зайди туда и попроси ссылок. Уверен, что их тебе быстро дадут.
VD>Если не ошибаюсь, много работ по системам типов было на http://lambda-the-ultimate.org. Попробуй погулить там.
OMFG, 422 results. Да, это определенно достаточно много работ, чтобы занять меня на следующие тридцать вечеров пятницы.

VD>Достаточно просто определить соответствующие операторы. Для строк же таких проблем нет?
Ну, возможно ты прав. Главное, чтобы нигде в выражениях не терялся тип. Иначе можно огрести эффект, сравнимый с чудесами боксинга.

VD>Это было бы полезно. Не уверен на счет обраного. Впрочем явное приведение было бы тоже полезно.
Главное — понять, какова семантика этого приведения. Будут ли при енумерировании "на лету" конструироваться новые объекты, или просто будут успешно каститься существующие.

VD>Проблем с реализацией быть не должно. Разве что нельзя делать структурно идентичными типы-значения и ссылочные типы. Но это не сложно проверить.

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

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

VD>Я не понимаю что тут смешного? Если бы его слова были понятны всем, то идиотизма вроде анонимных типов не появилось бы, а появились бы полноценные записи и кортежи.
Не думаю, что его слова там как-то особенно непонятны. Чуваки из CLR — вполне вменяемые. Их главное убедить, что что-то вообще нужно. Потому что их работа — это говорить "but you can achieve virtually the same result by using {workaround description}" — и это правильно. Иначе бы в CLR было бы столько навоза — не разгребешь

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

VD>Задай в закрытой группе такой вопрос:
VD>Будет ли в следующей версии C# возможность возвращать анонимные типы из функций? Если, да то каких, публичных или только в рамках сборки? Если нет, то будет ли возможность структурной совместимости типов, чтобы полноценные анонимные типы (записи) можно было реализовать в других языках (например, в F# и Nemerle)?
VD>Если "нет" ответят на все вопросы, то хорошо бы услышать обоснование.
Ну, там пока в основном другие MVP отжигают; народ из команды как-то так, значительно менее активен. Но я попробую.

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

IT>Вне запроса. Кто этот метод будет объявлять?
а! Ну, так мы же говорим о (в основном) анонимных типах и приравненных к ним именованных типах.
Был автопроперти — будет автометод

IT>В данном случае компилятор на 100% проверяет правильность запроса. А с дополнительными методами, да ещё в цепочке прямо в Expression можно такого понаписать и потом долго тупить от выкидышей в рантайме.
Не понял. Как дополнительные методы помешают компилятору проверить корректность выражения, которое принимает Order и возвращает новый Order?

IT>Работает. А если ты случайно объявишь не SetDelayed, а SetDelayd?
А-а, вон ты про что. Тогда, наверное, придется писать Delayd = true

IT>Напрасно. Мне это тоже не нравится, но отсальное не нравиться ещё больше.
Ты смотрел на Building IQueryable Provider XIII?

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

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

VD>>>Это миф.

T>>Это реальность.

VD>С подобной аргументацией лучше в споры не влезать.

Это же твоя собственная аргументация. Я даже выделил.

VD>>>Зайди на баг-треккер Майкрософт и убедись сам сколько багов годами не исправляются.

T>>При чем тут багтрекер?

VD>Там четко видно сколько ошибок и недоработок так и не исправляются или исправляются долгими годами.

Прекрасно. Но я ничего не писал про количество ошибок.

VD>Это ставит светлую веру в количество пользователей под вопрос.

Количество пользователей не связано с количеством ошибок.

T>>С чего ты это взял? (hint: учитываем только NHibernate)

VD>Из вопросов в форумах, из общения с другими программистами, из информации о том на чем делают те или иные проекты.

У меня сложилось иное впечатление.

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

A>>У етбя получится очень сложная проверялка ссылочной целостности.
S>При чем тут RI? Она ортогональна безопасности.

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

A>>Я уже насмотрелся как кассир в Батуми принимал деньги от доставки Кутаиси в кассу Телави. Ссылочная целостность прав доступа — очень важная вещь.
S>Непонятно, о чем ты говоришь. Ограничения на то, кто где должен иметь право принимать деньги — это как раз бизнес-логика. И именно ее лучше делать так, как я говорю.

Вот это-то и есть ошибка, котрую я уже много раз видел — права доступа не на объекты, а на операции. Если делать права доступа на операции, то получится код, проверяющий, что касса, кассир и сдающий деньги числятся за одним и тем же филиалом. Это код и это не гибко. Не гибко, по той простой причине, что если кассу в Телави ограбили, я машины доставки пущу в Тбилиси, благо всего пара часов пути. А чтобы пустить их в Тбилиси мне надо переписывать код проверяющий права доступа.
Если раздавать права доступа на объекты, то кассир из Батуми другие филиалы вообще не видит. Так как проверка прав доступа обеспечивает ссылочную целостность, он не только филиалы другие не видит, он ещё ин е может оформить на них никакие операции, не может просмотреть отчёты по ним и т.п. То есть я указав права доступа всего на один объект, разрулил проблемы с большим количеством операций. Поменять права — дело пяти минут и работа уже для администратора, а не программиста.