Re[21]: Проблемы организации OR-мапинга
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.04.09 03:28
Оценка: +1 :))) :))
Здравствуйте, Tom, Вы писали:

IT>>В твоём примере с процедурой? Так там у тебя нет ни DAL, ни BL. Только каша из TSQL.

Tom>Хорошо, приведи пример где не будет каши и где всё будет сделано правильно.
Tom>И если можно покажи там разделение на слои.

Tom>PS:

Tom>Не понял где там каша, вроде был один TSQL запрос
Каша там в том, что непонятно,
1. Откуда было взято решение выделить delayed в отдельное поле. Почему нельзя сделать его вычисляемой колонкой, для которой, к примеру, задано выражение "OrderDate < GetDate()"
2. Что у нас там справа от >? Некая константа? Некоторое выражение — функция от атрибутов ордера, например OrderDate < ActualDeliveryDate?
3. Кто решает, какие еще условия наложить на множество ордеров?

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

К сожалению, пока что все системы делятся на две большие группы:
1. Классические клиент-сервера. Характерны большим количеством совершенно шаманских хранимок, которые делают несложные (с точки зрения логики) вещи, но совершенно непостижимы из-за неотъемлемой убогости T-SQL. Никакой композиционной гибкости в них нет, разработчики ходят с серыми лицами и мечтают уехать отсюда куда-нибудь туда, где есть Ajax и Silverlight.
2. Классические ORM. Всё максимально гибко; применены все паттерны Фаулера и несколько своих; в базе — избыточное количество однотипных сгенерированных спроков вида RetrieveXXX; UpdateXXX; и DeleteXXX. C точки зрения СУБД, клиентское приложение (апп-сервер) ведет себя крайне неэффективно: засасывает к себе огромные объемы информации, скармливает обратно килотонны одинаковых запросов типа UpdateXXX.
Производительность "почти устраивает", основные репорты уже переписаны на T-SQL, неосновные ждут своей очереди; разработчики ходят с серыми лицами и мечтают уехать отсюда куда-нибудь туда, где есть Ajax и Silverlight.

3. Есть еще небольшая группа пытающихся бороться с 1 и 2 путем использования динамического T-SQL. Инсталляций мало, система знаменита низкой надежностью, пользователи инстинктивно избегают задавать нетипичные комбинации параметров отчетов. разработчики нервно хихикают при словах "юнит-тестирование", ходят с серыми лицами и мечтают уехать отсюда куда-нибудь туда, где есть Ajax и Silverlight.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Nemerle & Real Life
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.09 18:28
Оценка: 19 (2) +2
Здравствуйте, IT, Вы писали:

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


Tom>>Если серьёзно, ты можешь показать на данном примере как грамотно это дело порефакторить.

IT>Этот код не надо рефакторить. Его нужно переписывать.

Ну почему же, приведенный кусок го... TSQLя можно и отрефакторить.
1)Эта нереальная процедура выполняется фактически 3 разных действия, селектор по параметру @Mode, её стоит разбить на 3 функции
2)Все хранимки с одним output-параметром заменить на функции, сразу же можно будет убрать обработку с помощью курсоров.
3)Врмененные таблицы позаменять на табличные переменные
4)Для получения значений #tz можно использовать table-valued function

Желательно отказаться от операторов IF ELSE в TSQL коде и перенести выбор в клиентский код.

Если ко времени окончания рефакторинга появится DML для Linq, то можно поотказываться от фунцкий и динамически строить запросы с помощью Linq, а потом передавать нужные значения в INSERT и UPDATE.
Re[15]: Проблемы организации OR-мапинга
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.04.09 06:34
Оценка: 18 (3) :)
Здравствуйте, Tom, Вы писали:

VD>>Там нет ни одного пункта интересующего мнея. BLToolkit меня интересует так же слабо как твои идеи размещения запросов в отдельных файлах.

VD>>Лучшим подходом, на мой взгляд, является размещение запросов в виде встроенного (типизированного) DSL внутри кода приложения. Короче говоря подход а-ля linq.
Tom>Такой DSL уже есть. Называется TSQL. Можешь пояснить как может выглядеть собственный DSL для работы с данными? Что принципиально будет в нём отличного от того же TSQL?
Самое главное, чего не хватает в T-SQL — возможностей декомпозиции. В принципе, для достижения множественного оргазма почти хватило бы возможности декларировать в спроках что-то типа локальных view, и редефайнить их по мере необходимости. То есть реляция должна бы стать first-class object в языке.
В мире Linq ей бы соответстовал IQueryable<Tuple<T1, ..., TN>>, если бы у нас были туплы.
Вот тогда можно было бы четко развести бизнес-логику на независимые кирпичи.
Одни функции бы занимались подготовкой реляций, другие — их использованием. Именно это и есть настоящая реляционная алгебра с блэкджеком и шлюхами.
А умение захардкодить конкретное выражение — малоинтересно. Интересны функции высшего порядка.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.09 21:32
Оценка: +4
Здравствуйте, MozgC, Вы писали:

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


G>>Как обрабаотывать случай отсутсвия в базе записи с нужным ID — уже дело BL, причем способ обработки сильно зависит от варианта использования.

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

Я предлагаю не выбрасывать исключение из DAL, а заниматься обработкой случая пустой выборки по месту в BL (возможно с выбрасыванем исключения).
Вполне возможно что отсуствие запси с нужным ID — нормальная ситуация в одном случае и ошибочная в другом, вы что будете делать? Писать два DAL метода с одинаковыми запросами?
Re[19]: Проблемы организации OR-мапинга
От: MozgC США http://nightcoder.livejournal.com
Дата: 11.04.09 22:21
Оценка: +2 :))
Здравствуйте, IT, Вы писали:

MC>>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.

IT>Это назвается строить логику на исключениях, практика, за которую нужно не просто отбивать пальцы линейкой, а лучше даже что-нибудь отрезать.

Нет, это называется использовать исключения там где нужно.

MC>>Вообще так можно про все сказать "что тут исключительного". К примеру пытаемся прочитать файл, а такого файла нет (его уже пользователь удалил), ну а что тут исключительного, давайте признак возвращать.

IT>Вот хороший пример. Можно ещё обсудить вариант с разрешением к доступу к файлу. Твой backup процесс пытается скопировать файл, а он недоступен, по твоей логике есть только один путь — кинуть исключение и прервать процесс. Такой бекапер будет выброшен сразу же после первой проблемы с потерей информации.

Нет, по-моему логике такого не будет, не надо за меня говорить. По-моему логике при попытке скопировать файл выкинется исключение а бизнес-логика решит что делать дальше, к примеру повторить попытку позже или залогировать это или сообщить пользователю.
Re[11]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 11.04.09 22:04
Оценка: 45 (1) +2
Здравствуйте, gandjustas, Вы писали:

A>>Linq не работает не с бизнес-сущностями, а с DTO.

G>Linq работает с данными, или с записями если угодно (одно и тоже). DTO — костыль для изначально хреновой жирной модели.

Я предпочитаю называть набор классов, соответсвующих схеме БД моделью данных приложения. Как правило этот термин интуитивно понятен большинству, не противопоставляет себя объектной модели приложения и не вызывает бурных возражений
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.09 10:53
Оценка: 17 (2) +1
Здравствуйте, gandjustas, Вы писали:

G>SOA — принции построения взаимодействия компонент. То что раньше было RPC теперь веб-сервисы.


SOA — это драцкий базворд за которым нет ничего нового. К компонентам (кстати "компонентов", а не "компонента") SOA не имеет никакого отношения. Расшифровывается этот базворд как "архитектура ориентированная на сервисы". Это тоже самое что серверы ориентированные на RPC. Дурацкий базвордов придумать можно миллионы (что и делаеют конторы вроде МС каждый день), но толку от этого не будет, так как ничего принципиально нового от этот не появится.
SOA родилась в момент когда в МС полностью отчаялись протащить DCOM в область разработки серверов приложений. Тогда они понял, что общаться с серверами намного проще по средствам RPC (без сохранения состояния между вызовами на сервере). Тогда срочно придумали веб-сервисы, а чтобы все это круто звучало и никто не догадался, что это просто откат к более "примитивной" технологии и признание недееспособности ООП в области организации распределенных вычислений назвали все это SOA. Как и любой базворд это звучит красиво, не понятно. Что еще нужно чтобы завуалировать собственную глупость?

ЗЫ

Мне эта тема не интересна. Предлагаю ее закрыть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Проблемы организации OR-мапинга
От: Tom Россия http://www.RSDN.ru
Дата: 08.04.09 16:44
Оценка: 1 (1) :))
IT>Я не использую его в коммерческих проектах. К сожалению, у меня в банке очень жёсткое полиси на весь софт. Средства разработки тоже ограничены, например, из дистрибутива студии вакинут даже VB. Но как только выйдет релиз 1.0 я попытаюсь зареквестить Немерлю хотя бы для оценки возможностей. А там кто знает, может и в продакшин протащу когда-нибудь. В общем, это не просто моё желание или нежелание, это борьба с бюрократической машиной, в которой (в борьбе) ошибок быть не должно.

Пошёл полкупать соль и спички. Новый банковский кризих похоже будет относительно скоро

10.04.09 12:44: Ветка выделена из темы Nemerle &amp; Real Life
Автор: ili
Дата: 11.03.09
— VladD2
10.04.09 21:25: Перенесено модератором из 'Nemerle' — VladD2
Народная мудрось
всем все никому ничего(с).
Re[21]: Nemerle & Real Life
От: IT Россия linq2db.com
Дата: 10.04.09 17:57
Оценка: +2 :)
Здравствуйте, Tom, Вы писали:

Tom>ну вот поростой и типичный вариант


От такого нужно избавляться в первую очередь.

Tom>C# никак не предназначен на сегодняшний день для манипуляции данными. Тем боллее, что серверов БД существует великое множество. И у каждого свой SQL диалект.


Если ты называешь манипуляцией данными то, что ты привёл выше, то это скорее бизнес логика, написанная на TSQL. Это нужно устранять в первую очередь. SQL должен заниматься исключительно тем, для чего он создавался — манипуляцией данными, т.е. исключительно запросами вида SELECT/INSERT/UPDATE/DELETE.
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.09 22:31
Оценка: +3
Здравствуйте, MozgC, Вы писали:

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


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


MC>>>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.

IT>>Это назвается строить логику на исключениях, практика, за которую нужно не просто отбивать пальцы линейкой, а лучше даже что-нибудь отрезать.

MC>Удели пожалуйста 2 минуты, объясни почему за выбрасывание исключения из DAL при отсутствии темы с заданным ID нужно что-нибудь отрезать.


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

Тогда у вас будет или два метода — один — бросающий исключение, а другой такой же, но небросающий. Или у вас появится метод BL, где половина кода в try, другая половина в catch, при этом реально достаточно одного простого if.

Короче если ваша вера непральная, то вы сами себе что-нить отрежете.
Re[20]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.04.09 14:27
Оценка: 7 (2)
Здравствуйте, Lloyd, Вы писали:

L>А как предполагается вытаскивать эту нформацию? Например, в случае того же web-а. Если исползуем вывод типов для запросов типа from c in customer select new { c.id, c.name }, то сразу теряем возможность использовать подобный запрос в более чем одном методе. Если же для каждого такого запроса создаем свой класс-обертку, содержащий id и name, то скоре колиество этих классов разрастется до неимоверных размеров. Как предполагается с этим бороться?


На этот вопрос есть сразу два ответа.
1. В Nemerle есть кортежи (tuple) которые могут служить в качестве возвращаемых типов. Их же можно использовать и в C#, но будет намного кривее, так как будет некоторый синтаксический оверхэд (с) Губанов.
2. Linq использует отложенное выполнение позволяя конструировать запрос по частям. Это позволяет экспортировать из методов запросы возвращающие объекты ассоциируемые с таблицами (те на которые linq осуществляет отображение таблиц). А уже по месту из них можно формировать запросы возвращающие конкретные значения.

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

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

L>А в чем серьезный недстаток вынимания всего объекта?


Если бы это не было проблемой, то классический ORM-мы были бы вполне эффективны и потребность в LINQ никогда не возникла бы.

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

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

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

Но это все костыли. Сам подход гнилой. Намного проще выбрать только требуемые данные. Запрос отличное средство указать какие данные реально нужны, а какие нет.

L>В случае функции бизнес-код будет содержать информацию о том, как данные хранятся, а такому коду, имхо, не место в бизнесе.


Что значит как? Они хранятся в таблицах БД. И в знании этой "сокровенной тайны" нет ничего страшного.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Проблемы организации OR-мапинга
От: Tom Россия http://www.RSDN.ru
Дата: 14.04.09 07:13
Оценка: 6 (1) +1
G>Есть большая проблема в примерах архитектуреных решений. Маленькие примеры непоказательны, а в больших трудно разобраться, да и многие преимущества и недостатки неочевидны.
А розового слоника в вакууме трогать нельзя, а то забанят. без примеров подобные топики сваливаются после третьего сообщения в маразм.
Я думаю идеальным было бы маааленькое приложение как пример.
С разбором, можно так, можно так. Тут такие плюсы минусы. тут такие...
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[33]: Проблемы организации OR-мапинга
От: EvilChild Ниоткуда  
Дата: 27.04.09 16:43
Оценка: 4 (1) +1
Здравствуйте, VladD2, Вы писали:

EC>>Динамическому приведению типа всё равно там делать нечего.


VD>Это не так. Вариант (в терминах немерла) — это базовый тип имеющий ряд подтипов. Ссылка на какой из подтипов была помещена в переменную можно узнать только в рантайме.

В F# сделано аналогично, но это артефакт реализации, такие типы компилятор помечет атрибутом CompilationMapping(SourceConstructFlags.SumType), чтобы отличать их от обычных.
Сделано так, думаю, исключительно исходя из простоты реализации, а не потому, что нам для реализации ПМ нужны динамические приведения типа.
В OCaml или Haskell уверен сделано совсем иначе.

VD>Просто динамическое приведение типов не имеет никакого отношения к динамической типизации. Это один из видов полиморфизма. Список типов известен в момент компиляции, а конкретный определяется в рантайме. Но весь код статически типизирован. И это главное, так как динамический код от статического как раз и отличается тем, что первый может иметь ошибки типизации в рантайме, и тем, что все типы неизвестны о стадии выполнения.

С этим полностью согласен.
now playing: Rekorder — Rekorder 9.3
Re[35]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 21.04.09 03:32
Оценка: 3 (1) +1
Здравствуйте, gandjustas, Вы писали:

G>RBS для операций гораздо проще в создании, поддержке и управлении, чем RLS.

G>Только чтобы сделать RBS правильно думать надо. А вариант с RLS позволяет сказать "у меня все настраивается разрешениями, а дальше е****сь сами".

Это всё только в теории. Практика показывает что управляемыми являются права доступа на элементарные операции над объектами, а не сложные бизнес-процессы.

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

G>А что значит "дополнительных"? В RBS группы (в смысле роли) создаются как раз для разделения групп разрешений.

Да-да-да, это и есть убогость. Подобная ситуация наблюдается в файловой системе старых Линуксов и Юниксов, где невозможно тонко раздать разрешения на объект и в итоге создаётся куча дополнительных групп пользователей, потом появляются всякие sudo, запись в файл через нарошный пайп и прочие извращения. Ты глубоко уверен что говоришь о чём-то прогрессивном, то твоим ошибкам уже лет 30. Сейчас у нас есть seLinux, HP-UX в которые сие исправили, потому что ошибка. Подожду 30 лет пока и ты эволюционируешь.

A>>О да, все в дерьме и только ты в белом. Недостаточное тестирование и кривость рук это факторы существующие в любом проекте.

G>И что? Затыкать проблемы разработчиков кривыми архитектурными решениями, пороздая только новые проблемы?
G>Надо разработчиков учить, а не оберегать ((с) не помню кто)

О нет, fine grained access rights это как раз правильная архитектура.

G>>>Кроме всего прочего RBS позволяет описывать гораздо больше сценариев, чем row-level security.

G>>>Пример Синклера: "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" отлично описывается в RBS, и нифига не работает в варианте row-level security.
A>>А и не должен работать, row-level security решает другие задачи.
G>
G>Какие? И как решать задачу описанную выше?

Я в последний раз пытаюсь до тебя донести элементарную истину. Row level security решает задачи доступа не требующие анализа объектов. Это настолько часто встречающаяся задача, что её крайне выгодно выделить в отдельную универсальную подсистему. Есть задачи которые в RLS не укладываются и их надо решать отдельно, но это не значит что универсальная система RLS перестала быть выгодной или раздавать права на объекты стало ошибкой.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[22]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 13.04.09 19:27
Оценка: 2 (1) +1
Здравствуйте, SleepyDrago, Вы писали:

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


О, эту проблему решить очень просто Я лично разбираюсь в предметной области. У меня неплохие познание в финансах, логистике, торговле. Если разонравится программирование, будет чем занятся.

На самом деле всё довольно грустно. Дело даже не в том, что клиент не может описать то, что он хочет, дело в том, что клиент не знает что он хочет. Не знает по той простой причине, что не умеет предсказывать поведение программных систем даже на уровне "получится/не получится". Практика показывает что программисту выучить предметную область проще, чем клиенту — программирование. Такие вот дела.

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


На самом деле они, отчасти, правы. Но только отчасти. 90% запросов можно генерировать и даже если они будут абсолютно оптимальными, они будут очень близки к этому. Остальные 10% это запросы которые можно оптимизировать. Более того, из нужно оптимизировать. И я не за тотальную генерацию, я за то чтобы начать с генерации и переписать вручную только то, что необходимо переписать. В данном случае, хранимая процедура это ещё один уровень абстракции, ещё один контракт между уровнями. Если мне надо получить остаток склада, то я, с точки зрения логики, просто обязан считать его как сумму операций перемещения. Если я захочу оптимизировать, запоминать промежуточные результаты (остатки складов на начало каждого месяца) или ещё что-то, это всё останется внутри хранимки. В случае с Linq-подобными запросами, не будет единой точки, логика размазана по всему приложению, рефакторинг дорог.

SD>Та же проблема с безопасностью. Какая степень дублирования нужна чтобы при отзыве прав с объекта бд транзитивно обновились все кеши объектов?


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

SD>то есть мне не понятно как вы для себя решили проблему отображения объекты логики <-> сущности бд.


Не без ограничений обошлось, конечно. Скажем, тип данных для primary key для всех объектов фиксирован и одинаков. Я выбрал Guid, потому что данные в систему попадают отовсюду и таскать с сервера IDENTITY удовольствие сомнительное. Например, для списка валют, многие, при написании вручную, в качестве PK взяли бы трёхбуквенный код (UAH, RUR, USD). У меня это Guid, а трёхбуквенный код — один из столбцов. Как с точки зрения логики, так и с точки зрения производительности — несущественное изменение. Но такая унификация сильно упрощает жизнь. Ну и так далее, по мелочи.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[29]: Nemerle & Real Life
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.04.09 06:34
Оценка: 2 (1) +1
Здравствуйте, MozgC, Вы писали:
MC>Вообще временные таблицы иногда могут помочь упростить запрос.
Они его упрощают ровно потому, что SQL не реализует реляционную алгебру.
Если бы реализовывал, то можно было бы делать как раз так:
-- 1. Define the source for the data
define @storelist table(id int primary key)
if (...)
  @storelist = select id from stores where store.city = @city
else if (...)
  @storelist = select @storeId
else
  @storelist = select id from stores
    
-- 2. Search for the item availability across all stores

select Availability from StoreItem where itemId = @itemId and storeId in @storelist

То есть мы реально ничего не селектим до момента 2, а всего лишь меняем способ построения списка. Увы — ничего подобного нет. Поэтому приходится принудительно складывать промежуточный результат во временную таблицу (или в табличную переменную — разницы нет). Это мешает серверу самому выбрать план запроса.

Вот как раз поэтому-то линк и рулит, как гидроусилитель БелАЗа.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: Проблемы организации OR-мапинга
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.04.09 07:13
Оценка: 2 (1) +1
Здравствуйте, Sinix, Вы писали:

S>Второй раз один и тот же вопрос (http://www.rsdn.ru/Forum/message/3361137.1.aspx
Автор: Sinix
Дата: 14.04.09
).

Просто у меня янус три дня глючил и не отправлял ответы.
S>Второй раз отвечу что лучше по старинке:
S>
S>(from o in orders where o.OrderDate < xxx select o).
S>  Update(o => o.SetDelayed(true)).
S>  Update(o => SetDiscount(o.discount + Consts.DelayDiscountRate)); // кстати чисто в теории такие методы вполне можно мапить на хранимые процедуры - вообще ляпота будет.
S>

S>Проще парсить expression tree.
S>Да и в концепцию IQueryable лучше вписывается.
В принципе, да. Я не против . Всё равно в основе лежит Expr<Func<T, T>>.
Альтернативный подход построен на Expr<Action<T>>, и выковыривании изменений, примененных к объекту "по месту". (...UpdateAll(o=>{o.Name = "Vasya";})).
Этот подход ближе к помыслам ORM-щиков; мне он принципиально не нравится, т.к. позволяет скомпилировать код, меняющий состояние объектов вне контекста UpdateAll, что полностью противоречит идее явных апдейтов.
Впрочем, Wayward вроде придумал механику, которая позволяет совместить оба подхода в рамках достаточно худенького IUpdatable<T>.
http://blogs.msdn.com/mattwar/archive/2009/01/22/building-a-linq-iqueryable-provider-part-xiii-iqtoolkit-v-0-13.aspx
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Проблемы организации OR-мапинга
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 13.04.09 04:10
Оценка: 1 (1) :)
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, kochetkov.vladimir, Вы писали:


KV>>А он там и не нужен. Контроль доступа (если мы говорим об одном и том контроле), должен реализовываться на уровне операций, причем "операций" в терминологии BL, а не DAL. В противном случае, это уверенный шаг к уязвимостях недостаточной авторизации.

C>Дело в том, что нужно обеспечивать и контроль данных — чтобы любой пользователь не мог подсмотреть номер кредитки директора.

Забавно, ты сам же и описал задачу в терминах операций BL Уточню, речь о row-level security, упомянутой gandjustas'ом или о чем-то ином?

Кстати, а что ты будет делать с атаками man-in-the-middle?

C>>>Реплики БД — это исключительно кривой хак.

KV>>Хорошо что тебя разработчики Lotus Domino/Notes не слышат. А то они на этом хаке, всю архитектуру своего продукта построили
C>Скажи, и нравится тебе как работает Лотус?

Как пользователю — нет, но это никак не связано с его архитектурой. Как админу, в прошлом поддерживавшему инфраструктуру из 12-13 лотусовых серверов и пары тысяч клиентов — да, нравится. Как безопаснику — мне вообще ничего не нравится, так что не аргумент

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[10]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.09 20:06
Оценка: +2
Здравствуйте, adontz, Вы писали:

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


G>>Сам факт обработки некоторой выборки уже относится к BL, для DAL достаточно вернуть выборку в удобном для обработки виде.


A>Так, ещё раз. Если я говорю "Найди мне клиента по имени Иван" (FindByFirstName), а Вани нет, то это нормальная ситуация. Если я говорю, "верни мне клиента с идентификатором {356F893B-68B3-4687-906B-0A50DD1612C1}" (GetById), а клиента с таким идентификатором нет, то что-то очень серьёзно не так, потому что нарушена целостность данных. Например, заказ ссылается на клиента через идентификатор, а клиента с таким идентификатором нет.

Это ты описываешь уже сильно высокоуровневую логику по сравнению с доставанием данных из БД.

A>Сохранение ссылочной целостности данных в компетенции DAL. Нельзя стирать клиента на которого оформлены заказы.

А я думал это в компетенции БД.

A>Поэтому GetById, если ничего не найдено, выкидывает исключение.

Не вижу связи этого утверждения с предыдущим.

Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).


A>Про orphan records слышал?

Нет.
Re[11]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.04.09 20:14
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

A>>Так, ещё раз. Если я говорю "Найди мне клиента по имени Иван" (FindByFirstName), а Вани нет, то это нормальная ситуация. Если я говорю, "верни мне клиента с идентификатором {356F893B-68B3-4687-906B-0A50DD1612C1}" (GetById), а клиента с таким идентификатором нет, то что-то очень серьёзно не так, потому что нарушена целостность данных. Например, заказ ссылается на клиента через идентификатор, а клиента с таким идентификатором нет.

G>Это ты описываешь уже сильно высокоуровневую логику по сравнению с доставанием данных из БД.

Это тот уровень, с которым надо работать из BL.

A>>Сохранение ссылочной целостности данных в компетенции DAL. Нельзя стирать клиента на которого оформлены заказы.

G>А я думал это в компетенции БД.

ИМХО ты путаешь DAL и ORM. Как бы то ни было, целостность данных должна поддерживаться уровнем ниже BL.

A>>Поэтому GetById, если ничего не найдено, выкидывает исключение.

G>Не вижу связи этого утверждения с предыдущим.

Если ничего не найдено GetById, то нарушена целостность данных. Это такая попа, что тут даже исключения мало.

G>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).


QueryObject нужен для нетипичных запросов, типа запросов для отчётов. Использовать его для всего подряд просто неправильно.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Проблемы организации OR-мапинга
От: MozgC США http://nightcoder.livejournal.com
Дата: 11.04.09 21:13
Оценка: +1 -1
Здравствуйте, gandjustas, Вы писали:

G>Как обрабаотывать случай отсутсвия в базе записи с нужным ID — уже дело BL, причем способ обработки сильно зависит от варианта использования.

Нет, целостность данных — должна контролироваться в DAL и БД. Отствие записи с нужным ID — это исключительная ситуация, и DAL в таком случае должен выбрасывать исключение. И вот дальше уже да, дело бизнес-логики как обрабатывать это исключение.
Re[21]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.04.09 23:08
Оценка: +1 -1
Здравствуйте, VladD2, Вы писали:

VD>Потому что такие программы практически невозможно отлаживать. Они не структурны и нельзя делать предположения о их поведении.

VD>Та же фигня с исключениями. Они позволяют передавать управление не структурно. К тому же в дотнете нельзя описать, что метод возвращает исключение, а значит нельзя гарантировать, что исключение которое планировалось как обязательное для обработки таки будет обработано. В результате когда код становится большим, то отследить полеты исключений становится очень сложно.

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

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


Вообще-то тут и говорится про обработку ошибки. Ситуация считается ошибочной и для её, ошибочной ситуации, обработки используется исключение.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[29]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.04.09 18:07
Оценка: -1 :)
Здравствуйте, gandjustas, Вы писали:

G>Или тот же пример с городами: запросили сначала список городов с количеством кастомеров, потом запрашиваем катомеров из конкретного города. Между запросами другой пользователь поменял одному из кастомеров в город. Какая ссылочная структура поможет отследить изменение количества в двух городах?


В данном примере всё очень просто, надо считать агрегаты на клиенте, только на основе имеющихся у него данных. Тогда данные будут всегда целостными, хотя, возмодно, и устаревшими немного.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[19]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.04.09 18:22
Оценка: :))
Здравствуйте, IT, Вы писали:

A>>

This database-related article is a stub. You can help Wikipedia by expanding it.

Ты там учился?

IT>А ты вообще хоть где-нибудь учился?

Да, например, я на курсы вежливости ходил.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[27]: Проблемы организации OR-мапинга
От: Cyberax Марс  
Дата: 12.04.09 19:49
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

C>>1) Контроль доступа.

VD>И что с ним?
Сложно сделать на уровне чистых данных.

C>>2) Время синхронизации — у меня оповещения рассылаются меньше чем за секунду.

VD>А почему репликация данных не может работать с той же скоростью? Секунда — это довольно много.
Я не знаю технологий репликации, которые это бы обеспечивали.

C>>3) Простота клиента. У меня это просто приложение, которое пользователь запускает через WebStart. Пользователям не надо думать о файрволах, публичных IP и т.д.

VD>Причем тут клиент? У тебя ведь сервер данные кэширует? Мы вообще что обсуждаем? Может я вас не верно понял?
Именно клиент кэширует, которых одновременно может быть сотни штук.

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

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

То что ты предлагаешь — это примерно на уровне старых дельфийских программ.

C>>Представь, что у нас есть две таблицы Person (id, date_created) и PersonalDetails(id, parent_id, name, last_name). Мы делаем запрос "SELECT pers.id, det.name, det.last_name FROM Person pers, PersonalDetails det where pers.id=det.parent_id" и кладём его результаты в кэш.

VD>А зачем часто изменяемые данные кэшировать. Такие данные я буду запрашивать каждый раз.
Каждый запрос по WAN — это секунда, грубо говоря. Просто обязан кэшировать.

VD>Реч шла о чем-то что редко изменяется. Например о списке наменклатур. Бывает так, что они обновляются раз в месяц. В таких условиях тянуть описания продуктов из БД смысла нет. Хотя тоже стоит подумать, так как если этот список огромен, а каждый раз нужно вытаскивать всего 1-5 записей, то опять же кэш может оказаться бессмысленными.

Я вот хочу кэшировать и изменяемые данные. Можешь предложить вариант? Или таки признаешь, что ORM имеют существенные преимущества в ряде случаев?

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

Реплики БД — это исключительно кривой хак.

C>>Теперь на сервере у нас поменялся PersonalDetails (Мария Иванова вышла замуж и стала Марией Петровой, а инженер Василий поменял пол и стал Василией). Но обновить кэш корректно мы не можем! У нас в нём нет связи между этими таблицами.

VD>То на что ты намекаешь — это болезнь под названием заменить БД кэшем в сервере приложения.
И что дальше? Почему я должен молиться на БД и считать её недостяжимым идеалом, попытка повторить часть функций которого является величайшей дерзостью?

C>>Предлагай решения.

VD>Перестать дублировать работу сервера БД.
Не решение.
Sapienti sat!
Re[14]: Проблемы организации OR-мапинга
От: Tom Россия http://www.RSDN.ru
Дата: 12.04.09 19:55
Оценка: +1 :)
Здравствуйте, gandjustas, Вы писали:

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


A>>>QueryObject нужен для нетипичных запросов, типа запросов для отчётов. Использовать его для всего подряд просто неправильно.

Tom>>Тут соглашусь с Ромой
G>С чем соглашиься? С голословным утверждением?
G>Может тогда ты ответишь почему это "просто неправильно" ?

Потому что серебрянной пули на практике не бывает.
Если на все задачи по работе с данными у тебя есть один единственно правильный ответ, то что то тут не так.
Если не согласен предлагаю перейти от розового слоника в вакууме перейти на примеры. Обсуждать воздух очень тяжело.
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[13]: Проблемы организации OR-мапинга
От: Lloyd Россия  
Дата: 13.04.09 00:07
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Могут. Вот только какой смысл cоздавать DAL в котором все методы будут выглядеть так:

VD>
VD>X GetById(int id)
VD>{
VD>  return (from x in xs where x.id = id select x).Fitst(); 
VD>}
VD>...
VD>... GetById(GetId())
VD>

VD>если нам раз в год нужно получать что-то по id и постоянно нужно получать списки и обрабатывать их?

Как ни прискорбно это сознавать, но большинство разработчиков работает в сфере т.н. enterprise-приложений, а уж в них получение чего-то по id, изменение этого и запись обратно в базу — гораздо более частая операция, чем массовые изменения в базе.
Re[14]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 13.04.09 04:31
Оценка: +1 :)
Здравствуйте, Lloyd, Вы писали:

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


VD>>Могут. Вот только какой смысл cоздавать DAL в котором все методы будут выглядеть так:

VD>>
VD>>X GetById(int id)
VD>>{
VD>>  return (from x in xs where x.id = id select x).Fitst(); 
VD>>}
VD>>...
VD>>... GetById(GetId())
VD>>

VD>>если нам раз в год нужно получать что-то по id и постоянно нужно получать списки и обрабатывать их?

L>Как ни прискорбно это сознавать, но большинство разработчиков работает в сфере т.н. enterprise-приложений, а уж в них получение чего-то по id, изменение этого и запись обратно в базу — гораздо более частая операция, чем массовые изменения в базе.

А кто мехает для операции "получение чего-то по id, изменение этого и запись обратно в базу" использовать один Update, а не SELECT+Update+ оптимистичная блокировка+identity map+навороченный кеш?
Re[36]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 13.04.09 05:49
Оценка: :))
Здравствуйте, Cyberax, Вы писали:

IT>>Ну так в чём тогда проблема? Объективная реальность

C>Хочется чтоб всё быстро работало

Сделай чтоб работало быстро
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: Проблемы организации OR-мапинга
От: Lloyd Россия  
Дата: 13.04.09 17:38
Оценка: +1 -1
Здравствуйте, VladD2, Вы писали:

L>>Ну так объясни, как пожно сравнивать архитектурный подход с механизмом удаленного вызова. У меня это как-то слабо укладывается в голове.


VD>Тут есть одна проблема. Очень тяжело что-то объяснять тем кто не хочет понять. Тебе объяснить что-либо вообще почти не возможно. А я и так порядком подустал от этой дискуссии.


Конечно же воздержаться от личных выпадов ты, увы, не можешь.

VD>Объясняю на пальцах. Если не поймешь, значит не судьба... Дальше отвечать не буду.


VD>До SOA MS насился с DCOM как с писанной торбой и уговаривал всех, что это лучшее средство создания сетевых приложений. Но со временем ребята из МС поняли, что ООП в распределенной среде — это вилы. Хранить ссылки на объекты через сетку — это идиотизм. Вот и решили откатиться к старым схемам когда сервер всего лишь производит обработку информации и возвращает результата клиенту. Но старую идею не продать. Вот и извернулись придумав новую "архитектуру". За одно придумали SOAP и много других базвордов.


Только одна маленькая неувязочка у них вышла: спецификация SOAP воявился лет за несколько до того, как о SOA начали говорить.

VD>Многие (вот ты, например) купились на эту пиар. Но многие понимают, что никакой новой архитектуры не придумано, а все разговоры про компоненты не более чем булшит.


На этот булшит повелись также IBM, Oracle, SAP. Один только Влад устоял.

P.S. Ничего личного, но имхо, стоит все-таки ознакомиться с SOA, хотя бы на таком уровне чтобы не мешать его в одну кучу с RPC.
Re[6]: Проблемы организации OR-мапинга
От: mrTwister Россия  
Дата: 18.04.09 19:26
Оценка: -2
Здравствуйте, adontz, Вы писали:

A>Вовсе нет. Если я хочу получить конкретный элемент по идентификатору, этот элемент в базе должен быть. В противном случае, имеет место логическая ошибка: неправильное получение идентификатора элемента или состояние гонки. Отсутствие конкретного элемента и пустой список элементов очень разные ситуации.


Это зависит от того, откуда мы получаем идентификатор. Если идентификатор приходит откуда-то из-вне, то этому "далёку" будет положить на наше исключение. Например, какой смысл кидать пользователю исключение, если он ввел неправильный логин?
лэт ми спик фром май харт
Re[27]: Проблемы организации OR-мапинга
От: Lloyd Россия  
Дата: 19.04.09 20:11
Оценка: +1 -1
Здравствуйте, VladD2, Вы писали:

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


VD>Ниже же был пример.


Но в тестах его не было.

VD>>>
VD>>>def custs = linq <# from c in customers
VD>>>                    join e on in employees on c.ID == e.CustomerID
VD>>>                    select (e.FirstName, e.SurName) #>;
VD>>>def html = $<#<ul> ..$(custs; "\n"; (fName, sName) => $"<li>fName, sName</li>") </ul>#>;
VD>>>


L>>Не, так писать не модно еще со времен коассического ASP. Нынче рулит разделение на model-view-controller.


VD>Ну и? Коллекции customers и employees — это часть модели. Приведенный код — это реализация одного из представлений. Вместо последней строчки можешь подставить любую реализацию.


Этот код хорошо выглядит только тогда, когда он занимает соседние строчки.
На практике же будет совершенно иначе: запросам не место в представлении, он будут в контроллере.
Когда ты его вынесешь в контроллер, то окажется, что метод контроллера GetEmployees возвращает значения типа IEnumerable<(string * string)>.
А это уже приводит к сл. проблемам:
1. Тот кто будет пользоваться таким классом должен будет знать, что метод возвращает FirstName, LastName.
2. Тот, кто будет править GetEmployees должен будет проверить все места, де потенциально используется код и исправить его.
Прямо-таки классический пример сильной свзяности.

L>>Прятание запросов типа GetCuatomerByFitstName не обсуждается. Речь идет о сокрытии деталей маппинга полей сущностей на поля таблиц базы данных.


VD>А где ты видишь тут дтали отображения? В коде используются некие абстракные коллекции customers и employees. Они скрыват те самые детали отображения. Может они — это ХМЛ.


Раз ты удалил отквоченый текст, то напомню, о чем идет речь:

Например, некоторые параметры не хранятся один-в-один в полях таблицы, а сериализуются в xml-ную колонку. Наличие DAL-а позволяет этот механизм хранения скрыть от бизнеса, что, имхо, очень удобно и позволяет очень просто дополнять поля сущности.

Re[25]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 20.04.09 12:10
Оценка: -2
Здравствуйте, gandjustas, Вы писали:

A>>Нет, я не потребовал. Я показал, что кеширование отдельных запросов без преобразования в объекты приводит к несогласованности данных кешах запросов. А вот если собрать граф объектов, то такой несогласованности не будет.

G>Именно эта фраза подтевржадет то что кеш в ORM-системах может быть только глобальный.

Ты не прав Вполне можно построить ссылочноцелостное подмножество данных БД, по объёму значительно меньше данныхв БД.

G>Кажестся я уже описывал, что эта задача и другими способами нормально не решается.

G>Вообще если между двумя запросами свзязанных данных проходит какое-то время, то всегда можно нарваться на рассогласованность, и без пессимистичной блокировки этих данных в общем случае победить такое нельзя.

Ты опять таки не прав.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[41]: Проблемы организации OR-мапинга
От: EvilChild Ниоткуда  
Дата: 29.04.09 07:27
Оценка: +1 :)
Здравствуйте, vdimas, Вы писали:

V>Извини, коллега, но у тебя полная каша в голове — ты же смотришь тип результата, а не тип контруктора. Вот в HUGS:


V>
Main>> :t Three
V>Three :: a -> MyNum a
V>


Объясни мне какое значение имеют сигнатуры конструкторов в контексте нашего обсуждения.
Важны типы значения, которые они конструируют.
Мой поинт в том, что конструкторы конструируют значения одного типа.
Ты с этим согласен?

EC>>А то тип вроде один, а ты говоришь оприведении. К какому типу мы приводим, если он один?


V>Там я тебе ссылку дал в предыдущем сообщении. Не хочешь пройтись по ней?

Я в курсе что такое размеченное объединение.
Re[32]: Проблемы организации OR-мапинга
От: Sinix  
Дата: 20.04.09 08:10
Оценка: 93 (1)
Ага, всё так и есть

А на вэйварда я даже подписан, заодно с Bart De Smet. Кcтати, не читали блог последнего? Крайне забавные темы проскальзывают. Из моих любимых — прикручиваем linq ко всему и осло.
Re[7]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 04.06.09 04:34
Оценка: 38 (1)
Здравствуйте, ili, Вы писали:

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


        [SqlQuery(@"
            WITH Numbered AS
            (
                SELECT TOP (@startRecord + @maxRecords)
                    ROW_NUMBER() OVER (ORDER BY fm.updt DESC) RowNum,
                    fm.mid       ID_Message,
                    fm.subj      Subject,
                    fm.uid       ID_User,
                    fm.usernick  UserNick,
                    fm.nans      AnswerCount,
                    fm.updt      UpdateTime,
                    fm.lastone   LastMessageAuthor,
                    fm.gid       ID_Forum,
                    fg.ref       ForumShortName,
                    (SELECT sum(Rating) FROM   MessageRating WHERE ID_Topic = fm.mid)  Rating,
                    (SELECT Count(*) FROM self WHERE mid = fm.mid AND (dte > COALESCE(fm.last_moderated,0))) SelfCount,
                    fm.dte       [Date]
                FROM forum_tree fm 
                INNER JOIN AllowedReadGroups(@userID,0) fg ON fg.gid = fm.gid
                WHERE fm.tid=0
                    AND ((@nans IS NULL) OR (nans = @nans))
                    AND NOT EXISTS(SELECT 1 FROM forum_filter ff WHERE ff.gid=fm.gid AND uid=@userID)
                ORDER BY fm.updt DESC
            )
            SELECT * FROM Numbered WHERE RowNum BETWEEN @startRecord + 1 AND @startRecord + @maxRecords
            OPTION (MAXDOP 1)")]
        [DataSetTable("Message")]
        public abstract ForumDataSet GetAllPublicTopics(
            int userID,
            [ParamName("nans"), ParamNullValue(-1)] int nAnswers,
            int startRecord, int maxRecords);

        public virtual ICollection GetAllPublicTopicsEx(UserInfo user, IEnumerable<int> allowed, IEnumerable<int> skip, int nAnswers, int startRecord, int maxRecords)
        {
            using (var db = RsdnDataContext.Create())
            {
                var ucread = user.IsAnonym? UserRole.User: user.UserRole;

                var result =
                    from mt in db.MessageTrees
                        join f in db.Forums on mt.ForumID equals f.ForumID
                    where
                        mt.TopicID == 0 &&
                        f.ForumID > 0 &&
                        (f.UserReadLevel >= (short)ucread || allowed.Contains(f.ForumID)) &&
                        !skip.Contains(f.ForumID)
                    orderby mt.UpdatedOn descending
                    select new
                    {
                        ID_Message        = mt.MessageID,
                        Subject           = mt.Subject,
                        ID_User           = mt.UserID,
                        UserNick          = mt.UserNick,
                        AnswerCount       = mt.AnswerNumber,
                        UpdateTime        = mt.UpdatedOn,
                        LastMessageAuthor = mt.LastAnswerBy,
                        ID_Forum          = mt.ForumID,
                        ForumShortName    = f.Alias,
                        UserRole          = f.UserReadLevel,
                        Rating            = (from mr in db.MessageRatings where mr.ID_Topic == mt.MessageID select mr.Rating).Sum()
                    };

                if (nAnswers >= 0)
                    result = from r in result where r.AnswerCount == nAnswers select r;

                result = result.Skip(startRecord).Take(maxRecords);

                return result.ToList();
            }
        }


Первый метод как было, второй как стало.

В 95% работают следующие оптимизации:

— allowed.Contains устраняется,
— пейджинг превращается в TOP,
— проверка AnswerCount не делается.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 08.04.09 21:40
Оценка: 10 (1)
Здравствуйте, Tom, Вы писали:

Tom>Я предпологаю, что TSQL код у нас будет отделён от C# кода.

Tom>Тоесть в тесте писать запросы мы не будем РУКАМИ.
Tom>Но, C# враперы над TSQL запросами будут всё же строится динамически в рантайме.
Tom>Как это будет.

Tom>Допустим у нас есть каталог SQL где лежат файлы, в каждом из них для простоты допустиь ad hoc запрос, а не хранимка.

Tom>Во compile time мы будем выполнять их используь FMTONLY и получать метаданные о resultset-е.
Tom>По ним мы будем строить соответствующий класс для resultset-а и функцию для выполнения данного ad hoc запроса.
Tom>Естественно что в сгенерированном коде будет присуствовать само тело запроса поднятое из файла.

Tom>Зачем нужно хранить TSQL отдельно от кода — в первую очередь что бы иметь нормальную возможность провалидировать этот TSQL и рефакторить его отдельно от кода.

Tom>Например при помощи той же VSTS Database Edition GDR.

Tom>Можешь на примерах как то описать принципиальные ошибки в таком подходе?


Начнём с того, что всё это элементарно не имеет никакого смысла. Самое сложное в DAL — это рутина ручной набивки аксессоров, которая хоть так хоть эдак уходит. После этого при разработке, например, какой-нибудь формы или отчёта, на разработку SQL запроса уходит два часа, на DAL и BL пять минут, а на UI неделя. Ну давай добавим ещё две минуты на твой ad hoc класс. На неделю UI это всё равно никак не повлияет. Не там ты оптимизируешь.

Но допустим вы нагенерировали кучу ad hoc классов. Сразу возникает несколько вопросов.

1. Для запросов SELECT * FROM Person и SELECT * FROM Person WHERE ID = 1 у тебя будет генерироваться один класс или два?
2. Как ты собираешься задавать имена своим классам?
3. Все свои классы ты будешь хранить в одном namespace или в разных? Как это задавать?
4. Готов ли ты к тому, что основная работа твоего приложения будет заключаться в бессмысленном мапинге одних сущностей на другие?
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Проблемы организации OR-мапинга
От: Flem1234  
Дата: 10.04.09 12:40
Оценка: 10 (1)
Здравствуйте, Tom, Вы писали:

Tom>Опять двадцать пять. Этот проект мёртв. Ещё предложения? И что всё таки делать с linq & DML?


Есть такая штука IQToolkit.
Там и DML, и исходники и все что хочешь.
Re[28]: Nemerle & Real Life
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.04.09 19:38
Оценка: 10 (1)
Здравствуйте, Tom, Вы писали:

G>>3)Врмененные таблицы позаменять на табличные переменные

Tom>А чем это улучшит код?

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

G>>4)Для получения значений #tz можно использовать table-valued function

Tom>Не понял четно говоря.

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

G>>Желательно отказаться от операторов IF ELSE в TSQL коде и перенести выбор в клиентский код.

Tom>Обьясните почему? Почему в C# ты от if не отказываешься а в TSQL решаешь отказаться? Просто что бы уменьшить обьём кода в функции?

Ифы в TSQL-е императивный. В итоге вся процедура превращается в смесь запросов и императива. Ее надо или забить на несколько процедур, или переписать без ветвления (так чтобы были одни запросы).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Nemerle & Real Life
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.04.09 19:43
Оценка: 10 (1)
Здравствуйте, Tom, Вы писали:

IT>>Но это всё случаи из разряда два процента от всей работы с SQL и подход к ним отдельный. Хотя подумать над тем как генерировать на linq подобные скрипты всё же стоит.

Tom>Хорошо, пункт один — императивная логика. Мне правда пока не совсем понятно почему в TSQL её лучше не использовать, но возможно позже понимание придёт. Что ещё можно сделать что бы улучшить этот код. Влад например предлагал устранить временные таблицы и курсоры. насчёт курсоров конечно понятно что лучше без них. Насчёт временных таблиц я пока не уверен что тотальное их устранение улучшит понимание кода.

Еще (по уму) нужно устранить update-ы delete-ы во временных таблицах.
Если логика в коде процедуры будет фильтрующей, то ее будет значительно проще поддерживать и развивать. При этом тебе ну будут нужны уже все управляющие конструкции. Будет только входные данные, преобразование и выходные данные, которые и надо вставлять в таблицы.
Увидишь, что когда перепишешь так код, то упростится не только его отладка, но и понимание.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 14.04.09 02:31
Оценка: 6 (1)
Здравствуйте, MozgC, Вы писали:

MC>Скажи, а какой бы подход в работе с БД ты бы выбрал в случае не-MSSQL? Я так понимаю что как раз твой BLT?


На работе я работаю работу на Sybase. Использую понятное дело Булкит. DAL у меня сейчас самый простой слой, требующий минимум поддержки. Но всё же не хватает типизации для полного счастья, поэтому работаю над поддержкой linq в Булките. Там будет и Sybase и MS SQL и ещё минимум штук пять серверов.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Проблемы организации OR-мапинга
От: Tom Россия http://www.RSDN.ru
Дата: 09.04.09 14:33
Оценка: 5 (1)
Tom>>Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы.
Tom>>Когда мы пишем руками — мы не имеем ни первого ни второго.
IT>Как это не имеем? А как же Linq2Sql?
Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем. И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет.
Ну и опять это перенос в код запростов TSQL, хоть и не в явном виде, что опять же усложняет рефакторинг базы.
Который кстате намечается серьёзный.

И мы обсуждали проблемы моей кодогенерации а не линк. У линка заметь опять же своя кодогенерация. И для стор между прочим он генерирует resultset файл. Ну или акцэсор. Незнаю как лучше назвать.
Я проблем пока реальных на примерах так и не увидел. Есть некоторые нюансы конечно но шоу стоперов реальных я пока не вижу.

Tom>>Так же про проверку TSQL. Если он у тебя в коде — то ты вообще в полной засаде.

IT>В полной заднице ты только, если размазываешь SQL по всему коду в виде конкатенации строк. DAL как раз и был придуман, чтобы эту задницу существенно уменьшить. А если использовать linq, то задницы вообще никакой нет.
Размазывания в виде конткатенаций скорее всего ожидать не стоит, а вот размазывания по разным C# файлам и возможно сборкам вполне (это если писать TSQL в коде)
А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует.
Какой смысл себя ограничивать так? Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь.

IT>>>Но допустим вы нагенерировали кучу ad hoc классов. Сразу возникает несколько вопросов.


IT>>>1. Для запросов SELECT * FROM Person и SELECT * FROM Person WHERE ID = 1 у тебя будет генерироваться один класс или два?

Tom>>Два по умолчанию. Но будет возможность явно указать Entity класс.
IT>Каким образом?
Явным, в конфиге. Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты.

IT>>>2. Как ты собираешься задавать имена своим классам?

Tom>>По ими файла ad hoc запроса.

IT>Я думал, что по имени файла лучше именовать метод аксессора. Но допустим это будет имя возращаемого типа. Тогда такой вопрос. Как будет именоваться имя метода аксессора.

Я тут думаю тебе лечше посмотреть как это делает например тот еж линк для стор. В нашем случае имя файла ad hoc запроса будет играть роль имени базового на основе которого будут строится другие имена.

IT>Ваш метод возвращает информацию для одного типа, но в одном случае это Person, во втором List<Person>, в третьем Dictionary<int,Person>? Нужно ещё как-то уметь задавать возвращаемые значения как скалярные типы.

С скалярными значениями, их просто лучше избегать. Тем более что мы движемся в сторону ad hoc запростов вместо хранимок. А вот с тем возвращать ли коллекцию или один обьект — это хороший вопрос. На вскидку. Для таблицы будут генерироваться не только C# но и CRUD TSQL. Таким образом нам надо только таблица и мы по ней сможем сгенерировать SelectAll/SelectById/Insert/Delete/Update C# с TSQL-ем в нём. В этом случае мы чётко знаем что возвращается.
Задача сводится к тому как понять, что возвращает некоторый ad hoc/sp. Одну сущность или коллекцию.
Буду думать, возможно забиться на имя файла. Или опять же как то каталоги использовать.

Если тут подумать то имя файла/каталог/конфиг — всё это мета информация заданная просто разными способами.
Надо просто подобрать более удобный.

Хороший нюанс кстате. буду думать.

IT>>>3. Все свои классы ты будешь хранить в одном namespace или в разных? Как это задавать?

Tom>>Вариантов миллион. Самый простой при помощи каталогов. Если надо группировать запросы в namespace — создавай каталог.

IT>Понятно. В наличии у нас имя файла и имя каталога. А нужно имён в количестве: namespace, class name, method name, entity name. Плюс нужно выбрать метод Execute (ExecuteScalar, ExecuteList, ExecuteDictionary).

Игрь вопросы именования уже решаются в существующих framework-ах. И принципиальных проблем я не вижу тут. Ну будет базовое имя и на его основе будут строится другие имена. В чём сложность то?

IT>Готовься.

А я геморой и сзади не боюсь У меня на него стойкая имунная реакция выработалась за годы профессиональной деятельности
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[14]: Проблемы организации OR-мапинга
От: Tom Россия http://www.RSDN.ru
Дата: 10.04.09 11:24
Оценка: 5 (1)
VD>Я правильно понимаю, что твои претензии относятся к конкретным провайдерам, а не самому подходу linq в целом?
Нет. Сам подход, как ВЕКТОР мне нравится. Не нравится что это очередное недоделанное решение. Опять же возвращаясь к DML.
Я не против использовать линк если будет чётко ясно что;
1. Решение обеспечивает эволюционную модель развития приложения. Переписать всё с нуля — такой подход не работает
2. Я смогу перенести все текущие запросы и linq будет полностью хватать для обработки данных в нашей системе


Но если посмотреть реально на ситуацию то такого не произойдёт в ближайшем будущем.
Ибо, сама идея EF+linq 2 entity не правильная. А linq2sql мёртвая.
Вместо неё M$ надо было заняться обьектной базой и запросами к ней.
Вот тогда всё бы стало на свои места. Пишем себе на managed языке обьекты, сохраняим их в обьектнуцю БД и выбираем данные на том же языке на котором описаны сами данные.
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[11]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.04.09 21:04
Оценка: 5 (1)
Здравствуйте, VladD2, Вы писали:

A>>Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести.

VD>Ты уперся в свое однобокое представление. Если хочешь понять мои слова, тебе прийдется немного перестроить свое сознание. Заставлять тебя я точно не буду. Так что если не хочешь напрягать мыслительный аппарат, то продолжай повторять эту же мантру. Мешать не буду.

Влад, ты рассуждаешь так, как будто кроме DAL ничего нет. Что потом делать с твоими анонимными типами?

VD>Не надо отображать объекты на БД.


О как. И как ты представляешь связь тогда?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[27]: Проблемы организации OR-мапинга
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.04.09 03:28
Оценка: 4 (1)
Здравствуйте, EvilChild, Вы писали:

EC>А почему бы для reflection-based сценариев не расширить этот самый reflection: добавить к

EC>public bool IsAbstract { get; }
EC>public bool IsAnsiClass { get; }
EC>public bool IsArray { get; }
EC>public bool IsAutoClass { get; }
EC>ещё и
EC>public bool IsTuple { get; }
EC>?
Потому, что это не то что нужно. Посмотри, к примеру, на MVC Framework. Там нормальным является скормить в метод в качестве object какую-нибудь new {Category="Beverages", Page=12}. Этакая альтернатива Dictionary<string, object>. А потом внутри это добро исследуется при помощи рефлекшна.
Или там скармливаем IEnumerable<T> с анонимусами в какой-нибудь Grid, а он колонки автоматически по именам мемберов строит.

И всё это накроется в одночасье, как только анонимусы станут туплами. Потому, что "Beverages" превратятся в string Value1, а Page — в int Value2.
Альтернативой могло бы быть наследование анонимуса от тупла. А еще лучше — неявная реализация интерфейса ITuple<T1, T2, T3,...>, чтобы банальный рефлекшн вообще не находил унаследованных ValueN. Но там — свои приколы, связанные с совместимостью по присваиваниям. В том смысле, что мы вроде как ожидаем возможности неявно сконвертировать любой Tuple<string, int> в тип объекта, заданного new {Category="Beverages", Page=12}.
Сценарий конверсии — очень простой. Вот мы берем и получаем откуда-нибудь (например, из линка) некий ICollection<T>, где T — унаследован от Tuple<string, int>.
А в параметр нашего метода приезжает честный Tuple<string, int> (аноним, ессно, приехать не может — он невыносим за пределы метода). И мы его хотим к этой коллекции приклеить. Упс! Налицо жосткое нарушение type safety — некорректный даункаст. Потому что мало ли кто приехал к нам под видом Tuple<string, int>. Может, я там наследника передал.
Возможное решение — при конверсии конструировать новый экземпляр. Но это, опять же, чревато граблями из-за того, что преобразование перестанет сохранять идентичность.

Возможное решение этой проблемы — отказаться от идентичности, т.е. перейти к value-типам. В принципе, желание логичное, т.к. туплы по семантике и должны себя вести как value-типы.
Но тогда мы теряем (по крайней мере в текущем CLR) возможность наследоваться от них. В общем, получается какая-то дупа. Связанная, очевидно, именно с тем, что структурные типы не были включены в рассмотрение при проектировании CLR c самого начала.
Впрочем, я тут не самый умный — в CLR уже работает достаточно злая магия типа неявной реализации большого количества интерфейсов массивами, занятные правила ко/контравариантности для массивов и делегатов (а теперь и для интерфейсов), шаманства с Nullable... Так что, возможно, и придумают злую магию, которая сделает туплы рабочими.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[38]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 21.04.09 13:30
Оценка: 4 (1)
Здравствуйте, 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 может быть встроена в синтаксис и сделана семантически правильной.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.09 12:03
Оценка: 2 (1)
Здравствуйте, adontz, Вы писали:

A>ИМХО всё не так. Для GetById надо откуда-то взять этот самый Id. Отсутствие объекта это исключительная ситуация и никаким null тут и не пахнет. К тому же ты пропустил вариант "просто какие-то табличные данные", что весьма типично для отчётов.

Вы описываете то что относиться к бизнес-логике. От DAL в идеале нужно только получать IQueryable<T>, вызывать методы Delete, Update и Insert, которые также могут принимать IQueryable<T> в качестве удаляемых\изменяемых\вставляемых значений.

A>>>SQL из C# сгенерировать можно, но поддерживать это хозяйство сложно. Много чего приходится указывать вручную. Нет никакого нормального механизма обновления схемы без потери данных.

Tom>>Обновление схемы — это отдельный вопрос. Вопрос решаемый разными путями, предлагаю обсуждать не тут.
A>Я уже выше отписался, почему считаю этот вопрос актуальным.
Тем не менее этот вопрос никак не свзяан со способом работы с даными.
Re[14]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 12.04.09 03:40
Оценка: 2 (1)
Здравствуйте, adontz, Вы писали:

A>DAL отличается от бизнес-логики назначением. DAL поддерживает инфрастурктуру: целостность данных, транзакции, права доступа на уровне строк. А вот как этим всем пользоваться решает BL.


Ну да, я так и думал. Всё-таки каша в голове. Рома, DAL — это слой изолирующий работу с БД в терминах БД от остальной части приложения. Другими словами, в коде мы используем типизированные данные, а с БД вынуждены работать используя строковые константы. DAL был придуман иключительно как средство, позволяющее изолировать работу со строками в одном месте, которое будет легче контролировать. Всё! Другого назначения у DAL нет и никогда не было.

Аналогичный слой можно использовать не только для БД. Например, работу в вражеским веб-сервером тоже желательно завернуть в слой, переводящий доступ к сервису из терминов сервиса в термины нашего приложения.

Ключевое слово в DAL и подобных слоях — изоляция. А ты в своём определении DAL намешал в одну кучу всё подряд.
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.04.09 20:35
Оценка: 2 (1)
Здравствуйте, Tom, Вы писали:

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


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


G>>>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).

Tom>>>А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия?
G>>Могут, только это будет не DAL.
Tom>Чуш какая то. Почему это будет не DAL? Где то есть религиозные огроаничения? Что ты под DAL понимаешь?
Уровень абстракции с помощью которого я могу работать с данными в терминах языка программирования, а не SQL.

G>>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.

Tom>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.

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

Tom>От клиента до сервера БД. ТАк же как и в самих запросах. Так что эти разделения на BL/DAL предлагаю сразу забыть.

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

ЗЫ. Есдинственное что допускал из размазывания — перенесение некоторой части логики в функции\хранимки БД. Только с целью оптимизации.
Re[36]: Проблемы организации OR-мапинга
От: vdimas Россия  
Дата: 28.04.09 12:43
Оценка: 2 (1)
Здравствуйте, EvilChild, Вы писали:

V>>В функцию приходит значение размеченного объединения, которое суть пара: разметка + значение соответсвующего разметке типа. Объекты CLR представлены в куче аналогично, кстати. И насчёт "одного типа"... в случае алгебраических типов мы имеем 2 типа минимум: тип группы и хоть один тип участника группы.


EC>Объясни мне тогда поведение GHCi:


EC>

EC>*Main> :i MyNum
EC>data MyNum = One | Two
EC>*Main> :t One
EC>One :: MyNum
EC>*Main> :t Two
EC>Two :: MyNum


Для полноты картины надо было еще матчинг привести. В Хаскеле синтаксис минималистический — конструктор алгебраического типа выглядит так же как упоминание соотв. значения дискриминатора.

В этом примере One, Two — конструкторы алгебраического типа. Каждый из них конструирует обобщенный тип MyNum, заворачивая в него пустой тупл. Случай вырожденный, размеченное объединение для всех своих значений состоит из собс-но кода разметки и ничего более, т.е. такое использование близко к enum из C++ или C#.


V>>Не хочешь посмотреть на описание размеченных объединений в CORBA IDL и заодно посмотреть, что генерируют компиляторы на эти описания? А потом мы возьмем эти 3 примера: IDL, CLR и Хаскель, и посмотрим, что там происходит в процессе динамического определения типа.

EC>Хочу посмотреть, покажи.

Я предлагал тебе самому, но ладно.

Отрывок из произведений прошлых лет (IDL):
  enum ScriptType {
    eInstallExec,
    eInstallCopy
  };
  
  union InstInfoBody switch(ScriptType) {
      case eInstallExec: CommandExecInfoBody CommandExec;
      case eInstallCopy: CopyInstallInfo CopyInstall;
    };


В отличие от Хаскель дискриминатор описывается отдельно от объединения. Сомнительный бенефит в том, что зато его можно многократно исопльзовать.
CommandExecInfoBody и CopyInstallInfo — определенные выше в IDL типы (для нас не существенные).

В C# имеем (лишние подробности вырезал):
[Serializable, RepositoryID("IDL:EsdAgent/ScriptType:1.0"), IdlEnum]
public enum ScriptType
{
    eInstallExec,
    eInstallCopy
}

[Serializable, RepositoryID("IDL:EsdAgent/InstInfoBody:1.0"), IdlUnion]
public struct InstInfoBody : IIdlEntity, ISerializable
{
    // Fields
    private CommandExecInfoBody m_CommandExec;
    private CopyInstallInfo m_CopyInstall;
    private ScriptType m_discriminator;

    // Methods
    // приведу тело одного метода только
    public CommandExecInfoBody GetCommandExec() 
    {
        if (this.m_discriminator != ScriptType.eInstallExec)
            throw new BAD_OPERATION(0x22, CompletionStatus.Completed_MayBe);

        return this.m_CommandExec;
    }

    public CopyInstallInfo GetCopyInstall();
    public void SetCommandExec(CommandExecInfoBody val);
    public void SetCopyInstall(CopyInstallInfo val);

    // Properties
    public ScriptType Discriminator { get; }
}


Для С++ компилятором IDL генерируется аналогичная структура.

Как этим пользоваться в отсутствии паттерн-матчинга? Непосредственный switch/case по Discriminator:
    switch(instInfoBody.Discriminator) {
    case ScriptType.eInstallExec:
        CommandExecInfoBody exec = instInfoBody.GetCommandExec();
        ...
        break;
    }


Теперь, если вернуться вообще к самому началу... В C# "дискриминатор" нам предоставляется самой CLR посредством GetType(). Он один на всех.
Как делать switch по типам, при отсутствии такой возможности в языке (если рассматривать обычные типы, а не генерённые IDL-компилятором)? Так же как и во всех других языках, где нет аналога swicth, т.е. через цепочки if/else.

Покажу для C++/CLR, т.к. там удобная возможность определения переменных и одновременной проверки на null:
if(Type1^ var1 = dynamic_cast<Type1>(obj)) { 
    // use var1 here ...
} else if (Type2^ var2 = dynamic_cast<Type2>(obj)) { ... }
} else { ... }


Если в паттерн матчинге оставить только одну строку, а все остальные варианты обозначить как "_", то как раз в аналогичный if/else и вырождается:
(не уверен в точности синтаксиса)
case obj of
    (Type1 var1) -> ...
    (_) -> case obj of 
        (Type2 var2) -> ...
        (_) -> ...


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

Да, алгебраические типы — очень удобная модель как раз для тех задач, где мы сегодня используем динамическое приведение в языках без оного. Внутренний механизм идентичен (даже для Хаскеля), но степень контроля компилятором значительно выше.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[24]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.05.09 15:28
Оценка: 2 (1)
Здравствуйте, dimgel, Вы писали:

VD>>Но такая фича не поддерживается в дотнете. По этому даже ФЯ реализованные на дотнете не поддерживают записей (по крайней мере в полной мере).


D>В скале эта фича есть, скала может компилироваться в .NET. Проблема выруливается на этапе компиляции преобразованием (1, "1") в new Tuple2<Int,String> (1, "1"). На данный момент поддерживаются до Tuple22.


Tuple — это кортеж. Речь же шла о записи — record. Запись это, можно сказать, кортеж с именованными полями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.04.09 12:33
Оценка: 1 (1)
Здравствуйте, Tom, Вы писали:

Tom>Нет. Сам подход, как ВЕКТОР мне нравится. Не нравится что это очередное недоделанное решение. Опять же возвращаясь к DML.


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

Tom>Я не против использовать линк если будет чётко ясно что;

Tom>1. Решение обеспечивает эволюционную модель развития приложения. Переписать всё с нуля — такой подход не работает

Ну, уж тут придется что-то делать. Понятно, что по мановению волшебной палочки TSQL не превратится в linq.
Можно переписывать проект по мере необходимости. Скажем встала задача изменить то-то и то-то, меняем связанную с этим реализацию на linq...

Tom>2. Я смогу перенести все текущие запросы и linq будет полностью хватать для обработки данных в нашей системе


Это само собой разумеется. Кроме CTE (т.е. рекурсивных запросов) все остальное на linq переносится.

Tom>Но если посмотреть реально на ситуацию то такого не произойдёт в ближайшем будущем.

Tom>Ибо, сама идея EF+linq 2 entity не правильная. А linq2sql мёртвая.

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

Подходы в общем-то чем-то похожи. Оба имеют цель сделать собственное решение. Но твой подход — это половичатое решение которое по любому создаст кучу проблем.
Реален ли твой подход? Наверно — да! Но лично мне он не нравится.

Tom>Вместо неё M$ надо было заняться обьектной базой и запросами к ней.


Ну, чем им там надо было бы заняться не нам с тобой решать. А то в этом форуме было бы более уместно обсудить вопрос почему МС развивает C# и F#, а не Nemerle. Казалось бы многие задаются этим вопросом, а в МС даже ответить на него не хотят.

Тем более, что вопрос ООБД крайне спорный. Я не считаю ООБД перспективной идеей. ООП банально более примитивная технология нежели ФП. Современные СУБД гораздо ближе к ФП и потому их средства обработки данных (запросы) намного мощнее.

Tom>Вот тогда всё бы стало на свои места. Пишем себе на managed языке обьекты, сохраняим их в обьектнуцю БД и выбираем данные на том же языке на котором описаны сами данные.


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

Задумайся над тем почему ты исползуешь транзакт, а не пишешь все на С#? Или даже поставим вопрос так. Почему ты в транзакте используешь SQL?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 11.04.09 21:55
Оценка: 1 (1)
Здравствуйте, adontz, Вы писали:

A>Стоп, а разве я описываю объектную модель? Вовсе нет. Я описываю сущности. Как может специалист предметной области не разбираться в сущностях?


Специалист предметной области может разобраться в том, что такое сущность. Но только при одном условии, если сущность называть Data Type и представлять их в виде таблицы в ворде с колонками типа Name, Type (не int, string, data, а число, строка, дата), Range, Validation Rules и т.п.
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.04.09 17:05
Оценка: 1 (1)
Здравствуйте, Lloyd, Вы писали:

L>Ну так объясни, как пожно сравнивать архитектурный подход с механизмом удаленного вызова. У меня это как-то слабо укладывается в голове.


Тут есть одна проблема. Очень тяжело что-то объяснять тем кто не хочет понять. Тебе объяснить что-либо вообще почти не возможно. А я и так порядком подустал от этой дискуссии.

Объясняю на пальцах. Если не поймешь, значит не судьба... Дальше отвечать не буду.

До SOA MS насился с DCOM как с писанной торбой и уговаривал всех, что это лучшее средство создания сетевых приложений. Но со временем ребята из МС поняли, что ООП в распределенной среде — это вилы. Хранить ссылки на объекты через сетку — это идиотизм. Вот и решили откатиться к старым схемам когда сервер всего лишь производит обработку информации и возвращает результата клиенту. Но старую идею не продать. Вот и извернулись придумав новую "архитектуру". За одно придумали SOAP и много других базвордов. Многие (вот ты, например) купились на эту пиар. Но многие понимают, что никакой новой архитектуры не придумано, а все разговоры про компоненты не более чем булшит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Проблемы организации OR-мапинга
От: Cyberax Марс  
Дата: 20.04.09 05:37
Оценка: 1 (1)
Здравствуйте, Sinclair, Вы писали:

C>>1) Бывают "толстые" клиенты.

S>И как это противоречит модели кэширования, не построенной на PK? Ты, собственно, пытаешся изобрести на коленке то, что в мире СУБД называется Replication based on log shipping.
Ага.

S>А я пытаюсь объяснить то, что кэш вовсе не обязан воспроизводить структуру серверной БД, и log shipping — не единственное решение для обновлений кэша.

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

C>>2) Запрос на сервер — это заметная латентность.

S>А это тут причём? Если есть обновления — их нужно как-то передать. Кто-то предполагает, что log shipping превысит скорость света и станет работать без латентности?
Нет. Я для большинства целей обхожусь локальными запросами, которые работают с репликой БД. Соответственно, нулевая латентность.

S>Нет, он работает по ровно тому же каналу. Вот только надо постараться, чтобы он не реплицировал лишних данных — я уже приводил пример про потребление трафика аутлуком.

Outlook реплицирует всю базу целиком. У меня реплицируется только working set.

C>>А точо работало?

S>Еще как. Я тогда уверовал в ORM как в манну небесную.
S>Вот только мы никак не могли нужную производительность получить — работало всё только на синтетических примерах. Ну, то есть тогда сто мегабит были дорогой редкостью.
Ха! У меня приложение работает прекрасно даже на модеме. Благодаря тому, что на сервер обращения идут очень редко, а объём меняющихся данных весьма мал.

Собственно, у меня приложение специально заточено для работы на неустойчивых каналах — пришлось даже для этого свой протокол RPC делать. Я об этом как-то писал.
Sapienti sat!
Re[7]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 09.04.09 13:47
Оценка: +1
Здравствуйте, Tom, Вы писали:

Tom>Да, но ты забываешь про поддержку.


Я как раз о ней и говорю.

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

Tom>Сейчас я думаю у нас около тысячи OLEDB акцэсоров, и поверь мне это один из самых геморойных мест проекта.

От тысячи аксессоров мне не страшно. Во-первых, много в программировании это не всегда хорошо, а чаще совсем наоборот. Во-вторых, как я уже говорил, главное устранить набивку кода внутри аксессоров. А это можно сделать разными способами.

Tom>Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы.

Tom>Когда мы пишем руками — мы не имеем ни первого ни второго.

Как это не имеем? А как же Linq2Sql?

Tom>Так же про проверку TSQL. Если он у тебя в коде — то ты вообще в полной засаде.


В полной заднице ты только, если размазываешь SQL по всему коду в виде конкатенации строк. DAL как раз и был придуман, чтобы эту задницу существенно уменьшить. А если использовать linq, то задницы вообще никакой нет.

IT>>Но допустим вы нагенерировали кучу ad hoc классов. Сразу возникает несколько вопросов.


IT>>1. Для запросов SELECT * FROM Person и SELECT * FROM Person WHERE ID = 1 у тебя будет генерироваться один класс или два?

Tom>Два по умолчанию. Но будет возможность явно указать Entity класс.

Каким образом?

IT>>2. Как ты собираешься задавать имена своим классам?

Tom>По ими файла ad hoc запроса.

Я думал, что по имени файла лучше именовать метод аксессора. Но допустим это будет имя возращаемого типа. Тогда такой вопрос. Как будет именоваться имя метода аксессора. Как вы будете решать такую проблему. Ваш метод возвращает информацию для одного типа, но в одном случае это Person, во втором List<Person>, в третьем Dictionary<int,Person>? Нужно ещё как-то уметь задавать возвращаемые значения как скалярные типы.

IT>>3. Все свои классы ты будешь хранить в одном namespace или в разных? Как это задавать?

Tom>Вариантов миллион. Самый простой при помощи каталогов. Если надо группировать запросы в namespace — создавай каталог.

Понятно. В наличии у нас имя файла и имя каталога. А нужно имён в количестве: namespace, class name, method name, entity name. Плюс нужно выбрать метод Execute (ExecuteScalar, ExecuteList, ExecuteDictionary).

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

Tom>Не готов и очень хочется этого избежать.

Готовься.
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Проблемы организации OR-мапинга
От: Tom Россия http://www.RSDN.ru
Дата: 09.04.09 14:39
Оценка: +1
IT>Разные поля, используемые в запросе, а не значение параметра. Редко, но бывает нужно.
А, понятно, дело в том что от обезьяны с гранатой спасения нет.
Особенно если туда ещё и условие присобачить.
Но и задачи спастить от идиота не ставится.
Ну и у нас код ревью есть абсолютно всех changeset-ов.
Такое можно вылавливать.

Tom>>>>А по поводу генерации прямо в коде, тут есть свои за и против.

Tom>>>>Скажем так, я против того что бы такой подход использовать повсеместно, но как исключение из правила — почему нет
IT>>>Почему против, какие аргументы?
Tom>>Да я вроде уже не раз писал аргументы, тут например Re[11]: Nemerle &amp; Real Life
Автор: IT
Дата: 09.04.09


IT>Это ссылка на моё сообщение.

Акела промахнулся. Моё рядышком.

Tom>>основная причина разделения C# и TSQL кода — это вопросы поддержки.

Tom>>Когда TSQL живёт внутри C# эта поддержка на порядок усложняется.
Tom>>А так же исчезает compile time проверка этого TSQL.

IT>Это ты про то как у вас было раньше или у тебя есть реальный опыт использования этого в других условиях, особенно с linq?

Конечно из жизни. Тяжёлой и горькой Если хочешь можно с примерами. С линком есть опыт но небольшой и не менее горький.
В наших проектах он не применим из за убогости. да и смысла применять мёртвый проект я не вижу.
Ну и опять же это перенос TSQL в не явном виде в код. Что полюбому усложняет поддержку рефакторинг.
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[12]: Проблемы организации OR-мапинга
От: Tom Россия http://www.RSDN.ru
Дата: 10.04.09 10:37
Оценка: +1
VD>Я их не создаю, так что мне их рекламировать нет проку.
VD>Использовать можно любой. EF и Linq2sql вполне рабочие решения.
VD>Когда IT доделает свой провайдер, то скорее всего он будет более предпочтителен, так как его не сложно будет оснастить поддержкой DML.
И всё же, какой провайдер ты предлагаешь использовать СЕЙЧАС. Не завтра и не после завтра, а сейчас?

VD>Одни говорят (давно), а другие делают. Улавливаешь разницу?

А я по твоему ничего не делаю? Просто ты волен заниматсья тем что тебе интересно, а мне приходится работать в реальных проектах с большой и многолетней историей (более 15 лет) и огромный количеством кода. Если формально посчитать — то более 100 мегабайт.

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

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

VD>К тому все описанное тобой — это ваши проблемы. Вы сами создали себе условия и рамки.

VD>Насколько я знаю тот же IT использует в старых проектах BLToolkit + linq и работает над собственным linq-провайдером.
VD>В следующем проекте он просто возьмет свой новый провайдер и избавится ото всех компромиссов.
VD>Вы же так и будете убеждать себя, что других путей нет.

VD>Хинты — это не возможности SQL-я. Это средства оптимизации. Оных можно добиться и без хинтов.

VD>Более того, IT тебе не зря указывал на то, что запрос переписанный из монолитного SQL-я в ряд linq-азпросов решил проблему производительности в одном из мест нашего сервера. Так что многие хинты просто не будут нужны.

VD>В итоге ты так и не показал где же мы теряем в мощности при использовании linq-а. Сдается мне, что дело в другом. linq просто нужно уметь готовить. Он требует других подходов, другого менталитета.

Я тебе обьяснил чего нету в линке. Ты это услышать не захотел. Если не понятно — читай выше.

VD>>>TSQL — это гремучая смесь обычного SQL, который практически идентичен linq по функциональности, и совершенно чудовищного императивного языка программирования родом из мезозоя. Зачем над собой издеваться и использовать это палеонтологическое чудо?

Tom>>Потому, что это основной язык который развивает поставщик БД. Я может и не в восторге но другой альтернативы нет пока.
VD>Что, простите, развивает? Да он реально не развивается вот уже 10 лет. Так мелкие примочки добавляют при полностью гнилой базе.
Какие примочки и причём тут гнилапя база? Для MS SQL Server — а единственный язык общения — это TSQL.

VD>При этом тот же "поставщик" предлагает конкретное решение — linq + современные дотнет-языки. И это решение действительно развивается.

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

Tom>>И единственный на сегодняшний день язык который обладает полной мощью для соответствующей БД.

VD>Он обладает полной немощью как язык программирования. Этого одного уже достаточно чтобы его никогда не применят. А sql прекрасно коррелирует с linq. Единственная проблема DML, но она как раз решаема.
Влад, ты какой нибудь другой язык который понимает SQL сервер?
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[14]: Проблемы организации OR-мапинга
От: Tom Россия http://www.RSDN.ru
Дата: 10.04.09 10:50
Оценка: +1
VD>Там нет ни одного пункта интересующего мнея. BLToolkit меня интересует так же слабо как твои идеи размещения запросов в отдельных файлах.
VD>Лучшим подходом, на мой взгляд, является размещение запросов в виде встроенного (типизированного) DSL внутри кода приложения. Короче говоря подход а-ля linq.
Такой DSL уже есть. Называется TSQL. Можешь пояснить как может выглядеть собственный DSL для работы с данными? Что принципиально будет в нём отличного от того же TSQL?

VD>Согласен, что серьезные проблемы, но, на мой взгляд, разумнее устранить их нежели заниматься скрещиванием TSQL, C# и текстовых файлов.

Я попробую всё же, ибо пока другого решения я просто не вижу.
Думаю первый же гемор будет давольно скоро (на этих выходных например , ) попробую потом свой опят описать.

PS
linq по многим причинам не подходит как полноценное и всеобьемлющее решения для работы с данными. Пока он не дорос.
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[18]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.04.09 14:57
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Ключевое слово тут "entity". Entity и объект — это не одно и то же. EF ушел не туда в некоторых областях, но темнеменее его дизайн строится на основе модели данных. Я еще в 1995-ом проектировал БД с использованием EF-Win. Это такой Entity-моделлер. Поверь в EF-Win не было ни слова про объекты. Так же и в EF.

Только программка называется ER-Win, хотя работа в ней очень похожа на работу в дизайнере EF.
Re[19]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.04.09 15:44
Оценка: +1
Здравствуйте, Tom, Вы писали:

VD>>С использованием грязных хаков.

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

VD>>Кстати, о причках. В Nemerle есть кортежи которые без проблем возвращаться из методов. Плюс есть локальные функции для которых есть вывод типов. Так что даже LINQ-ом и то из него проще пользоваться.

Tom>Я кстате так и не понял почему анонимый тип в C# нельзя явно обьявлять. Как в других человеческих языках. (((
Наверное потому что он будет неанонимным
Наверное имеется ввиду вывод типов для возвращаемых значений методов класса.
Re[19]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.04.09 16:20
Оценка: +1
Здравствуйте, Tom, Вы писали:

Tom>изврат конечно


Несомненно.

Tom>Я кстате так и не понял почему анонимый тип в C# нельзя явно обьявлять. Как в других человеческих языках. (((


Аналог анонмных типов в ФЯ — это записи. Запись — это кортеж с именованными полями. Проблема в том, что кортежи и записи в ФЯ имеют так называемую структурную идентичность. Это значит, что два объекта сравнимы если у них одинаковый набор полей и у всех полей совместимые (соответственно) поля.

В дотнете структурная совместимость не поддерживается. Посему типы объеявленные в разных сборках являюся разными типами. Да и имена у них обязаны быть обязательно, а типы с разными именами тоже разные (даже если структурно они эквивалентны).

В общем, не поддерживает дотнет эту фичу.

Во времена когда шла работа над 3.5-ым фрэймворком Хейльсберг говорил, что им, мол, не дают им бедным менять рантайм. А то бы они давно сделали экспорт анонимных типов... Вот только в 4-ом дотнете, где будет новый рантайм, все равно ничего для поддержки структурной идентичности сделано не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 10.04.09 18:02
Оценка: +1
Здравствуйте, Tom, Вы писали:

Tom>Вот что исходники откроют я верю. Как раз из за проблем поддержки. Что бы спихнуть её на комьюнити. Но без открытия исходников компилятора нормально линк развивать не получится.


Компилятор то тут при чём?
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 10.04.09 18:24
Оценка: +1
Здравствуйте, Tom, Вы писали:

Tom>
Tom>{string, int} t = new {Name="", 123}
Tom>


Tom>Плюс от такого подхода очевиден?


Поздравляю, ты только что изобрёл tuple Только в Немерле он записывается так string * int.
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Проблемы организации OR-мапинга
От: dotneter  
Дата: 10.04.09 22:05
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Вот только в 4-ом дотнете, где будет новый рантайм, все равно ничего для поддержки структурной идентичности сделано не будет.

И еще раз http://channel9.msdn.com/pdc2008/TL02/
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[17]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.09 06:55
Оценка: +1
Здравствуйте, vdimas, Вы писали:

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



VD>>Тем более, что вопрос ООБД крайне спорный. Я не считаю ООБД перспективной идеей. ООП банально более примитивная технология нежели ФП. Современные СУБД гораздо ближе к ФП и потому их средства обработки данных (запросы) намного мощнее.


V>От ООБД можно взять "типизированность" кортежей. Да и вообще, побольше бы типизированности всего. Просто есть что-то не то в том, что по union можно в один столбец явно, или по ошибке склеить числовые и строковые данные, и никто не тебе ругнётся на это.

Да ну? Вообще-то компилятор запроса ругается при таком раскладе.
SQL вообще говоря типизированный, только проверка типа осуществляется гораздо позже, чем хотелось бы программисту.
Re[17]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.04.09 08:58
Оценка: +1
Здравствуйте, vdimas, Вы писали:

V>От ООБД можно взять "типизированность" кортежей. Да и вообще, побольше бы типизированности всего.


Типизированность (Что за слова дурацкое? Лучше сказать "Строгая статическая типизация") она никакого отношения к ООП не имеет. Возьми Руби, Смолток и иже с ними. Там типизация слабая и динамическая. При этом поддержка ООП на высшем уровне.

Если уж нужна мощьная типизация в БД, то стоит обратить внимание на системы типов МЛ-подобных языков и на Хаскель. Вот только последний склеить с современными ООЯ будет еще сложнее.
Хотя как раз система типов МЛ ложится на БД просто замечательно.

Так что если и говорить о новых видах БД, то скорее нужно говорить о функциональных БД — ФБД, а не ООБД.

V>Просто есть что-то не то в том, что по union можно в один столбец явно, или по ошибке склеить числовые и строковые данные, и никто не тебе ругнётся на это.


Это вопрос строгости типизации. Есть СУБД которые не позволяют этого сделать. То что MS SQL имеет довольно слабую (и откровенно говоря дряхлую и кривую) систему типов — это проблемы Microsoft и от части Sybase, а не РСУБД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.04.09 09:14
Оценка: +1
Здравствуйте, Tom, Вы писали:

Почитал дискуссию, не согласен со всеми
Суть задачи в том, чтобы сгенерировать DAL и немножечко бизнес логики (ну сколько получится). DAL в свою очередь, грубо говоря, состоит из SQL и C#. При этом почему-то ошибочно предполагается что C# или SQL могут хранить всю информацию, необходимую для генерации части на другом языке или даже могут это делать удобно. Враки это всё. Хуже того, сгенерировать DAL это пол-беды, надо уметь удобно переезжать со старой версии на новую, модифицируя схему БД.

C# генерировать из SQL нельзя по той простой причине, что SQL менее типизирован и понять что именно возвращает запрос: один объект, список объектов предопределённого типа, просто какие-то табличные данные, нельзя. К тому же сам SQL, как способ описания сущностей, неприемлем. Один объект может храниться в нескольких таблицах, связи между объектами (FK) устанавливаются не очень удобно и не несут однозначного смысла.

SQL из C# сгенерировать можно, но поддерживать это хозяйство сложно. Много чего приходится указывать вручную. Нет никакого нормального механизма обновления схемы без потери данных.

DAL не просто можно, его обязательно нужно генерировать. Но не C# из SQL или SQL из C#. И то и другое надо генерировать из третьего, более приспособленного для хранения условий задачи, источника.м
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[5]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.04.09 12:09
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

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


A>>ИМХО всё не так. Для GetById надо откуда-то взять этот самый Id. Отсутствие объекта это исключительная ситуация и никаким null тут и не пахнет. К тому же ты пропустил вариант "просто какие-то табличные данные", что весьма типично для отчётов.

G>Вы описываете то что относиться к бизнес-логике.

Вовсе нет. Если я хочу получить конкретный элемент по идентификатору, этот элемент в базе должен быть. В противном случае, имеет место логическая ошибка: неправильное получение идентификатора элемента или состояние гонки. Отсутствие конкретного элемента и пустой список элементов очень разные ситуации.

A>>Я уже выше отписался, почему считаю этот вопрос актуальным.

G>Тем не менее этот вопрос никак не связан со способом работы с данными.

Методы работы с БД должны учитывать возможность изменения схемы. Использовать другие методы, значит отрицать возможность рефакторинга БД и, тем самым, существенно его удорожать.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[5]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.04.09 13:28
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


Влад, ну ты вместо аргументированного ответа решил задеть собеседника? Когда нечего сказать по существу, лучше вообще не писать.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[7]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.04.09 14:39
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Взять хотя бы утверждение "SQL менее типизирован и понять что именно возвращает запрос: один объект, список объектов предопределённого типа, просто какие-то табличные данные, нельзя".

VD>1. В РСБУД и в SQL вообще нет объектов. Стало быть разговор о их возврате — это ээ... ну, сам придумай как это по мягче назвать, в общем.

Объектов нет, есть записи (record) — строки таблиц имеющие определённые поля (field). По видимой форме массив структур Си и таблица SQL принципиально не отличаются. Однако, SQL позволяет делать довольно нехорошую, с точки зрения ORM, вешь — возвращать часть записи. Да и целая запись не подарок. Даже установив конкретный формат возвращаемых запросом данных, однозначно определить тип C# на который надо произвести отображение нельзя.

VD>2. Утверждение о нетипизированности запросов стоило бы обосновать. Оно явно не верно, но без твоего обоснования я должен тратить свои силы на обоснование очевидного факта.


Я ответил выше — результаты запроса никак не могут быть связаны с типом C#, попросту не хватает информации.

VD>3. Запрос, в РСУБД, всегда возвращает список записей (они не даром так называются, запись это кортеж с именованными полями). Единичное (скалярное) значение не более чем частный случай — список состоящий из одной записи которая в свою очередь состоит из одного элемента (поля).

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

Проблема и ещё какая.

VD>Теперь о причинах по которым тебе тяжело будет объяснить почему ты не прав.

VD>Дело в том, что ты исходишь из узкого и не верного трактования действительности. Ты смотришь на доступ к данным через призму ООП-теории. Этот взгляд не может привести к пониманию обсуждаемого в данной теме. Отсюда все разговоры о выборе объектов из базы. О каких то там связях частей объектов и т.п.
VD>Так что первое что нужно понять для понимания этой темы — в БД нет объектов. И мы просто предлагаем вместо работы с объектами в БД, работать с данными вынимаемыми из БД и размещаемыми структурах удобных для обработки в прикладном языке программирования.

Влад, я искрене рад, что у тебя достаточно богатая фантазия и ты придумал объективную реальность.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[6]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.09 18:11
Оценка: +1
Здравствуйте, adontz, Вы писали:

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


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


A>>>ИМХО всё не так. Для GetById надо откуда-то взять этот самый Id. Отсутствие объекта это исключительная ситуация и никаким null тут и не пахнет. К тому же ты пропустил вариант "просто какие-то табличные данные", что весьма типично для отчётов.

G>>Вы описываете то что относиться к бизнес-логике.

A>Вовсе нет. Если я хочу получить конкретный элемент по идентификатору, этот элемент в базе должен быть. В противном случае, имеет место логическая ошибка: неправильное получение идентификатора элемента или состояние гонки. Отсутствие конкретного элемента и пустой список элементов очень разные ситуации.

"получить конкретный элемент по идентификатору" относится к бизнес-логике, а не к доступу к данным. Абстракции над БД должно быть абсолютно пофиг что ты хочешь сделать с возвращаемыми данными.
DAL должен обеспечивать возможность получить последовательность элементов, соотвествующих некоторым условиями фильтрации\проекции\группировки.

A>>>Я уже выше отписался, почему считаю этот вопрос актуальным.

G>>Тем не менее этот вопрос никак не связан со способом работы с данными.

A>Методы работы с БД должны учитывать возможность изменения схемы. Использовать другие методы, значит отрицать возможность рефакторинга БД и, тем самым, существенно его удорожать.

Хоть убей не пойму зачем тому же IQueryable учитывать возможность рефакторинга БД.
Re[8]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.04.09 18:27
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>Объектов нет, есть записи (record) — строки таблиц имеющие определённые поля (field). По видимой форме массив структур Си и таблица SQL принципиально не отличаются. Однако, SQL позволяет делать довольно нехорошую, с точки зрения ORM, вешь — возвращать часть записи. Да и целая запись не подарок. Даже установив конкретный формат возвращаемых запросом данных, однозначно определить тип C# на который надо произвести отображение нельзя.


Как все запущено!
Рама, забудь свои знания С. Они тут тебе не помогут.
"Запись", о которой я говорил — это тип данных, а не понятие из РСУБД (где, впрочем они рассматриваются так же, прост ты не привык). Запись есть набор разнотипных именованных значений. Скажем в C# 3.0 ей аналогичны анонимные типы. Не полностью аналогичны, правда... с ограничениями... но все же для возврата значений из БД анонимных типов более чем достаточно.

Так что нет никаких "частей записи". Это и есть запись. Только другая. Запрос просто преобразует набор одних записей (возможно даже множество наборов) в другой набор других записей.
А ты не можешь понять это потому, что смотришь через призму объектов и ООП.
Вот тебе и мерещатся объекты получаемые соединением по FK и другая ерунда.

A>Я ответил выше — результаты запроса никак не могут быть связаны с типом C#, попросту не хватает информации.


Очень смешно!

VD>>3. Запрос, в РСУБД, всегда возвращает список записей (они не даром так называются, запись это кортеж с именованными полями). Единичное (скалярное) значение не более чем частный случай — список состоящий из одной записи которая в свою очередь состоит из одного элемента (поля).

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

A>Проблема и ещё какая.


С удовольствием послушаю обоснование. Особенно это интересно в контексте linq.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.04.09 19:46
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>Сам факт обработки некоторой выборки уже относится к BL, для DAL достаточно вернуть выборку в удобном для обработки виде.


Так, ещё раз. Если я говорю "Найди мне клиента по имени Иван" (FindByFirstName), а Вани нет, то это нормальная ситуация. Если я говорю, "верни мне клиента с идентификатором {356F893B-68B3-4687-906B-0A50DD1612C1}" (GetById), а клиента с таким идентификатором нет, то что-то очень серьёзно не так, потому что нарушена целостность данных. Например, заказ ссылается на клиента через идентификатор, а клиента с таким идентификатором нет. Сохранение ссылочной целостности данных в компетенции DAL. Нельзя стирать клиента на которого оформлены заказы. Поэтому GetById, если ничего не найдено, выкидывает исключение. Про orphan records слышал?

G>>>Хоть убей не пойму зачем тому же IQueryable учитывать возможность рефакторинга БД.

A>>IQueryable не надо, надо методике доступа к БД, которая включает в себя Linq.
G>Linq = IEnumerable\IQueryable + extension methods + anonimous types + object initializers + sql-подобный синтаксис.
G>Для полноценной работы с данными не хватает только DML — insert\update\delete.
G>Зачем этому всему учитывать возможность рефакторинга БД?

А зачем вообще учитывать возможность рефакторинга, вне контекста Linq?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[10]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.09 20:00
Оценка: +1
Здравствуйте, adontz, Вы писали:

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


VD>>Рама, забудь свои знания С. Они тут тебе не помогут.

VD>>"Запись", о которой я говорил — это тип данных, а не понятие из РСУБД (где, впрочем они рассматриваются так же, прост ты не привык). Запись есть набор разнотипных именованных значений. Скажем в C# 3.0 ей аналогичны анонимные типы. Не полностью аналогичны, правда... с ограничениями... но все же для возврата значений из БД анонимных типов более чем достаточно.

A>Анонимные типы, очень хорошая аналогия, только пользы от них в данном случае никакой нет. Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести.


Это решется с помощью метаданных. Причем метаданные могут быть выведены автоматически (следующая версия EF это будет уметь)

VD>>Так что нет никаких "частей записи". Это и есть запись. Только другая. Запрос просто преобразует набор одних записей (возможно даже множество наборов) в другой набор других записей.

A>Да в том то всё и дело что часть, потому что одна возвращённая запись влияет (отображается) на несколько объектов C#.
Что значит влияет?

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

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

VD>>С удовольствием послушаю обоснование. Особенно это интересно в контексте linq.

A>Linq не работает не с бизнес-сущностями, а с DTO.
Linq работает с данными, или с записями если угодно (одно и тоже). DTO — костыль для изначально хреновой жирной модели.
Re[10]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.04.09 21:02
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>Анонимные типы, очень хорошая аналогия, только пользы от них в данном случае никакой нет.


Какая на фиг аналогия? Анонимные типы — это и есть реализация записей в C#. В Немерле для тех же целей я использую кортежи.

A>Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести.


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

VD>>Так что нет никаких "частей записи". Это и есть запись. Только другая. Запрос просто преобразует набор одних записей (возможно даже множество наборов) в другой набор других записей.


A>Да в том то всё и дело что часть, потому что одна возвращённая запись влияет (отображается) на несколько объектов C#.


Это твоя мантра. Меж тем надо понять простую истину. Ложки нет. Тфу ты... Объектов нет! Есть записи которые один в один отражаются в простые плоские объекты или в анонимные типы (тоже весьма простые и плоские).

Как только это понимание придет в твою голову, то все идеологические проблемы сразу же исчезнут.

Пойми ООП просто не причем. Для отображения в БД лучше подходя просты плоские типы.

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


A>Проблема, по той простой причине, что одному типу C# может соответствовать не одна таблица БД, и напротив одна таблица может содержать данные для разных типов C#. Если ты не придумал искуственный интеллект, то проблема не решена.


Это или ты выдумал сам, или почерпнул от маньяков ОРМ-щиков.

Не надо отображать объекты на БД. Это тупиковый путь. Повторяться надоело. Прочти еще раз мои слова. Не поймешь, значит тебе не надо.

VD>>С удовольствием послушаю обоснование. Особенно это интересно в контексте linq.


A>Linq не работает не с бизнес-сущностями, а с DTO.


В задницу твои бизнес-сущности. Линк обрабатывает данные. В том числе и лежащие в БД. А ты погряз в догмах ООП. Ты не понял ни слова из этой темы. Счастливо оставаться в своих заблуждениях.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.09 21:10
Оценка: +1
Здравствуйте, adontz, Вы писали:

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


A>>>Это тот уровень, с которым надо работать из BL.

G>>Можете так думать, будете только усложнять себе жизнь.
A>Ну а альтернатива какая? Усложнить BL введя логику обработки повреждённых данных? Что-то не впечатляет.

A>>>ИМХО ты путаешь DAL и ORM. Как бы то ни было, целостность данных должна поддерживаться уровнем ниже BL.

G>>Ниче не понял. Причем тут DAL и ORM ? БД — уровень ниже BL?
A>БД, уровень, безусловно ниже BL.

Так и пусть целостность данных на уровне БД будет, и не надо BL усложнять. И волки сыты и овцы — целки.

A>>>Если ничего не найдено GetById, то нарушена целостность данных. Это такая попа, что тут даже исключения мало.

G>>Почему? Какая разница методу GetById почему его вызвали с Id которого нет в базе?
A>Разница такая, что его не имеют права вызывать с Id которого нет в базе. Если подобное случилось, значит где-то баг, который надо исправить.
Почему не имеют? Это же просто метод доступа к данным, какая вообще разница зачем его вызывают? Как обрабаотывать случай отсутсвия в базе записи с нужным ID — уже дело BL, причем способ обработки сильно зависит от варианта использования.

A>>>Использовать его для всего подряд просто неправильно.

G>>А обоснования? (рассказываю секрет: IQueryable реализует именно такую абстракцию)

A>Ты всегда приводишь IQueryable как обоснование своей позиции

Ага, потому что это работающее решение. Даже когда не ыбло IQueryable я писал свои QueryObjects.

A>Открою секрет — в базе данных есть индексы. Нельзя одинаково эффективно выполнять выборку по разным условиям. Поэтому, надо явно выделять эффективные случаи в специализированные методы доступа.

Вау, оказывается DAL — это premature optimization для работы с БД?

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

А под все оптимизировать и не надо, надо только под тормозящие. Для этого профайлер в зубы и смотрим, обычно в программе меньше пяти Особо Торозящих Запросов.

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

A>Только вот в твоём варианте, какие лучше нигде в интерфейсе DAL не светится.

Не надо преждевременной оптимизацие заниматься.
Re[29]: Nemerle & Real Life
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.09 22:00
Оценка: +1
Здравствуйте, MozgC, Вы писали:

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


IT>>Временные таблицы точно также затрудняют анализ скрипта, но с ними всё же как-то можно бороться.

MC>Вообще временные таблицы иногда могут помочь упростить запрос.

В MS SQL Server есть table variables.
Re[18]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 11.04.09 22:16
Оценка: -1
Здравствуйте, MozgC, Вы писали:

MC>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.


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

MC>Вообще так можно про все сказать "что тут исключительного". К примеру пытаемся прочитать файл, а такого файла нет (его уже пользователь удалил), ну а что тут исключительного, давайте признак возвращать.


Вот хороший пример. Можно ещё обсудить вариант с разрешением к доступу к файлу. Твой backup процесс пытается скопировать файл, а он недоступен, по твоей логике есть только один путь — кинуть исключение и прервать процесс. Такой бекапер будет выброшен сразу же после первой проблемы с потерей информации.
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.04.09 22:21
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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

VD>В таких условиях ООП используется скорее для организации логики программы, а не для представления данных.
Не-не-не, дэвид блейн, не-не. Не надо ООП тянуть в организацию логики программы. Для логики подходит модель SOA.

Всля логика разбивается на сервсиные классы, которые в идеале stateless, в качестве SOA-интерфейсов используются интерфейсы языка, в качестве брокера — IoC контейнер. Методы сервисов создают цепочку вызовов, которая формирует запросы, не материализуя их без необходимости.

IoC контейнер в возможностями перехвата (runtime AOP) позволяет также навешивать авторизацию, кеширование и другие вкусности без затрагивания логики.
Re[19]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.04.09 22:59
Оценка: +1
Здравствуйте, IT, Вы писали:

MC>>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.

IT>Это назвается строить логику на исключениях, практика, за которую нужно не просто отбивать пальцы линейкой, а лучше даже что-нибудь отрезать.

Пальцы надо отбивать за безличный return null из которого не ясно что и где произошло.

MC>>Вообще так можно про все сказать "что тут исключительного". К примеру пытаемся прочитать файл, а такого файла нет (его уже пользователь удалил), ну а что тут исключительного, давайте признак возвращать.

IT>Вот хороший пример. Можно ещё обсудить вариант с разрешением к доступу к файлу. Твой backup процесс пытается скопировать файл, а он недоступен, по твоей логике есть только один путь — кинуть исключение и прервать процесс. Такой бекапер будет выброшен сразу же после первой проблемы с потерей информации.

Вообще-то исключения надо ловить, а не только кидать
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[19]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.04.09 23:02
Оценка: +1
Здравствуйте, VladD2, Вы писали:

A>>По-моему, в твоём примере налицо race condition. Надо либо запретить удалять из базы данных (я за этот метод), а только помечать сообщение как удалённое, либо смириться с тем что DAL кинет исключение, потому что блокировать ресурс-сообщение нельзя. В BL его можно обработать, а можно даже не обрабатывать. В конце концов я могу прямо в URL вбить номер несуществующего сообщения.

VD>Зачем мне мериться? Проще возвращать что надо и проверять результат.

А что надо? Сообщение может быть недоступно потому что нет прав доступа, потому что самого сообщения нет, потому что сообщение не доступно анонимным пользователям. И на все случаи жизни у нас будет return null? Бу-га-га.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.04.09 23:04
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>А зачем, собственно? Мы ведь должны были выбрать список тем для форума. Или данные по клиенту.


Влад я говорю не про форум и не про отчёты с дистрибуции. Есть и другие задачи, выходящии за пределы select из таблицы Orders.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[22]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.04.09 23:46
Оценка: +1
Здравствуйте, MozgC, Вы писали:

MC>Ну вот допустим идет запрос производителя по ID, и тут оказывается что такого производителя нет (а должен быть). Я кидаю из DAL исключение. И обрабатываю в БЛ (вывожу сообщение об ошибке пользователю и логирую саму ошибку). Что не так то?


Все бы ничего если бы не требовалось обработки в БЛ. А раз она есть, то ты строишь логику на исключениях.

Запомни на всю жизнь. Или это исключение, или ты не обрабатываешь его в логике.

Для обработки исключений должны быть специальные места. Ими не должен быть утыкан весь код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Проблемы организации OR-мапинга
От: Cyberax Марс  
Дата: 12.04.09 00:06
Оценка: -1
Здравствуйте, VladD2, Вы писали:

A>>Если ты заметил, я не считаю ORM лучшим решением. Как это согласуется с твоими выводами?

VD>Ты мыслишь их понятиями. Ты уже достал своей идеей проецирования объектов на БД. По буквам Д О С Т А Л!
VD>Это тупик. Счастливого пути в этом направлении.
Самое прикольное, что по сравнению с традиционными реляционными БД, такой тупик кажется всё более и более привлекательным.
Sapienti sat!
Re[24]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.09 01:35
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>У меня не SQL-сервер смотрит наружу, естественно, а мой специальный сервис магической синхронизации кэшей


Чем изобретать велосипеды проще иметь реплики БД. Тогда они будут по близости и всегда в актуальном состоянии. Это лучший вариант кэша.

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


Например, при перехватывая операцию добавления записи в таблицу (предположим, что удаление и обновление в таблице запрещено).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 12.04.09 02:40
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>BL не должен содержать код обработки нецелостных данных.


При чём здесь целостность? Целостность — это когда ты не можешь добавить или изменить данные в БД таким образом, чтобы не сломать их на предмет логической согласованности и правильности значений. Выборка данных к их целостности отношения не имеет. Ты сам утверждаешь, что один запрос по твоей логике следует считать корректным, а другой некорректным. Откуда базе данных это знать? DAL — это слой абстракции доступа к данным и о бизнес логике ему следует знать не больше чем самой базе. DAL — это вообще затычка, средство для того, чтобы собрать тараканов в одном месте и не давать им разбегаться по всему приложению. Вот что такое DAL, а ты приписываешь ему совершенно не свойственные для него функции.

И вообще, для многих это покажется крамолой, но с появлением технолоний вроде linq DAL, потеряв свои первоначальное продназначение вообще должен отмереть за ненадобностью.
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.04.09 05:01
Оценка: +1
Здравствуйте, adontz, Вы писали:

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


G>>>Как обрабаотывать случай отсутсвия в базе записи с нужным ID — уже дело BL, причем способ обработки сильно зависит от варианта использования.

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

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


Это у вас исключительная ситуация, а у меня пустая выбрка из dal — ситуация вполне нормальная.

А что вы будете делать если "Отсутвие записи с нужным ID" будет исключительной ситуацией в одном сценарии, и вполне нормальной ситуацией в другом?
Re[15]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.04.09 09:48
Оценка: :)
Здравствуйте, IT, Вы писали:

A>>DAL отличается от бизнес-логики назначением. DAL поддерживает инфрастурктуру: целостность данных, транзакции, права доступа на уровне строк. А вот как этим всем пользоваться решает BL.

IT>Ну да, я так и думал. Всё-таки каша в голове. Рома, DAL — это слой изолирующий работу с БД в терминах БД от остальной части приложения. Другими словами, в коде мы используем типизированные данные, а с БД вынуждены работать используя строковые константы. DAL был придуман иключительно как средство, позволяющее изолировать работу со строками в одном месте, которое будет легче контролировать. Всё! Другого назначения у DAL нет и никогда не было.

Это не DAL, это ORM.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[18]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.04.09 15:46
Оценка: +1
Здравствуйте, adontz, Вы писали:

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


A>>>>>Если читать её не целиком, а кусками (не важно по aID будет выборка или по bID) ты в самом лучшем случае замедлишь всё в O(ln(n)) раз.

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

A>Что значит каких? Удобных Какая разница? Данные надо прочесть, вот и всё. Если Linq-образный подход не поддерживает чтение в нужном виде, не надо мне доказывать, что подсказки личшние.


Так ты опиши в каком виде тебе нужно прочесть данные (какие у тебя уже есть и какие нужно получить) и тебе сразу же покажут как это сделать в разы лучше на Linq, чем на любом супер-мега DAL.
Re[17]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.04.09 18:03
Оценка: :)
Здравствуйте, IT, Вы писали:

A>>Это не DAL, это ORM.

IT>Рома, ты прежде чем спорить ознакомился бы сначала с общепринятой терминологией. Начни отсюда.

This database-related article is a stub. You can help Wikipedia by expanding it.

Ты там учился?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[19]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.04.09 18:05
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>А какие у тебя проблемы с кешированием? Ты его затолкал в DAL только потому что так удобнее и теперь считаешь его неотъемлемой частью DAL?


Да нет, дело не в том что удобнее, а в том что правильнее. Кеш должен быть прозрачным для пользователя, не должно быть нескольких хранилищ.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[18]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 12.04.09 18:15
Оценка: :)
Здравствуйте, adontz, Вы писали:

A>

This database-related article is a stub. You can help Wikipedia by expanding it.

Ты там учился?


А ты вообще хоть где-нибудь учился?
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 12.04.09 18:20
Оценка: +1
Здравствуйте, adontz, Вы писали:

IT>>А какие у тебя проблемы с кешированием? Ты его затолкал в DAL только потому что так удобнее и теперь считаешь его неотъемлемой частью DAL?


A>Да нет, дело не в том что удобнее, а в том что правильнее. Кеш должен быть прозрачным для пользователя, не должно быть нескольких хранилищ.


Правильнее понятие недетерминированное. Например, ты искренне заблуждаясь считаешь, что понятие integrity применимо к выборки данных и это правильно.
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 12.04.09 18:23
Оценка: :)
Здравствуйте, adontz, Вы писали:

A>>>

This database-related article is a stub. You can help Wikipedia by expanding it.

Ты там учился?

IT>>А ты вообще хоть где-нибудь учился?

A>Да, например, я на курсы вежливости ходил.


Надо было ещё на курсы элементарной логики походить.
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.04.09 18:47
Оценка: +1
Здравствуйте, adontz, Вы писали:

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


G>>Или тот же пример с городами: запросили сначала список городов с количеством кастомеров, потом запрашиваем катомеров из конкретного города. Между запросами другой пользователь поменял одному из кастомеров в город. Какая ссылочная структура поможет отследить изменение количества в двух городах?


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

Только для этого надо запрашивать список всех кастомеров каждый раз.

Вообще это получается решение соотвествующее жирной модели, которое тяготеет к вытягиванию всей базы на клиента.
Потом идет придумывание LazyLoad, кеширования и прочих гадостей.
Re[31]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.04.09 18:49
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

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

G>Только для этого надо запрашивать список всех кастомеров каждый раз.

Как показала практика, нет. Во-первых, не каждый раз, а всего один раз и время от времени обновлять. Во-вторых, не всех, а только видимых данному оператору. Права доступа на уровне DAL — великая вещь.

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

G>Потом идет придумывание LazyLoad, кеширования и прочих гадостей.

Ты просто не умеешь их готовить.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[32]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.04.09 19:08
Оценка: +1
Здравствуйте, adontz, Вы писали:

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


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

G>>Только для этого надо запрашивать список всех кастомеров каждый раз.

A>Как показала практика, нет.

Если ты еще не нарвался на проблему, то это не значит что её не существует.

A>Во-первых, не каждый раз, а всего один раз и время от времени обновлять.

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

A>Во-вторых, не всех, а только видимых данному оператору.

Это не зависит от технологии доступа к БД.

A>Права доступа на уровне DAL — великая вещь.

У тебя фильтрация по уровню доступа в DAL?
Это ужасно.

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

G>>Потом идет придумывание LazyLoad, кеширования и прочих гадостей.
A>Ты просто не умеешь их готовить.
Я-то как раз умею, поэтому и не использую.
Re[13]: Проблемы организации OR-мапинга
От: Tom Россия http://www.RSDN.ru
Дата: 12.04.09 19:55
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

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


G>>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).

Tom>>А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия?
G>Могут, только это будет не DAL.
Чуш какая то. Почему это будет не DAL? Где то есть религиозные огроаничения? Что ты под DAL понимаешь?

G>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.

Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.
От клиента до сервера БД. ТАк же как и в самих запросах. Так что эти разделения на BL/DAL предлагаю сразу забыть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[28]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.09 20:40
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

C>Реплики БД — это исключительно кривой хак.


Ыыыыыуууыыыйй! Я плякаль! А еще говорят умер юмор на нашей эстраде.

Ладно. Спорить на таком уровне я не готов. Пилите Шура! Пилите! Они золотые. (с)

C>И что дальше? Почему я должен молиться на БД и считать её недостяжимым идеалом, попытка повторить часть функций которого является величайшей дерзостью?


Я даже не знаю. Это же твоя идея. От тебя и ответа ждать.
Если ты не верно сформулировал вопрос и хочешь спросить почему не стоит повторять функции СУБД в своем приложении, то я могу ответить. Потому, что это море очень серьезного кода воспроизвести качественно который ты не сможешь. Будет жалкая пародия, в лучшем случае.

C>>>Предлагай решения.

VD>>Перестать дублировать работу сервера БД.
C>Не решение.

Пилите Шура... Пилите...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.04.09 20:41
Оценка: +1
Здравствуйте, Tom, Вы писали:

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


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


A>>>>QueryObject нужен для нетипичных запросов, типа запросов для отчётов. Использовать его для всего подряд просто неправильно.

Tom>>>Тут соглашусь с Ромой
G>>С чем соглашиься? С голословным утверждением?
G>>Может тогда ты ответишь почему это "просто неправильно" ?

Tom>Потому что серебрянной пули на практике не бывает.

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

Да, у меня на все есть один ответ — DML. Разве его недостаточно для выполнения любой задачи по работе с данными?
К сожалению современные средства позволяют описывать только выборки, поэтому приходится немного постараться чтобы работа с данными была DML-подобной.
Re[28]: Проблемы организации OR-мапинга
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 12.04.09 20:48
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

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


C>>>1) Контроль доступа.

VD>>И что с ним?
C>Сложно сделать на уровне чистых данных.

<крик с галерки>

А он там и не нужен. Контроль доступа (если мы говорим об одном и том контроле), должен реализовываться на уровне операций, причем "операций" в терминологии BL, а не DAL. В противном случае, это уверенный шаг к уязвимостях недостаточной авторизации.

</крик с галерки>

C>Реплики БД — это исключительно кривой хак.


Хорошо что тебя разработчики Lotus Domino/Notes не слышат. А то они на этом хаке, всю архитектуру своего продукта построили

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[29]: Проблемы организации OR-мапинга
От: Cyberax Марс  
Дата: 12.04.09 20:53
Оценка: +1
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>А он там и не нужен. Контроль доступа (если мы говорим об одном и том контроле), должен реализовываться на уровне операций, причем "операций" в терминологии BL, а не DAL. В противном случае, это уверенный шаг к уязвимостях недостаточной авторизации.

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

C>>Реплики БД — это исключительно кривой хак.

KV>Хорошо что тебя разработчики Lotus Domino/Notes не слышат. А то они на этом хаке, всю архитектуру своего продукта построили
Скажи, и нравится тебе как работает Лотус?
Sapienti sat!
Re[29]: Проблемы организации OR-мапинга
От: Cyberax Марс  
Дата: 12.04.09 20:57
Оценка: +1
Здравствуйте, VladD2, Вы писали:

C>>Реплики БД — это исключительно кривой хак.

VD>Ыыыыыуууыыыйй! Я плякаль! А еще говорят умер юмор на нашей эстраде.
VD>Ладно. Спорить на таком уровне я не готов. Пилите Шура! Пилите! Они золотые. (с)
А ведь на вопрос как мне такое сделать ты так и не ответил.

C>>И что дальше? Почему я должен молиться на БД и считать её недостяжимым идеалом, попытка повторить часть функций которого является величайшей дерзостью?

VD>Я даже не знаю. Это же твоя идея. От тебя и ответа ждать.
Я это делаю с помощью ORM — в кэше хранятся объекты, обладающие свойством идентичности. Соответственно, и никаких проблем.

VD>Если ты не верно сформулировал вопрос и хочешь спросить почему не стоит повторять функции СУБД в своем приложении, то я могу ответить. Потому, что это море очень серьезного кода воспроизвести качественно который ты не сможешь. Будет жалкая пародия, в лучшем случае.

Если пародия работает круто — то это не пародия. Обычные РБД оптимизированы на работу с большим количеством данных. В клиентском кэше данных обычно совсем немного, поэтому простой линейный перебор по экстентам почти всегда даёт нужный результат.
Sapienti sat!
Re[30]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.04.09 21:11
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

VD>>Если ты не верно сформулировал вопрос и хочешь спросить почему не стоит повторять функции СУБД в своем приложении, то я могу ответить. Потому, что это море очень серьезного кода воспроизвести качественно который ты не сможешь. Будет жалкая пародия, в лучшем случае.

C>Если пародия работает круто — то это не пародия. Обычные РБД оптимизированы на работу с большим количеством данных. В клиентском кэше данных обычно совсем немного, поэтому простой линейный перебор по экстентам почти всегда даёт нужный результат.

Ты наверное не понял что использование DML позволяет вообще не тянуть на клиент никакие данные, материализовываться выборки будут только с целью отображения.
Следовательно не понадобится идентичность объектов, оптимистичные блокировки и другие гадости.
Кеш станет предельно простым, так как объекты в кеше будут неизменяемыми (так как они получены только с целью отображения) и синхронизировать надо будет в одну сторону, что элементарно делается по LastModified.
Re[31]: Проблемы организации OR-мапинга
От: Cyberax Марс  
Дата: 12.04.09 22:11
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

C>>Если пародия работает круто — то это не пародия. Обычные РБД оптимизированы на работу с большим количеством данных. В клиентском кэше данных обычно совсем немного, поэтому простой линейный перебор по экстентам почти всегда даёт нужный результат.

G>Ты наверное не понял что использование DML позволяет вообще не тянуть на клиент никакие данные, материализовываться выборки будут только с целью отображения.
"Вообще не тянуть на клиент никакие данные" — это смешно.

У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем?
Sapienti sat!
Re[33]: Проблемы организации OR-мапинга
От: Cyberax Марс  
Дата: 12.04.09 23:25
Оценка: +1
Здравствуйте, IT, Вы писали:

C>>У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем?

IT>Какой смысл в отображении одного мегабайта данных?
Это совсем не так много, как кажется. Особенно, если туда входят картинки.
Sapienti sat!
Re[17]: Проблемы организации OR-мапинга
От: Lloyd Россия  
Дата: 13.04.09 00:26
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>SOA — это драцкий базворд за которым нет ничего нового. К компонентам (кстати "компонентов", а не "компонента") SOA не имеет никакого отношения. Расшифровывается этот базворд как "архитектура ориентированная на сервисы". Это тоже самое что серверы ориентированные на RPC. Дурацкий базвордов придумать можно миллионы (что и делаеют конторы вроде МС каждый день), но толку от этого не будет, так как ничего принципиально нового от этот не появится.

VD>SOA родилась в момент когда в МС полностью отчаялись протащить DCOM в область разработки серверов приложений. Тогда они понял, что общаться с серверами намного проще по средствам RPC (без сохранения состояния между вызовами на сервере). Тогда срочно придумали веб-сервисы, а чтобы все это круто звучало и никто не догадался, что это просто откат к более "примитивной" технологии и признание недееспособности ООП в области организации распределенных вычислений назвали все это SOA. Как и любой базворд это звучит красиво, не понятно. Что еще нужно чтобы завуалировать собственную глупость?

То о чем ты пишешь скорее относится не SOAP, но уж совсем не к SOA.
Первое (SOAP) — описание формата сообщений и не более того.
Второе (SOA) — архитектурный подход к "разрезанию" логики приложений.
Re[15]: Проблемы организации OR-мапинга
От: Lloyd Россия  
Дата: 13.04.09 05:20
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

L>>Как ни прискорбно это сознавать, но большинство разработчиков работает в сфере т.н. enterprise-приложений, а уж в них получение чего-то по id, изменение этого и запись обратно в базу — гораздо более частая операция, чем массовые изменения в базе.

G>А кто мехает для операции "получение чего-то по id, изменение этого и запись обратно в базу" использовать один Update,

Например то, что в этой цепочке присутствует пользователь и ему надо-таки что-то показать. Для этого и нужен GetById.
А по поводу того, как организовать запись в БД, я вроде ничего и не писал.
Re[16]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 13.04.09 05:48
Оценка: +1
Здравствуйте, Lloyd, Вы писали:

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


L>>>Как ни прискорбно это сознавать, но большинство разработчиков работает в сфере т.н. enterprise-приложений, а уж в них получение чего-то по id, изменение этого и запись обратно в базу — гораздо более частая операция, чем массовые изменения в базе.

G>>А кто мехает для операции "получение чего-то по id, изменение этого и запись обратно в базу" использовать один Update,

L>Например то, что в этой цепочке присутствует пользователь и ему надо-таки что-то показать. Для этого и нужен GetById.

Для этого нужен один select.
Вообще если не думать о работе с даннми в терминах GetById, FindByЧтототам, то жить становится гораздо проще.
Re[33]: Проблемы организации OR-мапинга
От: Cyberax Марс  
Дата: 13.04.09 07:50
Оценка: :)
Здравствуйте, kochetkov.vladimir, Вы писали:

C>>У меня это object-level security. Естественно, это не отменяет security на операции.

KV>Т.е. ты строишь в реляционной среде разграничение доступа на уровне объектов и утверждаешь, что это лучше, чем использовать для этого ОО-среду? Или у тебя ООБД?
У меня ORM. Т.е. объектная модель, построена на основе РБД.

KV>>>Кстати, а что ты будет делать с атаками man-in-the-middle?

C>>Так как обычно security каналов связи (HTTPS со строгой проверкой сертов).
KV>Нифига себе у тебя "есстественный путь", которым SQL-сервер смотрит наружу , хотя это по нашему
У меня не SQL-сервер, а моя система смотрит наружу.

KV>>>Как пользователю — нет, но это никак не связано с его архитектурой. Как админу, в прошлом поддерживавшему инфраструктуру из 12-13 лотусовых серверов и пары тысяч клиентов — да, нравится. Как безопаснику — мне вообще ничего не нравится, так что не аргумент

C>>Тем не менее, это подход очень глючный. Для email-серверов он ещё сгодится — нет особых ограничений на время и консистентность синхронизации.
KV>Лотус — это не почтовый сервер. Более того, сама IBM уже не раз признавала, что именно как почтовик, оно получилось не очень.
Я знаю, просто имею в виду саму область email-подобных решений.

Хотя, в принципе, в Лотусе репликация немного напоминает мой подход.
Sapienti sat!
Re[37]: Проблемы организации OR-мапинга
От: Cyberax Марс  
Дата: 13.04.09 07:51
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>>>Ну так в чём тогда проблема? Объективная реальность

C>>Хочется чтоб всё быстро работало
IT>Сделай чтоб работало быстро
Дык уже. С помощью идеологически неправильного антисоветского ORM
Sapienti sat!
Re[16]: Проблемы организации OR-мапинга
От: Tom Россия http://www.RSDN.ru
Дата: 13.04.09 09:20
Оценка: +1
IT>>Это звучит примерно так: я не понимаю смысла разделения приложения на слои, поэтому предлагаю эти разделения сразу забыть. Да уж, чего только люди не придумают для оправдания собственных ошибок или непонимания сути обсуждаемых вещей.
Tom>Опять розовый слоник в вакууме

Поясню, я писал выше в сообщении но если ты пропустишь:

Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос:
update order set delayed = true where OrderDate < '...'
По твоему подобный запрос не реализует часть бизнес логики?
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[17]: Проблемы организации OR-мапинга
От: Tom Россия http://www.RSDN.ru
Дата: 13.04.09 09:54
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

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


G>>>>>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.

Tom>>>>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.
G>>>
G>>>Открою тебе секрет, ни в одном моем проекте, которя я создавал от начала до конца такого не было.
Tom>>Это фикция. Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос:
Tom>>update order set delayed = true where OrderDate < '...'
Tom>>По твоему подобный запрос не реализует часть бизнес логики?
Tom>>Если нет, тогда покажи мне пример на C# реализующий бизнес правило: Заказы не выполненые по любой причине в течении дня перевести в статус задержанные.
G>Сайчас это или foreach с объектами или SQL-запрос.
Я написал пример. Можешь так же написать пример?

G>Если будет Linq или EF провайдер с поддержкой DML, то буду использовать только его.

Пример можно? И где вообще ты нашёл про поддержку DML в EF 2?

G>>>ЗЫ. Есдинственное что допускал из размазывания — перенесение некоторой части логики в функции\хранимки БД. Только с целью оптимизации.

Tom>>Я это уже читал. Это фикция. С вовременных приложениях, когда одна из основных задач — работа с данными, бизнес логика в любом случае будет реализовываться через запросы к БД.
G>Вопрос в том как формировать такие запросы.
G>Linq сейчас позволяет это очень удобно делать в коде приложения, а не в хранимках или текстовых запросах в DAL, но только для выборок.
Гед пример?
... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
Народная мудрось
всем все никому ничего(с).
Re[18]: Проблемы организации OR-мапинга
От: vdimas Россия  
Дата: 13.04.09 10:04
Оценка: -1
Здравствуйте, VladD2, Вы писали:


V>>Просто есть что-то не то в том, что по union можно в один столбец явно, или по ошибке склеить числовые и строковые данные, и никто не тебе ругнётся на это.


VD>Это вопрос строгости типизации. Есть СУБД которые не позволяют этого сделать. То что MS SQL имеет довольно слабую (и откровенно говоря дряхлую и кривую) систему типов — это проблемы Microsoft и от части Sybase, а не РСУБД.


Именно, нестрогая, да еще и динамическая типизация. И не только у MS SQL, практически у всех популярных СУБД.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[22]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.04.09 10:43
Оценка: -1
Здравствуйте, adontz, Вы писали:

A>>>Да нет, дело не в том что удобнее, а в том что правильнее.

VD>>Супер. Новое инженерно-научный постулат "правильнее".
VD>>Можно задать критерии правильности в общем случае?

A>Влад, если нечего сказать по существу, то лучше вообще не писать,


О, мудрая мысль. Но тебе придется сломать обе раку чтобы избежать искушения ответить мне .
Вот этот ответ, например, не имеет никакого отношения к вопросу (да вообще ни к чему).

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


A>ведь разговаривать про клиентский кеш ты недавно отказался.


И что? Он не имеет отношения к делу. В теме речь шла о доступе к данным (БД).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.04.09 10:52
Оценка: :)
Здравствуйте, Tom, Вы писали:

Tom>Опять розовый слоник в вакууме


Я попросил бы!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 13.04.09 11:11
Оценка: +1
Здравствуйте, Tom, Вы писали:

G>>Даже апдейты не нужны.

Tom>Не понял, в задаче чётко сказано Заказы не выполненые по любой причине в течении дня перевестись в статус задержанные.
Флаг "задержинный" в базе — нарушение нормальзации, без веских причин я такого делать не буду.

Tom>У тебя вижу только селект.

Это задержанные заказы, что с ними дальше делать зависит от usecase.
Например можно взять всех менеджеров заказов и отправить им уведомление об их неправльной половой ориентации.

var managers = (from o in delayedOrders
                select manager).Distinct();
foreach(var tuple in managers.Select(m => new {m.Name, m.Email}))
{
    _notificationService.SendNotification(tuple.Email, tuple.Name, ...);
}


Причем запрос к базе будет только один.

G>>>>Если будет Linq или EF провайдер с поддержкой DML, то буду использовать только его.

Tom>>>Пример можно? И где вообще ты нашёл про поддержку DML в EF 2?
G>>Меня в EF интересует не eSQL и Object Services, а модель провайдеров и edm.
G>>Сейчас в EF есть AST для представления запросов, в том числе числе insert\update\delete.
Tom>Какой нафик AST и причём он к EF? И где ты взял что они будут сильно менять edm?
Tom>Максимум — переделают работу с relation-ами.
Сильно и не надо, некоторых мелких изменений будет вполне достаточно.


G>>Но нету способов сформировать ast для DML, они формируются внутри при вызове SaveChanges в контексте.

G>>Я сначала хотел написать методы-расширения для DML, но уперся в убогость самого средства описания модели данных — edm.
G>>Ко второй версии EF обещают edm поправить, и если у них не будет провайдера с DML, то напишу свой.
Tom>DML — я нет и не будет, и здаётся мне что задача написать такой провайдер сама по себе не простая.
Распарсить expression tree и и сформировать dbexpression tree задача конечно не простая, но решаемая? При том что основная сложность — построение where выражений с подзапросами уже реализована.

Tom>Ибо даже на сегодняшний день ни у одного комерчвеского linq решения она не реализована.

ну это только их проблемы.
Re[38]: Проблемы организации OR-мапинга
От: SleepyDrago Украина  
Дата: 13.04.09 11:17
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

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


IT>>>>Ну так в чём тогда проблема? Объективная реальность

C>>>Хочется чтоб всё быстро работало
IT>>Сделай чтоб работало быстро
C>Дык уже. С помощью идеологически неправильного антисоветского ORM
А не стремно это все ? Не даром люди 20 лет в оракле пилят consistency, security, и тп. А ты тут пришел со своим кешом объектов и всех зарулил. Ты бы видел их баглист ... Я даже думать не хочу, сколько там вылезет тараканов если прижать эту распределенную репликацию кешей серьезными тестами, с отказами каналов и тд и тп. Скорее всего речь идет о том, что конкретные клиенты уже приучены к "безопасным сценариям" и своим каналам и знают когда нужно "выйти и снова зайти"
Re[19]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.04.09 11:24
Оценка: +1
Здравствуйте, Tom, Вы писали:

VD>>Это именно запрос реализующий часть бизнес-логики.

VD>>И что?

Tom>То, что часть логики всегда будет реализована с использованием запросов БД.


Дык с тобой никто и не спорит. С тобой спорят о том где этим запросам лежать и на чем написаны.

Tom>И в этом случае бизнес логика размазывается не только по слоям но и по компонентам деплоймента.


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

Tom>И это тоже не зло а нормальная ситуация.


Размазывание — это по любому проблема. (в терминах зла и добра я разговаривать не хочу)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: Проблемы организации OR-мапинга
От: Cyberax Марс  
Дата: 13.04.09 11:27
Оценка: :)
Здравствуйте, SleepyDrago, Вы писали:

C>>Дык уже. С помощью идеологически неправильного антисоветского ORM

SD>А не стремно это все ? Не даром люди 20 лет в оракле пилят consistency, security, и тп. А ты тут пришел со своим кешом объектов и всех зарулил. Ты бы видел их баглист ...
А кто говорит, что у меня нет consistency и security? Кстати, предыдущая итерация софта использовала прямое соединение с Оракулом и row-level security. С каким же удовольствием мы его прибили....

SD>Я даже думать не хочу, сколько там вылезет тараканов если прижать эту распределенную репликацию кешей серьезными тестами, с отказами каналов и тд и тп.

Как раз одной из причин использования моего кэша является очень низкое качество каналов. Мне даже пришлось делать свой протокол RPC, так как ни один из существующих не давал достаточной надёжности.

SD>Скорее всего речь идет о том, что конкретные клиенты уже приучены к "безопасным сценариям" и своим каналам и знают когда нужно "выйти и снова зайти"

Нет.
Sapienti sat!
Re[20]: Проблемы организации OR-мапинга
От: IT Россия linq2db.com
Дата: 13.04.09 13:20
Оценка: :)
Здравствуйте, Tom, Вы писали:

Tom>DML — я нет и не будет, и здаётся мне что задача написать такой провайдер сама по себе не простая.

Tom>Ибо даже на сегодняшний день ни у одного комерчвеского linq решения она не реализована.

Задача вполне посильная. Только комерсантам это не надо. Пипл сегодня хавает heavy ORM. Что это такое в .NET мире пока мало кто знает, но раз говорят, значит должно быть круто. А DML, так это примитивщина какая! Фактически шаг назад в развитии человечества.
Если нам не помогут, то мы тоже никого не пощадим.
Re[51]: Проблемы организации OR-мапинга
От: adontz Грузия http://adontz.wordpress.com/
Дата: 13.04.09 14:12
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

A>>Является ли логика работы прав доступа NTFS частью бизнес-логики приложения работающего с файлами?

G>Ты доступа к этому не имеешь, поэтому разницы нету как называть.

Вот уж слил так слил
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[19]: Проблемы организации OR-мапинга
От: Lloyd Россия  
Дата: 13.04.09 15:55
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>То о чем ты пишешь скорее относится не SOAP, но уж совсем не к SOA.


VD>Нет.


Из того, ты отнес RPC и SOA к понятиям одного уровня, у меня сложилось именно такое ощущение.
Между тем SOA может прекрасно сосуществовать с тем же RPC, это понятия ортоганальные.

L>>Первое (SOAP) — описание формата сообщений и не более того.


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


Ну так объясни, как пожно сравнивать архитектурный подход с механизмом удаленного вызова. У меня это как-то слабо укладывается в голове.

L>>Второе (SOA) — архитектурный подход к "разрезанию" логики приложений.


VD>Этой архитектуре 100 лет в обед.


Кто-ж с этим спорит.

VD>Всю жизнь она называлась клиент-сервер. Весь остальной булшит из SOA — эо банальные принципы структурного программирования.


И да, и нет. То, что называют клиент-сервером, обычно относят к разделению на слои, горизонтальное деление (UI, бизнес-логика, данные + вариации).
SOA-же про то, как резать "вертикально", в иной плоскости, как стыковать разные бизнес-подсистемы. Это сильно разные вещи.
Re[21]: Проблемы организации OR-мапинга
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.04.09 21:59
Оценка: :)
Здравствуйте, vdimas, Вы писали:

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


V>>>Именно, нестрогая, да еще и динамическая типизация. И не только у MS SQL, практически у всех популярных СУБД.


VD>>Осталось доказать это утверждение.


V>Доказать что?


Тебе не ясно значение слова "утверждение"?
Вот и докажи свое утверждение.

V>Что даже сохранённые запросы (или спроки) компиллируются динамически, и ты не узнаешь про проблемы до запуска запроса?


Какая прелесть "сохранённые запросы"?! Сам придумал, сам обсуждает.
Я уже не спрашиваю, что такое "спроки".

Какая разница что и когда компилируется? Статическая типизация — это когда типы выражений известны до выполнения. И для SQL-я это всегда так.
По-твоему зачем в таблицах описываются типы данных колонок?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 14.04.09 07:38
Оценка: +1
Здравствуйте, Lloyd, Вы писали:

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


L>>>Это зависит от того, что у вас за клиент. В случае веба click по договору приведет к открытию страницы договора, а на новой странице эта инфорация уже не будет доступна и запрашивать все рано придется.


VD>>Ага. Но зачем мне получать объект по id? Я лучше получу всю нужную информацию отображаемую на странице.


L>А как предполагается вытаскивать эту нформацию? Например, в случае того же web-а. Если исползуем вывод типов для запросов типа from c in customer select new { c.id, c.name }, то сразу теряем возможность использовать подобный запрос в более чем одном методе. Если же для каждого такого запроса создаем свой класс-обертку, содержащий id и name, то скоре колиество этих классов разрастется до неимоверных размеров. Как предполагается с этим бороться?

Очень просто. Проекция накладывается в том месте где становится известно какие конкретно данные нужны. В вебе — при формировании presentation entity (она же View Model).
Подход с использованием паттерна Query Object позволяет отложить само выполнение запроса до тех пор пока не станут известны все параметры необходимой выборки. Это дает огромный прирост быстродействия в некоторых случаях.

VD>>При этом я не хочу вынимать лишнюю информацию. Запрос же объекта по идентификатору — это неэффективное вынимание данных — запрос данных наобум.

L>А в чем серьезный недстаток вынимания всего объекта? Насколько я понимаю, сервер все равно читает с диска постранично, т.е. все данные, относящиеся к записи все равно будут подняты в память.
Это если запись маленькая. Если в записи фигурируют image, varbinary, ntext и подобное, то читать эту запись полностью становится достаточно дорого.
Кроме того одной записи для отображения чаще всего недостаточно, обычно тянется некоторый набор связанных записей и на них наклдаывается проекция или группировка. При подходе с GetById накладывать проекции и группировки нельзя, иначе получится протаскивание деталей presentation в DAL (та самая каша, о которой говорит Tom).

VD>>>>И select тут будет намного более удобнее. Зачем нам объект? Нам нужно содержимое договора (например).

L>>>Если схема данных один-в-один соответствует entity, то будет гораздо удобнее.
L>>>Если же DAL занимается каким-нибудь преобразованием из резалтсета в entity, то будет уже не так удобно.
VD>>Если нужны преобразования, то не трудно написать функцию. Но зато в 99% случаев ты просто напишешь запрос который вынет те данные которые реально нужны.
L>В случае функции бизнес-код будет содержать информацию о том, как данные хранятся, а такому коду, имхо, не место в бизнесе.
EF имеет мощный маппинг, но при этом вполне нормально работает с запросами, без материалиализации данных.
Кроме того можно сделать абстракции от способа хранения на view в БД, а из клиентского кода работать как с таблицами
Re[31]: Проблемы организации OR-мапинга
От: drol  
Дата: 18.04.09 18:08
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Семантика тут тоже не причем. Нужные операции есть и сейчас. Просто то что раньше было запрещено будет разрешено.


Продолжаю не понимать. Операция раньше делала что-то по одним правилам, а теперь стала по другим. Что это если не изменение семантики ??? Тут ведь всё надо будет переделывать/передоказывать. Начиная с верификатора, и далее со всеми остановками...
Re[33]: Проблемы организации OR-мапинга
От: drol  
Дата: 18.04.09 18:38
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Операция раньше копировала, и теперь копирует. Просто раньше она была применима только для объектов одного типа, а теперь и для разных.


Это и есть изменение семантики. Надо менять верификатор и т.д. Про что Хейльсберг и говорил.
Re[30]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.04.09 14:29
Оценка: +1
Здравствуйте, Lloyd, Вы писали:

G>>Как раз в случаях с Ajax много класов делать не надо. Если передавать на клиента сериализованный в JSON объект, даже класс писать не нужно.

L>Не, нетипизированные методы идут в топку.
На сервере все типизировано, а на клиенте полюбому javascript.
Re[20]: Проблемы организации OR-мапинга
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.04.09 03:28
Оценка: +1
Здравствуйте, adontz, Вы писали:

A>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз

Это легко и понятно.
A>и распихать результат по экземплярам обоих типов.
А вот это — непонятно. Зачем тебе эти несчастные экземпляры?

Вот представь, что "многие-ко-многим" — это авиарейсы между городами. Каждый город, естественно, оборудован огромным количеством подробностей. Но вот ты выводишь табличку, к примеру, рейсов конкретной авиакомпании. Зачем тебе "экземпляры" всех городов? Всё, что тебе нужно — это список вида {string Departure, string Destination}. Ну так ты его и получишь!
Если тебе интересно получить граф типа "полное описание города -> список доступных пунктов назначения", то тебе и нужна коллекция структур вида {Сity city, IEnumerable<string> Destinations}. Зачем тебе опять полные экземпляры в правой части?
Хотеть их — вредное занятие. А то, о чем я пишу, тривиально получается в линке. За что мы его и любим.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Проблемы организации OR-мапинга
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.04.09 08:21
Оценка: +1
Здравствуйте, adontz, Вы писали:

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


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


A>
  • Какая разница, размазывать логику или нет, если хранимки генерируются?
    Так что, хранимки генерируются на ВСЕ возможные запросы? В хранимках страшная каша будет из бизнес-логики и деталей представления.

    A>
  • Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. Ничто тебя не обязывает к этому вызову.
    Для этого существуют механизмы AOP как compile-time, так и runtime.

    A>Права доступа должны быть уровнем ниже бизнес-логики, иначе будут постоянные проблемы.

    Чушь повторенная несколько раз истиной не становится.
  • Re[9]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 08:28
    Оценка: :)
    Здравствуйте, mrTwister, Вы писали:

    A>>С каких это пор логин стал Primary Key?

    T>Как сделаешь, так и будет.

    Делать через жопу — право каждого.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[24]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 08:47
    Оценка: +1
    Здравствуйте, Cyberax, Вы писали:

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


    S>>Это проблема ментальной модели, и я с этой проблемой тесно знаком. Спроси ОРМ-программиста захрена он тащит в тонкого клиента полную географию США — он смотрит на тебя как на идиота и говорит "ну так мне же нужно показать список штатов в дроп-дауне".

    C>Это плохой ORM-программист. Нормальный программист просто вытащит список объектов типа State для заданной страны. В объекте State будет три поля "id", "name" и "abbreviation".

    А если State обладает значительно более сложной структурой?
    Задчача таже — отобразить список в dropdown.
    Re[29]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 09:32
    Оценка: :)
    Здравствуйте, gandjustas, Вы писали:

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

    Нет, ты это сам придумал, что объект штата будет большим из-за того, что программа предназначена для работы с географией.

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

    G>>>Обобщая такие крайние случаи и получим модель запросов и полновесный ORM нам никак не поможет.

    C>>DTO — это всего лишь объект передачи данных, тот же кортеж им вполне может быть. В этом случае просто всё у нас скатывается к SQL-подобному доступу.
    G>Так если SQL-подобный доступ совместить с механизмом отображения полей БД на свойства объектов данных (DTO), то будет счастье. Об этом и говорим.
    Тебе говорят, что в большинстве случаев ORM не даёт существенного overhead'а, поэтому и DTO не нужны. Для редких случаев, когда overhead от ORM слишком велик — используем DTO. Ситуация примерно как с ассмеблерными вставками раньше — оптимизируем только узкие места.
    Sapienti sat!
    Re[30]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 20.04.09 12:38
    Оценка: +1
    Здравствуйте, 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)?
    Если "нет" ответят на все вопросы, то хорошо бы услышать обоснование.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[26]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 12:43
    Оценка: +1
    Здравствуйте, adontz, Вы писали:
    A>Ага, только вот между чтениями может пройти существенное количество времени (минуты). Не вариант.
    А по-другому никак.
    A>Ты не обеспечиваешь целостность данных, ты просто позволяешь эффективно читать обновления. Это вообще другая задача.
    А ты как-то по-другому обеспечиваешь "целостность данных"? Нет, нифига ты не обеспечиваешь.
    Целостность данных иначе как транзакционным чтением и не обеспечишь.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[31]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 12:51
    Оценка: :)
    Здравствуйте, gandjustas, Вы писали:

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

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

    C>>Для редких случаев, когда overhead от ORM слишком велик — используем DTO.

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

    C>>Ситуация примерно как с ассмеблерными вставками раньше — оптимизируем только узкие места.

    G>Неверная аналогия. SQL обладает большими возможностями, чем GetById, FindByName и прочее.
    Что ты привязался к FindByName?? В нормальных ORM есть свой язык запросов, кроме того, есть ещё навигационный доступ.
    Sapienti sat!
    Re[29]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 14:12
    Оценка: -1
    Здравствуйте, Sinclair, Вы писали:

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

    S>При чем тут RI? Она ортогональна безопасности.

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

    A>>Я уже насмотрелся как кассир в Батуми принимал деньги от доставки Кутаиси в кассу Телави. Ссылочная целостность прав доступа — очень важная вещь.

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

    Вот это-то и есть ошибка, котрую я уже много раз видел — права доступа не на объекты, а на операции. Если делать права доступа на операции, то получится код, проверяющий, что касса, кассир и сдающий деньги числятся за одним и тем же филиалом. Это код и это не гибко. Не гибко, по той простой причине, что если кассу в Телави ограбили, я машины доставки пущу в Тбилиси, благо всего пара часов пути. А чтобы пустить их в Тбилиси мне надо переписывать код проверяющий права доступа.
    Если раздавать права доступа на объекты, то кассир из Батуми другие филиалы вообще не видит. Так как проверка прав доступа обеспечивает ссылочную целостность, он не только филиалы другие не видит, он ещё ин е может оформить на них никакие операции, не может просмотреть отчёты по ним и т.п. То есть я указав права доступа всего на один объект, разрулил проблемы с большим количеством операций. Поменять права — дело пяти минут и работа уже для администратора, а не программиста.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[32]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 18:36
    Оценка: -1
    Здравствуйте, Cyberax, Вы писали:

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


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

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

    C>>>Для редких случаев, когда overhead от ORM слишком велик — используем DTO.

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

    C>>>Ситуация примерно как с ассмеблерными вставками раньше — оптимизируем только узкие места.

    G>>Неверная аналогия. SQL обладает большими возможностями, чем GetById, FindByName и прочее.
    C>Что ты привязался к FindByName?? В нормальных ORM есть свой язык запросов, кроме того, есть ещё навигационный доступ.
    Мы тут говорим не только о выборках, но и о DML.
    К сожалению такой возможности покачто нету ни в одном фреймворке.
    Re[28]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 19:24
    Оценка: -1
    Здравствуйте, adontz, Вы писали:

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


    G>>Шорош только тем, что его проще всего построить.

    A>А чем плох, не написал.
    Плох тем, что требует достаточно много приседаний для синхронизации.

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

    G>>Если еще и хочется запросы делать к кешу, то можно использовать inprocess БД.
    A>Кеш может жить не дольше самого приложения.
    С чего бы?
    Вот Янус и почта так работает.

    G>>>>Вообще если между двумя запросами свзязанных данных проходит какое-то время, то всегда можно нарваться на рассогласованность, и без пессимистичной блокировки этих данных в общем случае победить такое нельзя.

    A>>>Ты опять таки не прав.
    G>>Ну а обоснования будут?

    A>А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо.

    Еще раз. Я (и не только) говорю что сохранить согласованность данных между двумя запросами в общем случае можно только используя транзакционные методы (блокировки).
    Ты так и не смог доказать обратного. Частные случаи, вероятности и отстраненные размышения мало интересуют.
    Re[36]: Nemerle & Real Life
    От: mrTwister Россия  
    Дата: 21.04.09 04:15
    Оценка: -1
    Здравствуйте, VladD2, Вы писали:

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


    T>>Я тоже.


    VD>Где?


    http://rsdn.ru/forum/message/3364324.1.aspx
    Автор: mrTwister
    Дата: 18.04.09
    лэт ми спик фром май харт
    Re[32]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 07:04
    Оценка: +1
    Здравствуйте, adontz, Вы писали:

    A>Надо заметить, что вне зависимости от подхода, если есть желание работать только с актуальными данными, то придётся помучаться. Можно обновление исходных данных и оформления заказа совершать в транзакции. Впрочем это плохо, потому что данное решение крайне плохо масштабируется. Так же, при операции клиент может передавать версию данных, на основе которых операция оформляется, а сервер отказывать в оформлении, если исходные данные устарели. На практике это очень хорошее решение. Очень хорошее оно в первую очередь потому, что деление данных в программе достаточно хорошо соответствует распределению обязанностей между персоналом. Скажем, клиенты распределены по торговым агентам (одному и тому же клиенту два агента с одинаковым ассортиментом не продают). Как следствие, кеш клиентского ПО торгового агента в штатном режиме работе, фактически, обновлять нет необходимости вообще, так как его меняет только сам торговый агент, совершая продажи. Бывают исключения, например корректировка остатка склада, но их можно обрабатывать обнулением кеша. Из практики, корректировка остатсков происходит раз в неделю, а операций продажи до ста в сутки. Соответственно, кеш себя абсолютно оправдывает.


    То что данные строго разделены между пользователями — очень сильное допущение. Фактически все сводится к секционированию БД на области, в которых нету конкурентного доступа. Естественно таким образом каждую секцию выгоднее всего держать "ближе" к приложению — в локальной реплике. Я бы для таких целей SQL CE использовал, или SQL Express c user instance если нужны фичи полновесной РСУБД. То что не укладывается в такую схему можно дергать с сервера через веб-сервисы.

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

    Для автоматизации коллективной работы (любые CRM, ERP, систкемы документооборота) такая схема не подойдет. Там в большенстве процессов участвует много людей (менеджеры, кураторы, исполнители), с пересекающимися обязанностями, а самое главное они работают с одними и теми же данными (клиентами, договорами).
    Re[43]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 08:49
    Оценка: -1
    Здравствуйте, gandjustas, Вы писали:

    A>>Если ты хочешь что-то особенное, это всегда негибкий код. Вопрос не в том, как не писать его вовсе, это утопия. Вопрос в том, как решение 99% задач сделать data driven.

    G>Вопрос в том как сделать максимум кода декларативным, а не то что ты написал.

    Ща мы в очередной раз узнаем что Немерле немеряно рулит? По-моему, очевидно что декларативное опписание это ещё один язык, и далеко не самый удобный для понимания, отладки и т.д. Для администрирования лучше data driven.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[36]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 08:50
    Оценка: -1
    Здравствуйте, adontz, Вы писали:

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


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


    G>>Тебе так хочется в это верить?

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

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

    Я отлично знаю как данные в кеш выедлять.
    Только ты под кешем понимаешь только локальную реплику. Поэтому непонимаешь что другие тебе говорят.
    А самое главное что ты даже толком не можешь сказать зачем тебе локальная реплика, только пытаешься свести все к одному сценарию — "каждый пользователь работает только со своим куском данных".
    Re[26]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 21.04.09 09:19
    Оценка: -1
    Здравствуйте, EvilChild, Вы писали:


    V>>Да, хаскелисты тоже так считают. Хотя, полиморфизм по алгебраическим типам — это опять же и снова классика динамической типизации.

    EC>Это в каком месте полиморфизм по алгебраическим типам динамически типизирован?

    В месте определения значения дискриминатора, вестимо. Конкретно в Хаскеле — в соотв. строке матчинга.
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[34]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 21.04.09 10:15
    Оценка: +1
    Здравствуйте, Sinclair, Вы писали:

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

    S>...Дык надо понять, что такое "структура". Набор полей? Набор свойств?

    Набор, порядок следования, смещения, области видимости и имена полей.
    Отдельный вопрос нужны ли вообще типу поддерживающему структурную идентичность что-то выходящее за пределы интефейса object. Разве что им бы не помешала реализация IComparable<T> и IEquatable<T>.
    В прочем, учитывая проблемы с видимостью членов возможно должно быть полное совпадение интерфейса: полей, публичных методов и свойств, реализуемых интерфейсов.

    Для реализации записей достаточно будет если у объекта все поля будут публичными (доступными только на чтение). В прочем, у анонимных типов это уже не так. В них проявляется весь маразм ООП. Наружу торчат свойства, а свойства скрыты. Но это уже детали реализации. Если принять правила:
    1. Структурно-эквивалентными объектами могут быть объекты одного супер-типа (struct, class и т.п.).
    2. Объекты должны быть помечены специальным атрибутом содержащим Guid.
    3. У объектов должны полностью совпадать структура полей и интерфейс (возможно можно наплевать на не публичные методы и своейства).
    4. Тип должен быть запечатанным (sealed).
    то можно прозрачно обеспечить структурную эквивалентность для весьма разных типов.

    S>Ну да, вот Nullable пришлось специальным образом хардкодить в рантайме, чтобы гарантировать корректные результаты при анбоксинге null и прочие весёлости.


    Это немного другое. Там проблемой было неинтуитивная семантика. В случае структурной эквивалентности таких проблем нет. Кстати, в ML-клонах решена проблема null. Это исключает целый класс ошибок. Очень советую познакомиться.

    S>Я nen подумал о том, что для неизменяемых типов нужна специальный Property pattern.


    S>В CLR встроена возможность обозвать пропертью пару методов с сигнатурами void SetXXX(T value), T GetXXX().

    S>Для immutable-типов void SetXXX не подходит. Зато подойдет метод SetXXX, который возвращает новый экземпляр, который отличается от старого только значением свойства.
    S>Ну, и собственно сами проперти должны иметь тот же смысл.
    S>То есть мы пишем как-то так:
    S>
    S>var newDate = GetDate().Days += 1;
    S>


    Это отдельный разговор. Ты изобрел велосипед. В ML-клонах есть подобная функциональность. Выглядит немного по другому, но суть та же.

    VD>>Это все проверено сто раз в функциональных языках. Даже нехилая теория под это дело подведена.

    S>Ну так в этих языках нет проблемы интероперабельности с CLR.

    Это у CLR есть проблема в поддержке этих языков. И уж одно это является его недостатком. Ведь многоязычность декларирована, а по факту CLR может напрямую поддерживать только C# и VB.

    S>Да, мелочевка — в том числе и поддержка туплов. Но в основном люди страдают ерундой.


    Я так и думал. Потому и ребятам из МС плевать на свое детище. Один фиг куча недоучек ничего не заметит.

    S>Например, некоторые C# MVP из Калифорнии искренне полагают, что switch("test") порождает словарь строк при каждом проходе.


    Ну, дык и гнат его из MVP.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[37]: Nemerle & Real Life
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 21.04.09 11:20
    Оценка: :)
    Здравствуйте, mrTwister, Вы писали:

    T>>>Я тоже.

    VD>>Где?
    T>http://rsdn.ru/forum/message/3364324.1.aspx
    Автор: mrTwister
    Дата: 18.04.09


    Не считаю нужным тратить время на неадекватных собеседников. За сим прощаюсь.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[38]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 11:21
    Оценка: -1
    Здравствуйте, adontz, Вы писали:

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


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

    G>>Ну, конкретнее, сколько времени оценка будет правильной?
    A>Я уже написал, ты не удосужился прочесть. "настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора".
    Критерий полезности в студию. Работа с деньгами в программе должна быть точной, иначе проблема может быть очень много.

    G>>Что делать если в один прекрасный момент появится необходимость это время увеличить в 2 раза?

    A>А в чём проблема-то? Кеш обновляется не по таймеру.
    И как же он обновляется? Вытягиванием changeset с сервера при каждом обращении?

    A>>>Это можно сделать только на сервере.

    G>>Тогда зачем что-то делать на клиенте, если корректный результат возможен только при вычислении на сервере?
    G>>Ведь все эти кеши, запреты удаления, прочая муть только от того что хочется что-то безопасно делать на клиенте.
    A>Нет. Запрет удаления с кешем совсем не связан. Ты ничего не понял и решил свалить всё в кучу. В Active Directory, например, объекты удаляются в распределённой системе. И ничего, всё работает. Запрет удаления это не ограничение вызванное использованием кеша, это совершенно отдельная песня.
    Ну и чем же запрет удаления вызван? Судя по твоим ответам выше единственная причина для такого поведения — желание работать якобы без потери целостности данных, а это желание как раз возникает из-за работы с локальной репликой там где не надо.

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

    Так если постоянного соединения нет, то локальная копия БД и репликация изменений, других вариантов понка не придумали. Решения я уже писал выше.

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

    A>Не любая, потому что не все данные можно редактировать, но некоторые могут. И, кстати, часто возможность продолжить работу важнее, чем возможность продолжить её корректно. Например, если филиал магазина с двухтысячным ассортиментом отрубился от сети, а в центре обновили цены на три товара, лучше продолжить продавать по старым ценам, а не закрывать филиал.
    Угу, опять сведение к разделению данных между пользователями.
    Re[27]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 21.04.09 16:28
    Оценка: +1
    Здравствуйте, vdimas, Вы писали:

    V>>>Да, хаскелисты тоже так считают. Хотя, полиморфизм по алгебраическим типам — это опять же и снова классика динамической типизации.

    EC>>Это в каком месте полиморфизм по алгебраическим типам динамически типизирован?

    V>В месте определения значения дискриминатора, вестимо. Конкретно в Хаскеле — в соотв. строке матчинга.

    Т.е. у нас может быть ошибка типизации времени выполнения?
    Ты уверен, что имеешь в виду именно динамическую типизацию, а не диспетчеризацию?
    now playing: Dubfire — I Feel Speed (Dubfire Original Club Mix)
    Re[42]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 22.04.09 02:30
    Оценка: -1
    Здравствуйте, adontz, Вы писали:

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


    G>>Так это ты демагогию разводишь. Есть конкретная ситуация со скидками, ты можешь сказать как будет осщуствляться кеширование в таком случае? Конкретно время и условия устаревания, способ обновления кеша.

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


    G>>А вот насчет указания сервеа я не понял. Нету ведь постоянной связи с сервером, да и как будет выполняться оповещение?

    A>При синхронизации. Например взял заказ на 50 банок, на складе реально 48 (2 списали как разбитые), при синхронизации попросят заказ скорерктировать, так как остатки склада устарели.
    Ты изобретаешь велосипед. Его давно уже сделали, Sync Services называется.
    Только это далеко не единственный и далеко не всегда самый эффективный вариант кеширования.
    Но до тебя это не доходит никак.


    A>>>Нет, в данном случае разделение не при чём. Дело в реальных потребностях бизнеса. От того что что-то не обновилось нельзя всё останавливать.

    G>>Можешь не доказывать, я уже понгял с какими программами ты работаешь. Такой подход применим в очень небольшом количестве случаев.
    A>Я в своих рассуждениях ссылался минимум на 4 типа программ для систем с весьма разными бизнес-процессами, но ты видимо слишком неопытен чтобы это понять.
    Можешь ссылаться хоть на 8 типов. Все равно они все сводятся к одному сценарию. А те которые не сводятся ты искусственно пытаешься свести к такому сценарию.
    Re[45]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 22.04.09 06:40
    Оценка: -1
    Здравствуйте, gandjustas, Вы писали:

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

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

    Я же говорю, что ты не опытный
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[28]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 23.04.09 10:51
    Оценка: -1
    Здравствуйте, EvilChild, Вы писали:

    EC>Ты уверен, что имеешь в виду именно динамическую типизацию, а не диспетчеризацию?


    А вопрос-то не так прост. Всегда, когда мы делаем динамическое приведение типа, мы имеем диспетчеризацию как минимум на 2 ветки — успешную и неуспешную. А если еще поднятся на шаг выше, то динамическое приведение обычно и используется там, где предполагается некая _группа_ типов, иначе можно обойтись статической типизацией.

    ---------
    Согласен, что матчинг помимо подобного динамического определения типа еще умеет и значения матчить. Так же напомню, что шли обсуждения конструкций для C# типа этой:
    switch(obj.GetType()) {
      case typeof(A): ...
      case typeof(B): ...
    }

    Но, думается, вместо подобной билеберды введут все-таки матчинг, ибо он более удобен в этих самых задачах, для которых сегодня используется динамическая типизация.
    Re[53]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 23.04.09 14:00
    Оценка: -1
    Здравствуйте, gandjustas, Вы писали:

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

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

    Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер.

    G>>>Бред, в "большом бизнесе" интернет есть в кажом офисе.

    A>>Большой бизнес делается не только в офисе, это раз, и не может полагаться на работоспособность интернета, это два.
    G>А где же еще делается "большой бизнес"?

    Вне офиса

    G>И почему не может полагаться на работоспособность инета?


    А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня.

    G>Интернет — самая надежная сеть на сегодняшний момент.


    Из общедоступных, как минимум GSM сети надёжнее интернета.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[58]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 25.04.09 09:12
    Оценка: +1
    Здравствуйте, adontz, Вы писали:

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


    G>>>>И каким образом должно учитываться содержание?

    G>>При желании сам разработчик может разбит документ на несколько.

    A>Нет механизма client side includes, так что сам разработчик разбить документы на несколько не может.

    Есть, фреймы называется.
    А уж с помощью AJAX вообще можно сделать все.

    G>>Вне офиса много чего находится. Я вот сильно сомневаюсь что "большой бизнес", с использованием компьютеров (именно такой нас интересует), делается в сортире.

    G>>Так что давай конкретнее.
    A>Послушай, если ты не знаешь что такое "вне офиса", то это конечно очень странно. По-твоему строители, например, в кабинете сидят? Есть виды деятельности где большая часть сотрудников занимается не перекладыванием бумажек, а чем-то другим.
    Еще раз напомню что нас интересует тот бизнес, который делается с применением компьютеров.
    Cеть бабушек, торгующих семечками, нас не интересует.

    A>>>Есть фирмы для которых пара часов в месяц не мелочь. Вот представь себе что так.

    G>>Так они банально платят деньги чтобы получить 99,999% работосособности.
    A>Ты такой аптайм ни за какие деньги не купишь, потому что работоспособность линии связи не в полной мере зависит от деятельности владельца линии.
    Не надо устраивать плачи в пользу бедных, за деньги можно купить любой аптайм, существует резервирование каналов и прочая хрень, которая в разы уменьшает вероятность отключения.


    G>>Нужен, только не постоянно.

    G>>Можно по расписаних синхронизироватся через супер-пупер надежный GSM\GPRS.

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

    Не надо налоги считать по факту совершения проводки, отчетность сдается за период.
    В 1С например "документы" — информация о движении средств, отделена от "регистов" — непосредственно учетных единиц. Правла проведения документов можно менять, поменяются регистры, но документы останутся теми же.
    Re[59]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 25.04.09 09:46
    Оценка: -1
    Здравствуйте, gandjustas, Вы писали:

    A>>Нет механизма client side includes, так что сам разработчик разбить документы на несколько не может.

    G>Есть, фреймы называется.
    G>А уж с помощью AJAX вообще можно сделать все.

    Эти все технологии имеют очевидные минусы. Например, нельзя получить адрес страницы.

    A>>Послушай, если ты не знаешь что такое "вне офиса", то это конечно очень странно. По-твоему строители, например, в кабинете сидят? Есть виды деятельности где большая часть сотрудников занимается не перекладыванием бумажек, а чем-то другим.

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

    У тебя очень узкое понятие компьютера, вспомни о покетах.

    G>>>Так они банально платят деньги чтобы получить 99,999% работосособности.

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

    Видишь ли, резервирование каналов не работает, если кабели разных компаний лежат в одной траншее. То есть, конечно, можно себя убеждать что покупая тырнет у разных фирм ты что-то меняешь, но хорошо бы и с физической топологией ознакомиться для начала. Реальная альтернатива кабелям — беспроводные сети. К сожалению качество работы разных WiMAX пока не впечатляет, а GSM провайдеры берут дорого.

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

    G>Не надо налоги считать по факту совершения проводки, отчетность сдается за период.
    G>В 1С например "документы" — информация о движении средств, отделена от "регистов" — непосредственно учетных единиц. Правла проведения документов можно менять, поменяются регистры, но документы останутся теми же.

    Ага, ага. Вот почему в 1С есть понятие "восстановления последовательности" Нельзя считать налоги постфактум если от конечной цены меняются налоги. Такое документы надо проводить оперативно. Кстати, 1С в этом смысле полностью облажались предложив рассчитывать себестоимость раз в 5 минут.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[72]: Проблемы организации OR-мапинга
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 28.04.09 11:44
    Оценка: +1
    Здравствуйте, adontz, Вы писали:

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


    A>>>В 9:00 агент сделал синхронизацию в офисе и выехал на маршрут, в 10:00 приехала партия товара по более высокой цене, чем раньше , в 11:00 агент входит к клиенту.

    S>>Ой, как интересно. А вы себестоимость по какой модели учитываете — FIFO, LIFO, средневзвешенной или как?

    A>Налоговая требует партионный учёт, так что FIFO ил LIFO. На практике FIFO. Средневзвешенная система тоже используется для анализа.

    Давно не работал с бух учетом, но политика списания себестоимости прописвывается для фирмы (требовать можно только то что прописано в Учетной политике торговой организации).
    Подгон вполне возможен. Например в рознице, где не ведется (или ведется, но для себя) потоварная продажа, а в конце месяца на основании инвентаризации создается один документ продаж, равный сумме выручки за месяц.
    Так как возможно множество пересортиц итд. Главное, что бы предприятие работало с общей прибылью. Но могу конечно и ошибаться, основываясь на старом опыте.
    Аналогично поступают и с возвратами, редактируя задним числом оптовую отгрузку итд. Вариантов много. Главное соответствовать требованиям налоговой и встречным проверкам.
    и солнце б утром не вставало, когда бы не было меня
    Re[76]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 29.04.09 07:31
    Оценка: +1
    Здравствуйте, adontz, Вы писали:

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


    A>>>Агент берёт заказ. Товар будет клиенту доставлен самое скорое на следующий день.

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

    G>>Товар может валяться на складе неоприходованным много времени.

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

    G>>Обычно суетиться все начинают при наступлении конца отчетного периода.

    A>В быдлофирмах может и так. У нас товар оприходуется в день прибытия приямо при разгрузке.
    Угу, я тоже так думал, пока не увидел сколько времени кладовщики оприходовали товар с двух фур.
    За время оприходования небольшую часть успели продать.

    A>>>У нас происходит резервирование товара. Нельзя продать то, чего нет.

    G>>Резвервирование (как часть складского учета) никак не связано с бухгалтерским учетом.
    A>Я просто объяснил почему невозможен описанный тобой сценарий.
    Невозвожен где?
    В бухгалтерском учете все возможно
    Re[81]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 29.04.09 10:23
    Оценка: +1
    Здравствуйте, Sinclair, Вы писали:

    A>>Антон, я очень рад за тебя с 1991 года, но достаточно странно видеть, твои теоретические аргументы, на фоне реальных проблем возникающих в реальной жизни.

    S>Рома, пока что мы говорим не о "проблемах, возникающих в реальной жизни", а о твоём восприятии того, как эти проблемы ложатся на софт. У меня первые годы оно тоже было достаточно далеко от реальности.

    Есть хороший "критейрий истины" (в кавычках потому что ни разу не критерий), заключется в том чтобы выяснить как решаются указанные проблемы без компьютера. Ведь проблемы согласованности данных, идентичности данных, совсестной работы с данными не из компьютера появились. Если проблема решаема без компьютера и некоторого постороннего знания, то вполне можно тоже сделать и в программе.
    Вот я например не вижу как может быть решена проблема с курьером и прагыющей ценой.
    Re[45]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 06.05.09 00:19
    Оценка: +1
    Здравствуйте, vdimas, Вы писали:

    V>Динамическое приведение типов в CLR (не преобразование, а именно приведение без изменения значения) — суть рантайм-тест этой "разметки", матч по алгебраическим типам в хаскеле — аналогично.


    Ага. Вот только к динамической типизации это отношения не имеет. Ведь все типы известны во время компиляции.
    АлгТД — это вид полиморфизма. Эдакое безопасное объедение.

    Никто же не называет С++ динамически-типизированным только из того факта, что в нем поддерживаются виртуальные методы которые пиводят к тому, что реальный тип объекта становится известным только во время выполнения?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[47]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 07.05.09 10:11
    Оценка: +1
    Здравствуйте, vdimas, Вы писали:

    V>...Отсюда я и считаю, что для тех задач, где сегодня мы используем динамическое приведение типов (даже если оно безопасное с т.з. возможной неверной интерпретации памяти), алгебраические типы будут более удобны, и более безопасны, но уже на уровень выше — в алгоритмическом плане, преодолевая то самое правило Лисков в ввиду закрытости группы (но опять же, только в случае контроля компилятором полноты матчинга, иначе та самая "дыра" остаётся в первозданном виде).


    Я так и не понял какое отношения все эти рассуждения имеют к динамической типизации в стаически-типизированных языках?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[47]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 08.05.09 02:57
    Оценка: -1
    Здравствуйте, vdimas, Вы писали:

    EC>>В качестве резюме дискуссии, если её ещё кто-то читает:

    EC>>идём читать The Haskell 98 Report по ссылке и находим 3.13 Case-выражения,
    EC>>чуть дальше читаем
    EC>>

    EC>>Case-выражение должно иметь по крайней мере одну альтернативу, и каждая альтернатива должна иметь по крайней мере одно тело.
    EC>>Каждое тело должно иметь один и тот же тип, и все выражение должно быть того же типа.


    V>Опять у кого-то кое-где каша.

    V>Каждое тело должно иметь один и тот же тип, т.к. это будет тип всего case-выражения, но этот тип может быть произвольным, не связанным с аргументом case.

    V>Так что не вижу тут никакого резюме, даже не вижу связи с обсуждаемым.


    Ок, ваш слив засчитан.
    now playing: Dubfire — I Feel Speed (Alternative Mix)
    Re[41]: Проблемы организации OR-мапинга
    От: artelk  
    Дата: 08.05.09 09:58
    Оценка: +1
    Здравствуйте, vdimas, Вы писали:

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


    A>>Совсем не обязательно реализовывать алгебраические типы через группировку других типов и т.п.


    V>...


    V>В этом примере ты всего лишь разместил по одному адресу значения для случаев X и Y, потому как это оказалось возможным с т.з. системы типов CLR (тип массива не зависит от последней размерности). Если бы зависело, как в С++, то так просто не вышло бы. А в рассматриваемых мною исходниках Хаскеля по одному адресу размещаются значения вообще различных типов, сразу после дискриминатора, такое размещение аналогично union из С/С++. Но в отличии от последнего, язык не предоставляет ср-ва для потенциально неверной реинтерпретации памяти.


    Типы параметров конструкторов X и Y не обязаны быть одинаковыми (Int из примера). В плюсах было бы что-нибудь вроде "char* data = new char[size]" и интерпретацией памати "(int*)(data+2)", правда со всякими выравниваниями пришлось бы бороться, похоже.
    Только Хаскель ведь не в C++ транслируется перед компиляцией. Если б транслировался, тогда да, проще всего было бы сделать через union, но это было бы внутренней деталью реализации компилятора, а не чем-то, относящесмя к самому Хаскелю.
    Вся интерпретация памяти жестко инкапсулирована. Доступ к полям осуществляется только по матчу — путем передачи лямбд для каждого варианта. Runtime ошибок здесь быть не может вообще.

    V>- матч перемудрил, там просто case по дискриминатору надо сделать, безо всяких MatchResult, matchX и matchY.

    Ага, можно въинлайнить matchX и matchY в Match и избавиться от MatchResult. Просто хотелось акцентировать на том, что matchX и matchY по отдельности — private методы
    Re: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 08.04.09 17:57
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Я не использую его в коммерческих проектах. К сожалению, у меня в банке очень жёсткое полиси на весь софт. Средства разработки тоже ограничены, например, из дистрибутива студии вакинут даже VB. Но как только выйдет релиз 1.0 я попытаюсь зареквестить Немерлю хотя бы для оценки возможностей. А там кто знает, может и в продакшин протащу когда-нибудь. В общем, это не просто моё желание или нежелание, это борьба с бюрократической машиной, в которой (в борьбе) ошибок быть не должно.


    Tom>Пошёл полкупать соль и спички. Новый банковский кризих похоже будет относительно скоро


    Всё как раз наоборот. Если бы я использовал в банках не BLToolkit, а как ты хочешь precompile генерацию кода, то тебе уже давно не на что было бы покупать соль и спички. А если бы я использовал Немерле, то и кризиса не было бы.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[2]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 08.04.09 18:55
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    IT>>>Я не использую его в коммерческих проектах. К сожалению, у меня в банке очень жёсткое полиси на весь софт. Средства разработки тоже ограничены, например, из дистрибутива студии вакинут даже VB. Но как только выйдет релиз 1.0 я попытаюсь зареквестить Немерлю хотя бы для оценки возможностей. А там кто знает, может и в продакшин протащу когда-нибудь. В общем, это не просто моё желание или нежелание, это борьба с бюрократической машиной, в которой (в борьбе) ошибок быть не должно.


    Tom>>Пошёл полкупать соль и спички. Новый банковский кризих похоже будет относительно скоро


    IT>Всё как раз наоборот. Если бы я использовал в банках не BLToolkit, а как ты хочешь precompile генерацию кода, то тебе уже давно не на что было бы покупать соль и спички. А если бы я использовал Немерле, то и кризиса не было бы.


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

    Так что я пока твоих непониваю аргументов. Вон тот же EF/Linq2Sql генерируют себе энтити в компайлтайм или даже дизайнтайм и ничего.

    Ы?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[3]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 08.04.09 19:08
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Игорь, разницы в моём подходе, с генерацией кода во время билда и в рантайме нет.


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

    Tom>Так что я пока твоих непониваю аргументов. Вон тот же EF/Linq2Sql генерируют себе энтити в компайлтайм или даже дизайнтайм и ничего.


    В компайл тайм они ничего не генерируют. Они точно так же генерируют мусор, если угодно исходный мусор, по аналогии с исходым кодом.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[4]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 08.04.09 19:21
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    Tom>>Игорь, разницы в моём подходе, с генерацией кода во время билда и в рантайме нет.


    IT>Разница есть. BLToolkit генерирует исполняемый код, а твои генераторы мусор.


    Tom>>Так что я пока твоих непониваю аргументов. Вон тот же EF/Linq2Sql генерируют себе энтити в компайлтайм или даже дизайнтайм и ничего.


    IT>В компайл тайм они ничего не генерируют. Они точно так же генерируют мусор, если угодно исходный мусор, по аналогии с исходым кодом.

    Видимо я тебя не понимаю. Без конкретных примеров мы к пониманию не прийдём. Их есть у тебя? Я могу свою идею пояснить.

    Я предпологаю, что TSQL код у нас будет отделён от C# кода.
    Тоесть в тесте писать запросы мы не будем РУКАМИ.
    Но, C# враперы над TSQL запросами будут всё же строится динамически в рантайме.
    Как это будет.

    Допустим у нас есть каталог SQL где лежат файлы, в каждом из них для простоты допустиь ad hoc запрос, а не хранимка.
    Во compile time мы будем выполнять их используь FMTONLY и получать метаданные о resultset-е.
    По ним мы будем строить соответствующий класс для resultset-а и функцию для выполнения данного ad hoc запроса.
    Естественно что в сгенерированном коде будет присуствовать само тело запроса поднятое из файла.

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

    Зачем нужно хранить TSQL отдельно от кода — в первую очередь что бы иметь нормальную возможность провалидировать этот TSQL и рефакторить его отдельно от кода.
    Например при помощи той же VSTS Database Edition GDR.

    Можешь на примерах как то описать принципиальные ошибки в таком подходе?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[5]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 08.04.09 23:42
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Зачем нужно хранить TSQL отдельно от кода — в первую очередь что бы иметь нормальную возможность провалидировать этот TSQL и рефакторить его отдельно от кода.


    Кстати, забыл про SQL отдельно от кода. Иногда приложение можно существенно оптимизировать, генерируя и оптимизируя код SQL на клиенте. За примером далеко ходить не надо — это наш сайт и конкретно MainList.aspx. Переписывание кода со статического SQL на Linq2SQL решило проблему, над которой мы бились несколько лет, пытаясь тщетно подкрутить монстрообразный запрос индексами и хинтами.

    Так же напрочь убивается повторное использование кода. Десять запросов, отличающихся одной колонкой — это будет десять SQL-ей, вместо одного с параметром.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[6]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 09.04.09 05:49
    Оценка:
    IT>Начнём с того, что всё это элементарно не имеет никакого смысла. Самое сложное в DAL — это рутина ручной набивки аксессоров, которая хоть так хоть эдак уходит. После этого при разработке, например, какой-нибудь формы или отчёта, на разработку SQL запроса уходит два часа, на DAL и BL пять минут, а на UI неделя. Ну давай добавим ещё две минуты на твой ad hoc класс. На неделю UI это всё равно никак не повлияет. Не там ты оптимизируешь.
    Да, но ты забываешь про поддержку. Дело в том, что генерацию хочется использовать не по моей прихоти. А по нужде так сказать.
    Сейчас я думаю у нас около тысячи OLEDB акцэсоров, и поверь мне это один из самых геморойных мест проекта.
    Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы.
    Когда мы пишем руками — мы не имеем ни первого ни второго.
    Так же про проверку TSQL. Если он у тебя в коде — то ты вообще в полной засаде.

    IT>Но допустим вы нагенерировали кучу ad hoc классов. Сразу возникает несколько вопросов.


    IT>1. Для запросов SELECT * FROM Person и SELECT * FROM Person WHERE ID = 1 у тебя будет генерироваться один класс или два?

    Два по умолчанию. Но будет возможность явно указать Entity класс. Нужно это по нескольким причинам:
    1. К сожалению у нас есть CLR based stored procedures. Для них невозможно получить метаданные на основе FMTONLY
    2. Что бы в некоторых случаях не мапить одно на другое, хотя реально таких мест будет очень мало.

    IT>2. Как ты собираешься задавать имена своим классам?

    По ими файла ad hoc запроса. Кстате я забыл упомянуть что в ad hoc запросы как и в хранимки можно будет передавать параметры.
    Таким образом мы получим что то среднее между хранимыми процедурами и обычными запросами.
    Среднее в том плане, что сами запросы будут отделены от кода, но всё же будут жить на клиенте.
    Сторы сейчас одна из основных болей для нас, так как обновление базы в случае их применения — это гарантированный down time для On-Demand систем.

    IT>3. Все свои классы ты будешь хранить в одном namespace или в разных? Как это задавать?

    Вариантов миллион. Самый простой при помощи каталогов. Если надо группировать запросы в namespace — создавай каталог.

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

    Не готов и очень хочется этого избежать.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[6]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 09.04.09 05:49
    Оценка:
    IT>Так же напрочь убивается повторное использование кода. Десять запросов, отличающихся одной колонкой — это будет десять SQL-ей, вместо одного с параметром.
    Так параметры можно будет использовать, ессно они нужны.

    А по поводу генерации прямо в коде, тут есть свои за и против.

    Скажем так, я против того что бы такой подход использовать повсеместно, но как исключение из правила — почему нет
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[5]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 09.04.09 11:59
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Зачем нужно хранить TSQL отдельно от кода — в первую очередь что бы иметь нормальную возможность провалидировать этот TSQL и рефакторить его отдельно от кода.

    Tom>Например при помощи той же VSTS Database Edition GDR.

    Tom>Можешь на примерах как то описать принципиальные ошибки в таком подходе?


    То что ты описал, только без приседаний с выносом SQL-я в одтдельные фалы сделали в виде макры несколько лет назад: http://nemerle.org/SQL_macros
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[7]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 09.04.09 13:01
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Так же напрочь убивается повторное использование кода. Десять запросов, отличающихся одной колонкой — это будет десять SQL-ей, вместо одного с параметром.

    Tom>Так параметры можно будет использовать, ессно они нужны.

    SELECT * Table WHERE Field1 = 1
    SELECT * Table WHERE Field2 = 1

    Как ты тут будешь использовать параметры?

    Tom>А по поводу генерации прямо в коде, тут есть свои за и против.

    Tom>Скажем так, я против того что бы такой подход использовать повсеместно, но как исключение из правила — почему нет

    Почему против, какие аргументы?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[8]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 09.04.09 13:35
    Оценка:
    IT>Как ты тут будешь использовать параметры?

    SELECT * Table WHERE Field2 = @local_Field2
    Проблем не вижу. Генератор по формату имени поймёт что это параметр передаваемый из вне а не локальная переменная использующаяся в скрипте.

    Tom>>А по поводу генерации прямо в коде, тут есть свои за и против.

    Tom>>Скажем так, я против того что бы такой подход использовать повсеместно, но как исключение из правила — почему нет
    IT>Почему против, какие аргументы?
    Да я вроде уже не раз писал аргументы, тут например Re[11]: Nemerle &amp; Real Life
    Автор: IT
    Дата: 09.04.09


    основная причина разделения C# и TSQL кода — это вопросы поддержки.
    Когда TSQL живёт внутри C# эта поддержка на порядок усложняется.
    А так же исчезает compile time проверка этого TSQL.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[9]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 09.04.09 14:05
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>SELECT * Table WHERE Field2 = @local_Field2

    Tom>Проблем не вижу. Генератор по формату имени поймёт что это параметр передаваемый из вне а не локальная переменная использующаяся в скрипте.

    Ты не понял. Ещё раз.

    SELECT * Table WHERE Field1 = 1
    SELECT * Table WHERE Field2 = 1

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

    Tom>>>А по поводу генерации прямо в коде, тут есть свои за и против.

    Tom>>>Скажем так, я против того что бы такой подход использовать повсеместно, но как исключение из правила — почему нет
    IT>>Почему против, какие аргументы?
    Tom>Да я вроде уже не раз писал аргументы, тут например Re[11]: Nemerle &amp; Real Life
    Автор: IT
    Дата: 09.04.09


    Это ссылка на моё сообщение.

    Tom>основная причина разделения C# и TSQL кода — это вопросы поддержки.

    Tom>Когда TSQL живёт внутри C# эта поддержка на порядок усложняется.
    Tom>А так же исчезает compile time проверка этого TSQL.

    Это ты про то как у вас было раньше или у тебя есть реальный опыт использования этого в других условиях, особенно с linq?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[9]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 09.04.09 19:51
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Как это не имеем? А как же Linq2Sql?

    Tom>Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем.

    Влад говорит не о ряде причин, а том, что в linq2sql неверно сделаны insert/update/delete. Зато select, который нужен в 90% случаев, сделан вполне добротно. А что ещё есть в твоём ряде причин?

    Tom>И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет.


    Ну так MS и в твой генератор ресурсы вкладывать не будет.

    Tom>Ну и опять это перенос в код запростов TSQL, хоть и не в явном виде, что опять же усложняет рефакторинг базы.

    Tom>Который кстате намечается серьёзный.

    Как раз linq2sql позволяет проводит рефакторинг базы с применением компилятора C# и студии. А что даст твой валидатор SQL? Список ошибок на экране? И что ты с ним будешь делать?

    Tom>И мы обсуждали проблемы моей кодогенерации а не линк. У линка заметь опять же своя кодогенерация. И для стор между прочим он генерирует resultset файл. Ну или акцэсор. Незнаю как лучше назвать.


    Что касается спроков, то здесь у BLToolkit конкурентов нет. Вообще.

    Tom>Я проблем пока реальных на примерах так и не увидел. Есть некоторые нюансы конечно но шоу стоперов реальных я пока не вижу.


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

    Tom>Размазывания в виде конткатенаций скорее всего ожидать не стоит, а вот размазывания по разным C# файлам и возможно сборкам вполне (это если писать TSQL в коде)


    А ты всё в одном файле и в одном классе собираешься держать?

    Tom>А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует.

    Tom>Какой смысл себя ограничивать так? Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь.

    Остальные 80% элементарно достигаются применением таблиц-функций и получающимся смешанным стилем клиентский код/SQL.

    Tom>>>Два по умолчанию. Но будет возможность явно указать Entity класс.

    IT>>Каким образом?
    Tom>Явным, в конфиге.

    Т.е. на каждый запрос ещё и строчка в конфиге. Круто! Лучше ещё немного подумай, может быть окажется, что проще использовать специализированные комментарии в самом SQL.

    Tom>Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты.


    Это, конечно, очень удобно, иметь 1000 файлов в 500 каталогах в каждом по 2 файла, а то и по одному.

    IT>>Я думал, что по имени файла лучше именовать метод аксессора. Но допустим это будет имя возращаемого типа. Тогда такой вопрос. Как будет именоваться имя метода аксессора.

    Tom>Я тут думаю тебе лечше посмотреть как это делает например тот еж линк для стор. В нашем случае имя файла ad hoc запроса будет играть роль имени базового на основе которого будут строится другие имена.

    PersonNamespace_Person_List_GetPersonByCriteria15?

    IT>>Ваш метод возвращает информацию для одного типа, но в одном случае это Person, во втором List<Person>, в третьем Dictionary<int,Person>? Нужно ещё как-то уметь задавать возвращаемые значения как скалярные типы.

    Tom>С скалярными значениями, их просто лучше избегать.

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

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

    Tom>Тем более что мы движемся в сторону ad hoc запростов вместо хранимок. А вот с тем возвращать ли коллекцию или один обьект — это хороший вопрос. На вскидку. Для таблицы будут генерироваться не только C# но и CRUD TSQL. Таким образом нам надо только таблица и мы по ней сможем сгенерировать SelectAll/SelectById/Insert/Delete/Update C# с TSQL-ем в нём. В этом случае мы чётко знаем что возвращается.


    Это CRUDL. Как я уже говорил, эта задача решается вообще без всяких генераторов одним библиотечным кодом. Более того генерировать CRUDL — это генерировать кучу невостребованного мусора. Дай бог, чтобы ты использовал хотя бы 20% от сгенерированного.

    Tom>Задача сводится к тому как понять, что возвращает некоторый ad hoc/sp. Одну сущность или коллекцию.

    Tom>Буду думать, возможно забиться на имя файла. Или опять же как то каталоги использовать.

    Специализированные комментарии в SQL помогут отцу генерации.

    Tom>Если тут подумать то имя файла/каталог/конфиг — всё это мета информация заданная просто разными способами.

    Tom>Надо просто подобрать более удобный.

    Вот именно. И лучшая метаинформация — это декларация непосредственно в коде.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[11]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 09.04.09 19:59
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Разные поля, используемые в запросе, а не значение параметра. Редко, но бывает нужно.

    Tom>А, понятно, дело в том что от обезьяны с гранатой спасения нет.

    Обезъяна с гранатой не знает что с ней делать. А если гранатой умело воспользоваться, то можно легко изничтожить тонны тупого копипейстного кода. И поддержка такого кода только выигрывает.

    Tom>Особенно если туда ещё и условие присобачить.

    Tom>Но и задачи спастить от идиота не ставится.
    Tom>Ну и у нас код ревью есть абсолютно всех changeset-ов.
    Tom>Такое можно вылавливать.

    Что вылавливать, копипейст? Выловил и что дальше?

    IT>>Это ты про то как у вас было раньше или у тебя есть реальный опыт использования этого в других условиях, особенно с linq?

    Tom>Конечно из жизни. Тяжёлой и горькой

    Из той прошлой жизни на C++? Или ты уже и в новой успел поприменять старые методы?

    Tom>Если хочешь можно с примерами. С линком есть опыт но небольшой и не менее горький.

    Tom>В наших проектах он не применим из за убогости. да и смысла применять мёртвый проект я не вижу.
    Tom>Ну и опять же это перенос TSQL в не явном виде в код. Что полюбому усложняет поддержку рефакторинг.

    Я не знаю кто тебе такое напел, но видимо ты либо неправильно понял, либо плохо разобрался. За технологиями вроде Linq будущее. Не за прекомпайл-тайм генераторами кода, которые всё никак вот уже лет 20 не завоюют мир, а именно за генерацией кода в run-time, а ещё лучше в compile-time.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[9]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 09.04.09 20:04
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>>>Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы.

    Tom>>>Когда мы пишем руками — мы не имеем ни первого ни второго.
    IT>>Как это не имеем? А как же Linq2Sql?
    Tom>Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем. И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет.
    Linq2SQL уже развиваться не будет, смотрите в сторону EF.

    Tom>Ну и опять это перенос в код запростов TSQL, хоть и не в явном виде, что опять же усложняет рефакторинг базы.

    Tom>Который кстате намечается серьёзный.
    У вас рефакторинг БД случается чаще\имеет больший объем, чем рефакторинг кода?

    Tom>А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует.

    Tom>Какой смысл себя ограничивать так? Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь.
    Инкапсулируйте сложность на уровне БД, создавайте вьюхи для развесистых выборок, используйте хранимки, не возвращающие результат, для операций изменения данных.
    Кроме того Linq2SQL позволяет скалярные функции использовать в теле запросов. EF покачто такого не умеет.

    Tom>Явным, в конфиге. Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты.

    Со временем ручной кодинг таких вариантов будет отнимать все больше времени.
    Re[18]: Nemerle & Real Life
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 08:48
    Оценка:
    IT>Обезъяна с гранатой не знает что с ней делать. А если гранатой умело воспользоваться, то можно легко изничтожить тонны тупого копипейстного кода. И поддержка такого кода только выигрывает.
    Игорь, но ведь ьты предлагаешь писать больше кода. Как минимум классы resultset-ов.

    IT>Что вылавливать, копипейст? Выловил и что дальше?

    Мне кажется это уже не конструктивно.

    IT>Из той прошлой жизни на C++? Или ты уже и в новой успел поприменять старые методы?

    Опять же это не тот стиль в котором можно прийти к чему то конструктивному

    IT>Я не знаю кто тебе такое напел, но видимо ты либо неправильно понял, либо плохо разобрался. За технологиями вроде Linq будущее. Не за прекомпайл-тайм генераторами кода, которые всё никак вот уже лет 20 не завоюют мир, а именно за генерацией кода в run-time, а ещё лучше в compile-time.

    Напела мне жизнь. Допустим в линке есть некоторая поддержва в явном виде выборки данных. и нету поддержки UPDADE/DELETE/INSERT. В выборке данных есть поддержка всего процентов наверное 10-20 от всей мощи TSQL. Вопрос, нахрена козе баян? И что делать с действительно сложными запросами, которых у нас в огромном количестве. Да и смысла подменять один язык TSQL другим linq я не вижу. Тем более, что ты упорно игнорируешь тот факт что он мёртв.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[16]: Nemerle & Real Life
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 08:48
    Оценка:
    IT>Ну так MS и в твой генератор ресурсы вкладывать не будет.
    как это не будет если они его написали T4 используется в самой студии и для того же линка.

    IT>Что касается спроков, то здесь у BLToolkit конкурентов нет. Вообще.

    От стор мы отказываемся, для On Demand систем это зло которое затрудняет обновление системы без downtime-а

    Tom>>Я проблем пока реальных на примерах так и не увидел. Есть некоторые нюансы конечно но шоу стоперов реальных я пока не вижу.


    IT>Дело не в стоперах, дело в замедлителях и заколебателях. Для конкретных примеров, как я уже говорил, заведи себе тетрадочку.


    Tom>>Размазывания в виде конткатенаций скорее всего ожидать не стоит, а вот размазывания по разным C# файлам и возможно сборкам вполне (это если писать TSQL в коде)


    IT>А ты всё в одном файле и в одном классе собираешься держать?


    Tom>>А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует.

    Tom>>Какой смысл себя ограничивать так? Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь.
    IT>Остальные 80% элементарно достигаются применением таблиц-функций и получающимся смешанным стилем клиентский код/SQL.
    Не не не не, Дэвид Блэйн, это чёрная магия к тому же имеющая большие ограничения.

    IT>PersonNamespace_Person_List_GetPersonByCriteria15?

    Игорь, если хочется, то любую идею довести до идиотизма.

    Весь разговор сводится к тому что BLToolkit это хорошо, но на мои аргументы я так ответа твоего не услышал. Ещё раз повторю:
    При использовании BLToolkit-а приходится:
    1. Писать руками классы акцэсоров/resultset-ов. Что в свою очередь:
    1.1 Затрудняет поддержку. Так как если селект возвращает новое поле, или не возвращает поля вообще то во время компиляции ты об этом никогда не узнаешь.
    1.2 делает невозможным переход на BLToolkit для Legacy прилоджений. Допустим у нас 1000 хранимок возвращабщих resultset. Никто не будет руками писать и поддерживать эту 1000 классов.
    2 Поощеряет написание TSQL в коде. Что усложняет поддержку. А именно:
    2.1 Проверить синтаксис TSQL можно только в runtime.
    2.2 Делает невозможным использовать средства рефакторинга/анализа TSQL кода, такие как VSTS Database Edition GDR и прочие.
    2.3 Делает невозможным валидацию кода в compile time средствами, которые являются аналогом Fx Cop но для TSQL. (фактически анализ кода)

    Если интересно продолжать то хотелось бы аргументированно и с примерами.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[10]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 08:58
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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


    Tom>>>>Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы.

    Tom>>>>Когда мы пишем руками — мы не имеем ни первого ни второго.
    IT>>>Как это не имеем? А как же Linq2Sql?
    Tom>>Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем. И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет.
    G>Linq2SQL уже развиваться не будет, смотрите в сторону EF.
    В его сторону рано пока смотреть, но я бы сказал ещё в зачаточном состоянии.
    Да и двигается он в неправильном направлении, в стороно полного ORM решения.
    Если хочется ORM, да ещё и с нормальной поддержкой линка — то лучше пока использовать сторонние решения.
    Например LLBGenPro

    G>У вас рефакторинг БД случается чаще\имеет больший объем, чем рефакторинг кода?

    Это трудно оценить но по сложности база конечно опережает прикладной код.

    Tom>>А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует.

    Tom>>Какой смысл себя ограничивать так? Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь.
    G>Инкапсулируйте сложность на уровне БД, создавайте вьюхи для развесистых выборок, используйте хранимки, не возвращающие результат, для операций изменения данных.
    G>Кроме того Linq2SQL позволяет скалярные функции использовать в теле запросов. EF покачто такого не умеет.

    Tom>>Явным, в конфиге. Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты.

    G>Со временем ручной кодинг таких вариантов будет отнимать все больше времени.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[9]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 09:06
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Как это не имеем? А как же Linq2Sql?

    Tom>Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем. И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет.

    Только не надо домысливать слова Влада. Я сетовал на то, что Linq не поддерживает DML. Но я никогда не говорил, что Linq идет в лес. Наоборот, я считаю Linq одним из самых перспективных средств доступа к данным.

    К тому же уверен, что IT под термином Linq2Sql подразумевал не конкретный провайдер, а сам Linq применительно к доступу к БД. Провайдер же может быть и другой. Скажу тебе по секрету, IT пишет свой провайдер.

    Tom>Ну и опять это перенос в код запростов TSQL, хоть и не в явном виде, что опять же усложняет рефакторинг базы.


    Linq — это не TSQL. Это даже не SQL. Хотя к последнему он ближе.
    Что касается рефакторинга БД, я тебе уже говорил. Надо просто развернуть все и по модели строить БД, а не по БД пытаться обновлять код.

    В прочем, можно и так. Изменять БД тоже можно. Контроль типов при этом остается.

    Tom>А насчёт линка мне кажется ты немного наивен. Если взять подмножество linq2sql и TSQL 2008 то первый наверное и 20% не реализует.


    Можно конкренее? Что коме CTE не реализовано в linq?

    Tom>Какой смысл себя ограничивать так?


    TSQL — это гремучая смесь обычного SQL, который практически идентичен linq по функциональности, и совершенно чудовищного императивного языка программирования родом из мезозоя. Зачем над собой издеваться и использовать это палеонтологическое чудо?

    Tom>Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь.


    Какую мощь? А сожные запросы — это не более чем дерево из более простых. И linq, в отличии от TSQL-я, имеет средства декомпозиции сложных запросов в последовательность простых.

    Tom>Явным, в конфиге. Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты.


    Это какие-то шаманские танцы.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[10]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 09:23
    Оценка:
    VD>Только не надо домысливать слова Влада. Я сетовал на то, что Linq не поддерживает DML. Но я никогда не говорил, что Linq идет в лес. Наоборот, я считаю Linq одним из самых перспективных средств доступа к данным.
    Давай говорить конкретно. Какой провайдер ты предлагаешь?

    VD>К тому же уверен, что IT под термином Linq2Sql подразумевал не конкретный провайдер, а сам Linq применительно к доступу к БД. Провайдер же может быть и другой. Скажу тебе по секрету, IT пишет свой провайдер.

    Я давно говорил, вашу бы инициативу да в мирное русло

    Tom>>Ну и опять это перенос в код запростов TSQL, хоть и не в явном виде, что опять же усложняет рефакторинг базы.

    VD>Linq — это не TSQL. Это даже не SQL. Хотя к последнему он ближе.
    VD>Что касается рефакторинга БД, я тебе уже говорил. Надо просто развернуть все и по модели строить БД, а не по БД пытаться обновлять код.
    Влад, ты теоретик просто. В реальном приложении это никто не будет делать. У нас майлстоуны не дольше 4-ёх месяцев.
    Это означает что каждые 4-ре месяца надо выпускать рабочий продукт. Реально правда он ставится на сервера раз в 9 месяцев.

    VD>Можно конкренее? Что коме CTE не реализовано в linq?

    ну так как минимум INSERT/DELETE/UPDATE. без них остаётся уже только 25 процентов.
    ну а если приглядеться — MERGE/HAVING, хинты, управление уровнем изоляции итп...

    VD>TSQL — это гремучая смесь обычного SQL, который практически идентичен linq по функциональности, и совершенно чудовищного императивного языка программирования родом из мезозоя. Зачем над собой издеваться и использовать это палеонтологическое чудо?

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

    Tom>>Тем более что у нас запросы обычно сложные. Нам тут всю мощ TSQL хочется иметь.

    VD>Какую мощь? А сожные запросы — это не более чем дерево из более простых. И linq, в отличии от TSQL-я, имеет средства декомпозиции сложных запросов в последовательность простых.

    Tom>>Явным, в конфиге. Кодогенерация не означает того что она не будет конфигурируемая. Но надобности в таких вещах не будет практически (в теории). Можно задавать опять же неявно, вариантов много на самом деле. Например группировать TSQL который работает с некоторой одной entity в одном каталоге/namespace-е. Чем не вариант. naming использовать. Разные можно придумать варианты.


    VD>Это какие-то шаманские танцы.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[11]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 09:42
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Разные поля, используемые в запросе, а не значение параметра. Редко, но бывает нужно.

    Tom>А, понятно, дело в том что от обезьяны с гранатой спасения нет.
    Tom>Особенно если туда ещё и условие присобачить.
    Tom>Но и задачи спастить от идиота не ставится.
    Tom>Ну и у нас код ревью есть абсолютно всех changeset-ов.
    Tom>Такое можно вылавливать.

    Причем тут идиоты? Тебя спросили как твой генератор будет себя вести в условиях когда разные запросы возвращают один и тот список полей. Будешь формировать разные типы? В linq — это не проблема. Там все типизровано и будет возвращен или конкретный тип, или анонимный тип.

    Tom>Конечно из жизни. Тяжёлой и горькой Если хочешь можно с примерами. С линком есть опыт но небольшой и не менее горький.


    С этого места можно по подробнее.

    Tom>В наших проектах он не применим из за убогости.


    Убогости вашего проекта? Ты извини, но без обоснования эти слова тяжело применить к linq.

    Tom>да и смысла применять мёртвый проект я не вижу.


    Применяй EF.

    Tom>Ну и опять же это перенос TSQL в не явном виде в код. Что полюбому усложняет поддержку рефакторинг.


    То что эти слова являются мягко говоря заблуждением тебе уже сказал не раз. Так что не стоит повторяться.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[12]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 09:45
    Оценка:
    Tom>>Ну и опять же это перенос TSQL в не явном виде в код. Что полюбому усложняет поддержку рефакторинг.

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


    Re[16]: Nemerle &amp; Real Life
    Автор: Tom
    Дата: 10.04.09

    раз заблужденим, то тебе не составит труда ответить по каждому из пунктов?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[12]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 09:51
    Оценка:
    VD>Причем тут идиоты? Тебя спросили как твой генератор будет себя вести в условиях когда разные запросы возвращают один и тот список полей. Будешь формировать разные типы? В linq — это не проблема. Там все типизровано и будет возвращен или конкретный тип, или анонимный тип.
    Будет возвращён конкретный тип или анонимный. В моём варианте и в варианте линка нет разницы. Он так же как и я генерит враперы над хранимками например.

    Tom>>Конечно из жизни. Тяжёлой и горькой Если хочешь можно с примерами. С линком есть опыт но небольшой и не менее горький.

    VD>С этого места можно по подробнее.
    Реальная проблема раз. Поддержка большого количества рукописных resultset классов.
    Проблема два, в коде есть TSQL. Некто его правит и допускает мелкую синтаксическую ошибку.
    Об этом мы узнаём только когда клиент тыкает на кнопочку.
    Проблема три. Намечается большой рефакторинг базы, всех стор, таблиц и запросов.
    Как быть с тем TSQL который живёт в C# не совсем понятно.
    Тем более непонятно что делать с существующими resultset классами.
    Они должны соответствовать новому дизайну базы.

    Tom>>В наших проектах он не применим из за убогости.


    VD>Убогости вашего проекта? Ты извини, но без обоснования эти слова тяжело применить к linq.

    Какой конкретно linq провайдер? И правильно ли я понимаю что ты предлагаешь переписать все имеющиеся запросы у нас с использованием какого то конкретного linq провайдера?

    Tom>>да и смысла применять мёртвый проект я не вижу.

    VD>Применяй EF.
    Это чёрная магия ORM. ты читал их блог по дизайну EF 2.0?
    Если мне надо будет ORM я воспользуюсь LLBGen в котором есть полный провайдер линка кстате.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[11]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 10.04.09 09:59
    Оценка:
    Здравствуйте, Tom, Вы писали:

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


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


    Tom>>>>>Так же ты забываешь про рефакторинг и compile time проверку соответствия кода и базы.

    Tom>>>>>Когда мы пишем руками — мы не имеем ни первого ни второго.
    IT>>>>Как это не имеем? А как же Linq2Sql?
    Tom>>>Он идёт в лес по целому ряду причин. Тут я с Владом согласен что идея недодуманная совсем. И проект скорее мёртв чем жив, MS в него ресурсы вкладывать не будет.
    G>>Linq2SQL уже развиваться не будет, смотрите в сторону EF.
    Tom>В его сторону рано пока смотреть, но я бы сказал ещё в зачаточном состоянии.
    Tom>Да и двигается он в неправильном направлении, в стороно полного ORM решения.
    Tom>Если хочется ORM, да ещё и с нормальной поддержкой линка — то лучше пока использовать сторонние решения.
    Tom>Например LLBGenPro
    Двигается EF в разных направлениях. Видимо разработчики EF хотят покрыть как можно больше сценариев работы с даннми, а не наставить всех на "единственно верный путь".
    Даже сейчас EF — очень удачное решение для систем, в которых не требуется особо навороченных функций от БД.

    G>>У вас рефакторинг БД случается чаще\имеет больший объем, чем рефакторинг кода?

    Tom>Это трудно оценить но по сложности база конечно опережает прикладной код.
    То что по сложности опережает это понятно, но всетаки мне кажется что база рефакторится не так часто как изменяется код приложения.
    Если работать близко к SQL, то затрудняется рефакторинг\изменение функционала приложения.
    Re[11]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 10:25
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>Только не надо домысливать слова Влада. Я сетовал на то, что Linq не поддерживает DML. Но я никогда не говорил, что Linq идет в лес. Наоборот, я считаю Linq одним из самых перспективных средств доступа к данным.

    Tom>Давай говорить конкретно. Какой провайдер ты предлагаешь?

    Я их не создаю, так что мне их рекламировать нет проку.
    Использовать можно любой. EF и Linq2sql вполне рабочие решения.
    Когда IT доделает свой провайдер, то скорее всего он будет более предпочтителен, так как его не сложно будет оснастить поддержкой DML.

    VD>>К тому же уверен, что IT под термином Linq2Sql подразумевал не конкретный провайдер, а сам Linq применительно к доступу к БД. Провайдер же может быть и другой. Скажу тебе по секрету, IT пишет свой провайдер.

    Tom>Я давно говорил, вашу бы инициативу да в мирное русло

    Одни говорят (давно), а другие делают. Улавливаешь разницу?

    VD>>Что касается рефакторинга БД, я тебе уже говорил. Надо просто развернуть все и по модели строить БД, а не по БД пытаться обновлять код.

    Tom>Влад, ты теоретик просто. В реальном приложении это никто не будет делать. У нас майлстоуны не дольше 4-ёх месяцев.

    Я просто не приемлю кривые решения основанные на компромиссах. Если делать, то делать хорошо.

    Tom>Это означает что каждые 4-ре месяца надо выпускать рабочий продукт. Реально правда он ставится на сервера раз в 9 месяцев.


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

    К тому все описанное тобой — это ваши проблемы. Вы сами создали себе условия и рамки.
    Насколько я знаю тот же IT использует в старых проектах BLToolkit + linq и работает над собственным linq-провайдером.
    В следующем проекте он просто возьмет свой новый провайдер и избавится ото всех компромиссов.
    Вы же так и будете убеждать себя, что других путей нет.

    VD>>Можно конкренее? Что коме CTE не реализовано в linq?

    Tom>ну так как минимум INSERT/DELETE/UPDATE. без них остаётся уже только 25 процентов.

    Запросы — это 90% работы. А INSERT/DELETE/UPDATE можно оформить в виде библиотеки.

    Tom>ну а если приглядеться — MERGE/HAVING, хинты, управление уровнем изоляции итп...


    Хинты — это не возможности SQL-я. Это средства оптимизации. Оных можно добиться и без хинтов.
    Более того, IT тебе не зря указывал на то, что запрос переписанный из монолитного SQL-я в ряд linq-азпросов решил проблему производительности в одном из мест нашего сервера. Так что многие хинты просто не будут нужны.

    В итоге ты так и не показал где же мы теряем в мощности при использовании linq-а. Сдается мне, что дело в другом. linq просто нужно уметь готовить. Он требует других подходов, другого менталитета.

    VD>>TSQL — это гремучая смесь обычного SQL, который практически идентичен linq по функциональности, и совершенно чудовищного императивного языка программирования родом из мезозоя. Зачем над собой издеваться и использовать это палеонтологическое чудо?

    Tom>Потому, что это основной язык который развивает поставщик БД. Я может и не в восторге но другой альтернативы нет пока.

    Что, простите, развивает? Да он реально не развивается вот уже 10 лет. Так мелкие примочки добавляют при полностью гнилой базе.

    При этом тот же "поставщик" предлагает конкретное решение — linq + современные дотнет-языки. И это решение действительно развивается.

    Tom>И единственный на сегодняшний день язык который обладает полной мощью для соответствующей БД.


    Он обладает полной немощью как язык программирования. Этого одного уже достаточно чтобы его никогда не применят. А sql прекрасно коррелирует с linq. Единственная проблема DML, но она как раз решаема.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[19]: Nemerle & Real Life
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 10:30
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>В выборке данных есть поддержка всего процентов наверное 10-20 от всей мощи TSQL. Вопрос, нахрена козе баян? И что делать с действительно сложными запросами, которых у нас в огромном количестве.


    Ты бы объяснил, для начала, что ты понимаешь под мощью и под сложными запросами? Лучше всего на базе примеров.

    Tom>Да и смысла подменять один язык TSQL другим linq я не вижу. Тем более, что ты упорно игнорируешь тот факт что он мёртв.


    Можно поставить вопрос по другому. В чем смысл вместо одного языка (например, C#) использовать два (например, C# + TSQL) и тратить кучу времени на обеспечение их взаимодействия.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Nemerle & Real Life
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 10:44
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    Tom>>В выборке данных есть поддержка всего процентов наверное 10-20 от всей мощи TSQL. Вопрос, нахрена козе баян? И что делать с действительно сложными запросами, которых у нас в огромном количестве.


    VD>Ты бы объяснил, для начала, что ты понимаешь под мощью и под сложными запросами? Лучше всего на базе примеров.


    ну вот поростой и типичный вариант
    CREATE PROCEDURE [dbo].[BvSpCall_Activate]
    @SurveySID  INT,
    @ClassID    INT,
    @Mode       INT,
    @BatchID    INT,
    @Priority   INT,
    @RoleID     INT,
    @PersonSID  INT,
    @ShiftTypeID INT,
    @TimeToCall DATETIME
    AS
    SET XACT_ABORT ON
    SET NOCOUNT ON
     
    --  IF @ShiftTypeID = 0
    --      SET @ShiftTypeID = NULL
     
      CREATE TABLE #batch
      (
          [ID] [int] NOT NULL PRIMARY KEY
      )
     
      CREATE TABLE #tz (
          [ID] [int] NOT NULL,
          TimeZoneID [int] NOT NULL,
          Bias [int] NOT NULL,
          ShiftTypeID [int] NULL,
          ITS [int] NOT NULL
      )
    
      DECLARE @result INT,
              @ErrorMessage    NVARCHAR(4000),
              @ErrorNumber     INT,
              @ErrorSeverity   INT,
              @ErrorState      INT,
              @ErrorLine       INT,
              @ErrorProcedure  NVARCHAR(200);
      SET @result = 0;
    
      BEGIN TRY
     
         IF (@Mode = 1) -- means activate prepared scheduled calls
           INSERT INTO #tz
               SELECT BvSvySchedule.[ID], ISNULL(BvInterview.TimezoneID, 0), 0, NULL, 0
               FROM BvSvySchedule, BvInterview, BvPreparedCalls
               WHERE BvPreparedCalls.ItemID = BvSvySchedule.[ID]
                   AND BvSvySchedule.SurveySID = BvInterview.SurveySID
                   AND BvSvySchedule.InterviewID = BvInterview.[ID]
                   AND BvPreparedCalls.BatchID = @BatchID
         ELSE IF (@Mode = 2) -- activate prepared suspended calls
         BEGIN
           INSERT INTO #batch( [ID] )
              SELECT DISTINCT ItemID FROM BvPreparedCalls WITH( NOLOCK ) WHERE BatchID = @BatchID
        
           INSERT INTO #tz
              SELECT BvInterview.[ID], ISNULL(BvInterview.TimezoneID, 0), 0, NULL, BvInterview.TransientState
              FROM BvInterview
              INNER JOIN #batch ON #batch.[ID] = BvInterview.[ID]
              WHERE BvInterview.SurveySID = @SurveySID 
                     AND NOT EXISTS ( SELECT [ID] FROM BvSvySchedule
                            WHERE SurveySID = @SurveySID 
                              AND InterviewID = BvInterview.[ID] )
         END
         ELSE -- (@Mode = 3) -- activate all suspended calls
           INSERT INTO #tz
             SELECT BvInterview.[ID], ISNULL(BvInterview.TimezoneID, 0), 0, NULL, BvInterview.TransientState
             FROM BvInterview
             WHERE BvInterview.SurveySID = @SurveySID 
                 AND BvInterview.TransientState != 13 
                 AND NOT EXISTS ( SELECT [ID] FROM BvSvySchedule
                        WHERE BvSvySchedule.SurveySID = @SurveySID 
                              AND BvSvySchedule.InterviewID = BvInterview.[ID] )
        
    
           IF (@Mode = 2)
               -- check if activation for interview transient state is disabled
        
               IF EXISTS(SELECT 1
                       FROM BvState INNER JOIN #tz ON BvState.StateID = #tz.ITS
                       WHERE
                               BvState.StateGroupID = (SELECT BvSurvey.StateGroupID FROM BvSurvey WHERE BvSurvey.SID = @SurveySID) AND
                               DA = 1)
               BEGIN
                   DELETE BvPreparedCalls WHERE BatchID = @BatchID
                   SET @result = -1
                   RAISERROR( 'Restricted records selected, cannot activate calls. No activation performed for this action', 16, 1 )
                   --RETURN (-1)
               END
        
          CREATE TABLE #tzb (
              TimeZoneID [int] NOT NULL
          )
        
          INSERT INTO #tzb SELECT DISTINCT TimeZoneID FROM #tz
        
          -- Check shift
             IF ( @ShiftTypeID != 0 AND --any valid we should chek too
                  @TimeToCall IS NOT NULL )
             BEGIN
                 DECLARE @TimeToCall2 DATETIME
           
                 SET @TimeToCall2 = DATEADD( minute, 1, @TimeToCall )
    
                DECLARE @OwnerID INT
                SELECT @OwnerID = BvSchedule.Schd_ID 
                FROM BvSurvey, BvSchedule, BvScrAsgn 
                WHERE BvSurvey.SID = @SurveySID AND
                   BvSurvey.SID = BvScrAsgn.ScAsgn_ObjID AND
                   BvScrAsgn.Scr_ID = BvSchedule.Scr_ID
        
                 CREATE TABLE #activeshift(
                   ShiftID INT NOT NULL, 
                   OwnerID INT NOT NULL,
                   [ShiftTypeID] INT NOT NULL
                 )
                 INSERT INTO #activeshift EXEC BvSpGetActiveShiftsInRelativeTime @TimeToCall, @TimeToCall2
        
                 IF NOT EXISTS ( SELECT 1 
                                 FROM #activeshift
                                 WHERE OwnerID = @OwnerID AND
                                       ( ShiftTypeID = @ShiftTypeID OR @ShiftTypeID = -1))
                 BEGIN
                     DROP TABLE #tz
                     DROP TABLE #tzb
                     DROP TABLE #activeshift
                     IF (@Mode != 3)
                        DELETE BvPreparedCalls WHERE BatchID = @BatchID
                     SET @result = -1
                     RAISERROR( 'Time specified is out of shifts of selected type.', 16, 1 )
                     --RETURN (-1)
                 END
        
                 DROP TABLE #activeshift
             END
        
           -- Init timezones bias
           DECLARE crTZ CURSOR LOCAL FAST_FORWARD LOCAL
           FOR SELECT TimeZoneID FROM #tzb WHERE TimeZoneID <> 0
           DECLARE @tzID INT
           DECLARE @Bias INT
           DECLARE @SiteBias INT
           DECLARE @DefaultTZID INT
           DECLARE @dt_bias DATETIME
    
           SET @dt_bias = ISNULL( @TimeToCall, GETUTCDATE() )
        
           IF EXISTS( SELECT TimeZoneID FROM #tzb WHERE TimeZoneID <> 0 )
           BEGIN
             -- get default timezone 
             SELECT TOP 1 @DefaultTZID = TimezoneID FROM BvSite
        
             EXEC BvSpGetTZBias @dt_bias, @DefaultTZID, @SiteBias OUTPUT
        
             OPEN crTZ
             FETCH NEXT FROM crTZ INTO @tzID
             WHILE (@@FETCH_STATUS = 0)
             BEGIN
                SET @Bias = NULL
                EXEC BvSpGetTZBias @dt_bias, @tzID, @Bias OUTPUT
    
                IF @Bias IS NULL BEGIN
                    SET @result = -2
                    RAISERROR( 'TimeZone not found, id - %i', 16, 1, @tzID )
                    --RETURN (-2)
                END
    
                UPDATE #tz SET Bias = @Bias WHERE TimeZoneID = @tzID
                FETCH NEXT FROM crTZ INTO @tzID
             END
        
             -- close cursor
             CLOSE crTZ
             DEALLOCATE crTZ
        
           END
        
           -- Init Shift Type ID
           IF @ShiftTypeID > 0 
               UPDATE #tz SET #tz.ShiftTypeID = BvShiftZones.[ID]
               FROM BvShiftZones WHERE BvShiftZones.ShiftTypeID = @ShiftTypeID
                 AND BvShiftZones.TimeZoneID = #tz.TimeZoneID
       --    ELSE BEGIN
               -- get site bias
           EXEC BvSpGetDefaultTZBias @TimeToCall, @Bias OUTPUT
           UPDATE #tz SET Bias = @Bias WHERE TimeZoneID = 0
       --    END
           DECLARE @TimeZoneSet INT
           SELECT TOP 1 @TimeZoneSet = -BvSite.TimeZoneID FROM BvSite        
       --------------------------------------------------------------
       -- prepare calls
       --------------------------------------------------------------
         IF (@Mode = 1) BEGIN -- means activate prepared scheduled calls
           IF @PersonSID <> 0
               UPDATE  BvSvySchedule
                 SET TimeInShift = DATEADD( minute, #tz.Bias, @TimeToCall ),
                     Priority = @Priority,
                     ShiftTypeID =              CASE WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NOT NULL
                         THEN - BvInterview.TimeZoneID
                         WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NULL
                         THEN @TimeZoneSet
                         ELSE #tz.ShiftTypeID -- ShiftTypeID
                         END,
                     ExplicitSID = @PersonSID,
                     ExplicitType = 2,
                     RoleID = CASE WHEN @RoleID <> 0 AND @RoleID IS NOT NULL 
                                   THEN @RoleID ELSE BvSvySchedule.RoleID END
               FROM BvSvySchedule 
                 INNER JOIN BvPreparedCalls 
                 ON BvPreparedCalls.ItemID = BvSvySchedule.[ID]
                 INNER JOIN #tz ON BvSvySchedule.[ID] = #tz.[ID]
                 INNER JOIN BvInterview ON BvInterview.SurveySID = BvSvySchedule.SurveySID
                     AND BvInterview.[ID] = BvSvySchedule.InterviewID
               WHERE BvPreparedCalls.BatchID = @BatchID
           ELSE
               UPDATE  BvSvySchedule
                 SET TimeInShift = DATEADD( minute, #tz.Bias, @TimeToCall ),
                     Priority = @Priority,
                     ShiftTypeID = CASE WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NOT NULL
                         THEN - BvInterview.TimeZoneID
                         WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NULL
                         THEN @TimeZoneSet
                         ELSE #tz.ShiftTypeID -- ShiftTypeID
                         END
               FROM BvSvySchedule 
                 INNER JOIN BvPreparedCalls 
                 ON BvPreparedCalls.ItemID = BvSvySchedule.[ID]
                 INNER JOIN #tz ON BvSvySchedule.[ID] = #tz.[ID]
                 INNER JOIN BvInterview ON BvInterview.SurveySID = BvSvySchedule.SurveySID
                     AND BvInterview.[ID] = BvSvySchedule.InterviewID
               WHERE BvPreparedCalls.BatchID = @BatchID
        
               INSERT INTO BvCachedCallsInsert
                   SELECT c.InterviewID, @SurveySID
                   FROM BvSvySchedule c
                   INNER JOIN BvPreparedCalls p ON p.ItemID = c.[ID]            
                       AND p.BatchID = @BatchID
                   LEFT JOIN BvCachedCallsInsert ci ON ci.InterviewID = c.InterviewID
               AND ci.SurveySID = @SurveySID
                   WHERE ci.SurveySID IS NULL
         END
         ELSE IF (@Mode = 2) BEGIN  -- activate prepared suspended calls
           INSERT INTO BvSvySchedule
             SELECT 0,            -- AppID
                    CASE WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NOT NULL
                         THEN - BvInterview.TimeZoneID
                         WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NULL
                         THEN @TimeZoneSet
                         ELSE #tz.ShiftTypeID -- ShiftTypeID
                    END,
                    @RoleID,
                    BvInterview.[ID],
                    BvInterview.[SurveySID],
                    2 as PhaseCurrent /*hardcore dbcleanup*/,
                    @Priority,
                    DATEADD( minute, #tz.Bias, @TimeToCall), -- TimeInShift
                    '9999-01-01 00:00:00.000',        -- ExpireTime
                    @PersonSID,
                    2,           -- ExplicitType
                    '00000000-0000-0000-0000-000000000000'
              FROM BvInterview
              INNER JOIN #batch ON #batch.[ID] = BvInterview.[ID]
              INNER JOIN #tz ON #tz.[ID] = BvInterview.[ID]
              WHERE BvInterview.SurveySID = @SurveySID 
                     AND NOT EXISTS ( SELECT [ID] FROM BvSvySchedule
                            WHERE SurveySID = @SurveySID 
                              AND InterviewID = BvInterview.[ID] )
                              
              UPDATE BvAggregateSurvey WITH(ROWLOCK)
              SET ScheduledCallsCountPrev = ScheduledCallsCount,
                  ScheduledCallsCount = ScheduledCallsCount+@@ROWCOUNT
              WHERE SID = @SurveySID
        
              INSERT INTO BvCachedCallsInsert
                   SELECT #batch.[ID], @SurveySID
                   FROM #batch
                   LEFT JOIN BvCachedCallsInsert ci ON ci.InterviewID = #batch.[ID]
                       AND ci.SurveySID = @SurveySID
                   WHERE ci.SurveySID IS NULL
        
           END
          ELSE BEGIN -- (@Mode = 3) -- activate all suspended calls
          INSERT INTO BvSvySchedule
              SELECT
                  0,            -- ApptID
                  CASE WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NOT NULL
                       THEN - BvInterview.TimeZoneID
                       WHEN @ShiftTypeID < 0 AND BvInterview.TimeZoneID IS NULL
                       THEN @TimeZoneSet
                       ELSE #tz.ShiftTypeID -- ShiftTypeID
                  END,
                  @RoleID,
                  BvInterview.[ID],
                  @SurveySID,
                  2 as PhaseCurrent, /*hardcore dbcleanup*/
                  @Priority,
                  DATEADD( minute, #tz.Bias, @TimeToCall),-- TimeInShift
                  '9999-01-01 00:00:00.000',       -- ExpireTime
                  @PersonSID,
                  2,          -- ExplicitType
                  '00000000-0000-0000-0000-000000000000'
              FROM BvInterview
              INNER JOIN #tz ON #tz.[ID] = BvInterview.[ID]
              INNER JOIN BvSurvey ON BvSurvey.SID = @SurveySID
              INNER JOIN BvState ON BvSurvey.StateGroupID = BvState.StateGroupID
                  AND BvInterview.TransientState = BvState.StateID
                  AND BvState.DA = 0
              WHERE BvInterview.SurveySID = @SurveySID 
          --          AND BvInterview.TransientState != 13 
                    AND NOT EXISTS ( SELECT [ID] FROM BvSvySchedule
                           WHERE BvSvySchedule.SurveySID = @SurveySID 
                                 AND BvSvySchedule.InterviewID = BvInterview.[ID] )
                                 
              UPDATE BvAggregateSurvey WITH(ROWLOCK)
              SET ScheduledCallsCountPrev = ScheduledCallsCount,
                  ScheduledCallsCount = ScheduledCallsCount+@@ROWCOUNT
              WHERE SID = @SurveySID
           
              INSERT INTO BvCachedCallsInsert
                      SELECT #tz.[ID], @SurveySID
                      FROM #tz
                      LEFT JOIN BvCachedCallsInsert ci ON ci.InterviewID = #tz.[ID]
                          AND ci.SurveySID = @SurveySID
                      WHERE ci.SurveySID IS NULL
          END
           
         IF (@Mode != 3)
           DELETE BvPreparedCalls WHERE BatchID = @BatchID
        
         IF ( ( @Mode = 2 OR @Mode = 3 ) AND @PersonSID = 0 )
             UPDATE BvSvySchedule SET ExplicitType = 1,
                                      ExplicitSID  = BvAssignmentGroup.SID
                 FROM BvAssignmentGroup
                 WHERE BvSvySchedule.SurveySID = @SurveySID AND
                       BvAssignmentGroup.SurveySID = BvSvySchedule.SurveySID AND
                       BvAssignmentGroup.Phase = BvSvySchedule.Phase AND
                       BvAssignmentGroup.RoleID = BvSvySchedule.RoleID AND
                       BvSvySchedule.ExplicitSID = 0
        
          DROP TABLE #tz
          DROP TABLE #tzb
          DROP TABLE #batch
        
          if @PersonSID = 0 begin
              truncate table BvUniqueAssignments
              insert into BvUniqueAssignments
              select distinct ExplicitSID from BvSvySchedule
              LEFT JOIN BvUniqueAssignments bua ON (ExplicitSID = bua.sid)
              WHERE bua.SID IS NULL
          end
          else
              exec BvSpAddUniqueAssignment @PersonSID
           
          --   exec BvSpCache_NotifyUpdated
       END TRY
       BEGIN CATCH
     
          SELECT @ErrorNumber = ERROR_NUMBER(),
                 @ErrorSeverity = ERROR_SEVERITY(),
                 @ErrorState = ERROR_STATE(),
                 @ErrorLine = ERROR_LINE(),
                 @ErrorProcedure = ISNULL(ERROR_PROCEDURE(), '-');
    
          SELECT @ErrorMessage = 
                  N'Error %d, Level %d, State %d, Procedure %s, Line %d, ' + 
                    'Message: '+ ERROR_MESSAGE();
          RAISERROR( @ErrorMessage, 
                     @ErrorSeverity, 
                     1,               
                     @ErrorNumber,
                     @ErrorSeverity,
                     @ErrorState,
                     @ErrorProcedure,
                     @ErrorLine
                   );
          RETURN @result;
       END CATCH
     
    RETURN @result


    Tom>>Да и смысла подменять один язык TSQL другим linq я не вижу. Тем более, что ты упорно игнорируешь тот факт что он мёртв.

    VD>Можно поставить вопрос по другому. В чем смысл вместо одного языка (например, C#) использовать два (например, C# + TSQL) и тратить кучу времени на обеспечение их взаимодействия.
    Обьясню. Каждый язык имеет область применения.
    C# никак не предназначен на сегодняшний день для манипуляции данными. Тем боллее, что серверов БД существует великое множество. И у каждого свой SQL диалект.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[13]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 10:44
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Re[16]: Nemerle &amp; Real Life
    Автор: Tom
    Дата: 10.04.09

    Tom>раз заблужденим, то тебе не составит труда ответить по каждому из пунктов?

    Там нет ни одного пункта интересующего мнея. BLToolkit меня интересует так же слабо как твои идеи размещения запросов в отдельных файлах.

    Лучшим подходом, на мой взгляд, является размещение запросов в виде встроенного (типизированного) DSL внутри кода приложения. Короче говоря подход а-ля linq.

    Собственно проблемы linq-а известны:
    1. Отсутствие поддержки DML.
    2. Некоторая расточительность вызванная тем, что вся генерация SQL производится в рнтайме (не делается никаких предвычислений), а весь код встроенный в linq-запросы каждый раз компилируется во время выполнения.
    3. Ограничения конкретных провайдеров. Так EF не предоставляет некоторую функциональность (хранимые функции, работа с датой и временем и т.п.), а linq2sql не умеет работать с СУБД отличными от MS SQL.

    Согласен, что серьезные проблемы, но, на мой взгляд, разумнее устранить их нежели заниматься скрещиванием TSQL, C# и текстовых файлов.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[13]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 10:59
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>Причем тут идиоты? Тебя спросили как твой генератор будет себя вести в условиях когда разные запросы возвращают один и тот список полей. Будешь формировать разные типы? В linq — это не проблема. Там все типизровано и будет возвращен или конкретный тип, или анонимный тип.

    Tom>Будет возвращён конкретный тип или анонимный. В моём варианте и в варианте линка нет разницы. Он так же как и я генерит враперы над хранимками например.

    Вопрос был: сгенерирует ли твой генератор один тип для этих двух запросов, или два разных?

    Tom>Реальная проблема раз. Поддержка большого количества рукописных resultset классов.


    Это чё за зверь? Ты о linq говоришь? В нем большого количества не получается. Получается или класс описывающий таблицу БД, или анонимный тип (а-ка запись).

    Tom>Проблема два, в коде есть TSQL.


    Ну, дык, вот это конечно не хорошо. С этим и надо бороться.

    Tom>Некто его правит и допускает мелкую синтаксическую ошибку.


    Не фига было править. Надо выбрасывать и заменять linq-запросами.

    Tom>Об этом мы узнаём только когда клиент тыкает на кнопочку.


    Это следствие...

    Tom>Проблема три. Намечается большой рефакторинг базы, всех стор, таблиц и запросов.

    Tom>Как быть с тем TSQL который живёт в C# не совсем понятно.

    Не допускать такого идиотизма. Типизированный linq-код сам подскажет что и где нужно поменять (при компиляции).

    Tom>Тем более непонятно что делать с существующими resultset классами.


    Это тоже какой-то пережиток.

    Tom>Они должны соответствовать новому дизайну базы.


    Дык устрани их и проблем не будет. Есть только две рабочие схемы:
    1. Набор классов описывающих сущности БД. Их нужно тупо генерировать по БД.
    2. Описание модели данных по которой генерируется (или обновляется) БД и необходимый код.

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

    VD>>Убогости вашего проекта? Ты извини, но без обоснования эти слова тяжело применить к linq.

    Tom>Какой конкретно linq провайдер?

    Какой вам больше по душе. Если вы ориентируетесь исключительно на MS SQL Server, то наверно linq2sql — лучший выбор.

    Tom>И правильно ли я понимаю что ты предлагаешь переписать все имеющиеся запросы у нас с использованием какого то конкретного linq провайдера?


    Из изначально не надо писать на чем попало. Но уж если вы хотите перевести на новые технологии старый проект, то следует сначала провести рефакторинг и заменить весь TSQL на linq.

    Tom>>>да и смысла применять мёртвый проект я не вижу.

    VD>>Применяй EF.
    Tom>Это чёрная магия ORM. ты читал их блог по дизайну EF 2.0?

    Ты просто плохо в нем разобрался. Там есть лишнее, но его можно не использовать. Проблемы EF в другом. Он плохо поддерживает функционал конкретной СУБД. Работа с датами, например, там не к черту не годится. Отсюда многие агрегатные запросы могут просто не получиться реализовать.

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

    Tom>Если мне надо будет ORM я воспользуюсь LLBGen в котором есть полный провайдер линка кстате.


    С LLBGen не знаком. Но если у него есть приемущества, то почему бы и нет?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[13]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 11:01
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Какой конкретно linq провайдер? И правильно ли я понимаю что ты предлагаешь переписать все имеющиеся запросы у нас с использованием какого то конкретного linq провайдера?


    Tom>>>да и смысла применять мёртвый проект я не вижу.

    VD>>Применяй EF.
    Tom>Это чёрная магия ORM. ты читал их блог по дизайну EF 2.0?
    Tom>Если мне надо будет ORM я воспользуюсь LLBGen в котором есть полный провайдер линка кстате.

    Я правильно понимаю, что твои претензии относятся к конкретным провайдерам, а не самому подходу linq в целом?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[14]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 11:24
    Оценка:
    VD>Какой вам больше по душе. Если вы ориентируетесь исключительно на MS SQL Server, то наверно linq2sql — лучший выбор.
    Опять двадцать пять. Этот проект мёртв. Ещё предложения? И что всё таки делать с linq & DML?

    Tom>>И правильно ли я понимаю что ты предлагаешь переписать все имеющиеся запросы у нас с использованием какого то конкретного linq провайдера?

    VD>Из изначально не надо писать на чем попало. Но уж если вы хотите перевести на новые технологии старый проект, то следует сначала провести рефакторинг и заменить весь TSQL на linq.
    Понятно, спасибо. Это на мой взгляд невозможно, и глупо. невозможно потому что linq как ты сам писал не поддерживает DML а глупо потому что от того что масло станет маслянным качество проекта не улучшится.

    Tom>>>>да и смысла применять мёртвый проект я не вижу.

    VD>>>Применяй EF.
    Tom>>Это чёрная магия ORM. ты читал их блог по дизайну EF 2.0?

    VD>Ты просто плохо в нем разобрался. Там есть лишнее, но его можно не использовать. Проблемы EF в другом. Он плохо поддерживает функционал конкретной СУБД. Работа с датами, например, там не к черту не годится. Отсюда многие агрегатные запросы могут просто не получиться реализовать.

    Кы читал куда они двигаются/развиваются?

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

    Вот что исходники откроют я верю. Как раз из за проблем поддержки. Что бы спихнуть её на комьюнити. Но без открытия исходников компилятора нормально линк развивать не получится. Тот же DML полностью не реализовать, да и я не представляю сколько для этого понадобится ресурсов.

    Tom>>Если мне надо будет ORM я воспользуюсь LLBGen в котором есть полный провайдер линка кстате.


    VD>С LLBGen не знаком. Но если у него есть приемущества, то почему бы и нет?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[21]: Nemerle & Real Life
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 11:38
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>Ты бы объяснил, для начала, что ты понимаешь под мощью и под сложными запросами? Лучше всего на базе примеров.


    Tom>ну вот поростой и типичный вариант...


    ОК, это уже что-то. Теперь пара вопросов...

    Кстати, название процедуры совершенно ничего не говорящее. "BvSpCall" мало говорит о сути.

    Что же мы видим?
    А видим мы совершенно ужасный, монструозный в котором полностью отсутствует декомпозиция.
    При этом в linq из всего увиденного не удастся повторить только вставку/удаление в реальные таблицы:
    INSERT INTO BvCachedCallsInsert
         SELECT #batch.[ID], @SurveySID
         FROM #batch
         LEFT JOIN BvCachedCallsInsert ci ON ci.InterviewID = #batch.[ID]
             AND ci.SurveySID = @SurveySID
         WHERE ci.SurveySID IS NULL
    ...
    DELETE BvPreparedCalls WHERE BatchID = @BatchID


    Такой код нужно называть не "сложным запросом", а "плохим кодом".
    Даже используя возможности MS SQL можно было бы сделать этот код намного более понятным и легким в поддержке. Все что для этого нужно было сделать — это произвести его декомпозици на хранимые функции и разбить процедуру на ряд под-продцедур (что не просто в следствии кривости TSQL).
    С использованием linq произвести декомпозицию было намного проще, так как нет ограничений TSQL-я.
    Наличие курсоров вообще порадовало. Отличная демонстрация того как кривой язык подталкивает не очень ответственных (или не опытных) к использованию откровенно кривых решений.

    Что касается DML, тут прийдется делать собственное решение или дожидаться когда IT или кто-то другой реализует DML для linq. Пока что можно пользоваться датаконтекстом и модификацией объектов.

    А, что у вас все хранимки модифицируют данные в таблицах? Если нет, то какой процент этим занимается?

    VD>>Можно поставить вопрос по другому. В чем смысл вместо одного языка (например, C#) использовать два (например, C# + TSQL) и тратить кучу времени на обеспечение их взаимодействия.

    Tom>Обьясню. Каждый язык имеет область применения.
    Tom>C# никак не предназначен на сегодняшний день для манипуляции данными. Тем боллее, что серверов БД существует великое множество.

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

    Tom>И у каждого свой SQL диалект.


    Это было бы аргументом если бы мы обсуждали бы гетерогенное решение, а не код на скрипте конкретной СУБД.
    Как раз EF обеспечивает гетерогенность, правда, в ущерб функционалу. А код на конкретном диалекте СУБД-скрипта ее точно не обеспечивает.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 11:49
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Такой DSL уже есть. Называется TSQL.


    TSQL — это не DSL. У тебя совершенно не верная терминология.
    TSQL — это GPPL, т.е. язык программирования общего назначения. На нем можно написать все что можно написать на C# (например). Эти языки одинаково мощны по Тьюрингу.

    Вот SQL — это действительно ДСЛ. Только внешний. Linq — это как раз встраивание DSL аналогичного SQL в приличный ООЯ вроде C#.

    Проблема TSQL в том, что — это кривой скрипт со встроенной поддержкой действительно мощного диалекта SQL.

    Tom>Можешь пояснить как может выглядеть собственный DSL для работы с данными? Что принципиально будет в нём отличного от того же TSQL?


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

    VD>>Согласен, что серьезные проблемы, но, на мой взгляд, разумнее устранить их нежели заниматься скрещиванием TSQL, C# и текстовых файлов.

    Tom>Я попробую всё же, ибо пока другого решения я просто не вижу.

    Кто мы такие чтобы мешать тебе? Пробуй...
    Но это же ты пришел к нам и задаешь вопросы, правда? Вот мы тебе и отвечаем, что нам компромиссы подобные описанным тобой не нравятся.

    Tom>linq по многим причинам не подходит как полноценное и всеобьемлющее решения для работы с данными. Пока он не дорос.


    Это ты уже говорил. И тебе уже отвечали на это. Причем прямо в редыдущем сообщении, напеример. Не сотоит повторяться.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 11:57
    Оценка:
    Tom>>Можешь пояснить как может выглядеть собственный DSL для работы с данными? Что принципиально будет в нём отличного от того же TSQL?
    VD>Принципиально ничего. Но он будет встроен в полноценный язык (и удобный) программирования. Ты получаешь возможность писать весь код приложения на одном языке.
    Получается что, вместо использование/написания провайдера linq нормальный подход — свой DSL для работы с данными. Так?
    Есть ли уже готовые примеры?

    VD>Кто мы такие чтобы мешать тебе? Пробуй...

    VD>Но это же ты пришел к нам и задаешь вопросы, правда? Вот мы тебе и отвечаем, что нам компромиссы подобные описанным тобой не нравятся.
    да, да да и большое спасибо за ответы!
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[13]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 12:02
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>И всё же, какой провайдер ты предлагаешь использовать СЕЙЧАС. Не завтра и не после завтра, а сейчас?


    Я же тебе ответил. Зависит от задач. Лично тебе подошел бы linq2sql, так как ты работаешь с одной СУБД.
    IT обещал закончить провайдер в течении 1-2 месяцев. Если это произойдет, то его провайдер будет предпочтительнее.

    VD>>Одни говорят (давно), а другие делают. Улавливаешь разницу?

    Tom>А я по твоему ничего не делаю? Просто ты волен заниматсья тем что тебе интересно, а мне приходится работать в реальных проектах с большой и многолетней историей (более 15 лет) и огромный количеством кода. Если формально посчитать — то более 100 мегабайт.

    Я как бы и не скрывал, что в этом отношении у меня есть некоторое приемущество. Но тот же IT в том же положении, что и ты. Но он выбирает другой путь.

    Tom>Он уже огромный, и я его уменьшаю в разы. По моим оченкам обьём кода я смогу уменьшить на порядок


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

    Tom>Какие примочки и причём тут гнилапя база? Для MS SQL Server — а единственный язык общения — это TSQL.


    Я уже говорил об этом. TSQL — это кривой и очень примитивный скрипт в который встроена поддержка SQL. Равития у него нет. Его латают по скорому, чтобы хоть как-то использовать можно было.
    Я на этом говне писал еще в 1995 году и могу сравнивать с тем, что есть сейчас. Отличия можно пересчитать по пальцам одной руки.

    И вообще, если TSQL так крут, то зачем тебе вообще C# сдался? Пиши все на TSQL.

    VD>>При этом тот же "поставщик" предлагает конкретное решение — linq + современные дотнет-языки. И это решение действительно развивается.

    Tom>От MS реального решения для работы с данными пока нет. И тем более нет решения позволяющего правно смигрировать с существующего кода.

    Это ты себя убеждаешь в этом. А реально оно есть. Не совершенное пока, но есть.

    Tom>Влад, ты какой нибудь другой язык который понимает SQL сервер?


    Этот язык называется SQL. Его возможностей достаточно для работы с данными из БД. А разные TSQL-и и PL-SQL — это попытка прикрутить скрипты в СУБД. Причем TSQL просто провальная попытка, а PL-SQL кривенькая, но рабочая.
    Linq же решает очень похожую задачу, только вместо того чтобы выдумывать кривой скрипт, Linq предоставляет средства для встраивания запросов в любой язык. Ну, с DML пока недоработка. Но сам подход намньго более верный.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 12:07
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Получается что, вместо использование/написания провайдера linq нормальный подход — свой DSL для работы с данными. Так?


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

    Tom>Есть ли уже готовые примеры?


    Я не занимался этим вопросом. Знаю только, что IT близок к созданию своего провайдера который точно будет поддерживать DML.

    VD>>Кто мы такие чтобы мешать тебе? Пробуй...

    VD>>Но это же ты пришел к нам и задаешь вопросы, правда? Вот мы тебе и отвечаем, что нам компромиссы подобные описанным тобой не нравятся.
    Tom>да, да да и большое спасибо за ответы!

    На здоровье. Я это к тому сказал, чтобы ты не воспринимал наши слова как навязывание тебе нашего мнения.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 12:15
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>Какой вам больше по душе. Если вы ориентируетесь исключительно на MS SQL Server, то наверно linq2sql — лучший выбор.

    Tom>Опять двадцать пять. Этот проект мёртв. Ещё предложения?

    Что за чушь? Его не сделают кроссерверным и не будут развивать такими же темпами как EF. Но поддерживать будут, так как он уже часть фрэймворка.

    Tom> И что всё таки делать с linq & DML?


    Реализовать самому или дождаться пока появится провайдер со встроенным DML.
    Вариант 3 — использовать обновление объектов и датаконтекст (он мне самому не нравится).

    Tom>Понятно, спасибо. Это на мой взгляд невозможно, и глупо. невозможно потому что linq как ты сам писал не поддерживает DML а глупо потому что от того что масло станет маслянным качество проекта не улучшится.


    Сколько у вас там сложных запросов использующих DML (за исключением манипуляции с временными таблицами)?
    Ну, и оставьте их в виде хранимок. Это один черт лучше чем все держать в вдие TSQL-я.

    VD>>Ты просто плохо в нем разобрался. Там есть лишнее, но его можно не использовать. Проблемы EF в другом. Он плохо поддерживает функционал конкретной СУБД. Работа с датами, например, там не к черту не годится. Отсюда многие агрегатные запросы могут просто не получиться реализовать.

    Tom>Кы читал куда они двигаются/развиваются?

    Да. Но схему linq2sql они накрывают полностью, так что можешь просто не использовать то что тебе не нужно.

    Tom>Вот что исходники откроют я верю. Как раз из за проблем поддержки. Что бы спихнуть её на комьюнити. Но без открытия исходников компилятора нормально линк развивать не получится. Тот же DML полностью не реализовать, да и я не представляю сколько для этого понадобится ресурсов.


    DML реализовать можно, хотя и сложно. А что там еще развивать то?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[14]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 12:22
    Оценка:
    VD>Рад за твои оценки. Расскажи потом, чем дело кончилось. Кстати, процедуры аналогичные приведенной тобой я бы подверг рефакторингу. Это монстр, а не код. Его точно поддерживать будет сложно.
    Да я бы тоже их подверг, что и придётся делать скоро. Но рефакторинг будет связан с новой большой ыичей из за которого пол базы придётся перелопатить.
    заметки на полях я колнечно буду делать и потом расскажу что вышло. Вполне возможно что подход пойдёт в мусорку и надо будет думать что то другое.

    Tom>>Какие примочки и причём тут гнилапя база? Для MS SQL Server — а единственный язык общения — это TSQL.


    VD>Я уже говорил об этом. TSQL — это кривой и очень примитивный скрипт в который встроена поддержка SQL. Равития у него нет. Его латают по скорому, чтобы хоть как-то использовать можно было.

    VD>Я на этом говне писал еще в 1995 году и могу сравнивать с тем, что есть сейчас. Отличия можно пересчитать по пальцам одной руки.

    VD>И вообще, если TSQL так крут, то зачем тебе вообще C# сдался? Пиши все на TSQL.

    Ну логику обоработки данных иы и пишем на TSQL.

    VD>>>При этом тот же "поставщик" предлагает конкретное решение — linq + современные дотнет-языки. И это решение действительно развивается.

    Tom>>От MS реального решения для работы с данными пока нет. И тем более нет решения позволяющего правно смигрировать с существующего кода.

    VD>Это ты себя убеждаешь в этом. А реально оно есть. Не совершенное пока, но есть.


    Tom>>Влад, ты какой нибудь другой язык который понимает SQL сервер?


    VD>Этот язык называется SQL. Его возможностей достаточно для работы с данными из БД. А разные TSQL-и и PL-SQL — это попытка прикрутить скрипты в СУБД. Причем TSQL просто провальная попытка, а PL-SQL кривенькая, но рабочая.

    Интерено про PL-SQL и TSQL детали. Я с PL-SQL сталкивался так давно что не помню практически ничего.

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

    Так я и не смпорбю что ВЕКТОР правильный, а реализация пока кривенькая. Вот будет DML тогда и будем переписывать.

    Хотя для некоторых сложных запросов мы попытаемся сделать декомпозицию с помощью линка. Посмотрим насколько это реально.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[16]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 12:41
    Оценка:
    VD>Опять возвращаемся к исходным посылкам. Ты исходишь из посылок, что за тебя все должны сделать и предложить тебе законченное (и идеально сделанное) решение. Мы исходим из того, что решения удовлетворяющего нас на 100% нет. Но есть подход который можно развить до необходимого решения.
    VD>Мы предлагаем создасть свое решение и насрать на Майкрософт, таз уж их там колбасит по черному.
    VD>Ты же предлагаешь реализовть какой-то некрасивый компромис и пользоваться убогим транзактом.

    VD>Подходы в общем-то чем-то похожи. Оба имеют цель сделать собственное решение. Но твой подход — это половичатое решение которое по любому создаст кучу проблем.

    VD>Реален ли твой подход? Наверно — да! Но лично мне он не нравится.
    Ну сказать что бы он мне сильно нравился я такого не скажу. Я просто попытался придумать меньшую из зол.
    А написать своё провайдер или DSL дял работы с данными так меня просто не поймут.
    Представь сколько усилий понадобится на поддержку и развитие этого решения.
    Да и работа с данными станет проще конечно но не на порядок.

    Tom>>Вместо неё M$ надо было заняться обьектной базой и запросами к ней.


    VD>Ну, чем им там надо было бы заняться не нам с тобой решать. А то в этом форуме было бы более уместно обсудить вопрос почему МС развивает C# и F#, а не Nemerle. Казалось бы многие задаются этим вопросом, а в МС даже ответить на него не хотят.

    Я думаю эту ветку просто перенести можно, немерл тут офтопик пока.

    VD>Тем более, что вопрос ООБД крайне спорный. Я не считаю ООБД перспективной идеей. ООП банально более примитивная технология нежели ФП. Современные СУБД гораздо ближе к ФП и потому их средства обработки данных (запросы) намного мощнее.

    О, тогад вопрос, есть ли смысл в linq 2 entity? Ведь это попытка как я понимаю как раз делать запросы над некой обьектной структурой.

    Tom>>Вот тогда всё бы стало на свои места. Пишем себе на managed языке обьекты, сохраняим их в обьектнуцю БД и выбираем данные на том же языке на котором описаны сами данные.


    VD>Ты меня извини, но я тебе скажу правду от которой ты можешь обидится, но эта действительно правда. Ты смотришь на мир глазами незнайки. ООП далеко не лучшее решение во всех случаях. Обработка данных — это как раз тот случай где ООП практически ничего путного предложить не может.

    А гед я спорю с этим? Именно по этому я не предлагаю например всякую чёрную магию в виде ORM итп... А обрабатываю данные при помощи запросов

    VD>Задумайся над тем почему ты исползуешь транзакт, а не пишешь все на С#? Или даже поставим вопрос так. Почему ты в транзакте используешь SQL?

    Не понял
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[15]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 12:43
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>И вообще, если TSQL так крут, то зачем тебе вообще C# сдался? Пиши все на TSQL.

    Tom>Ну логику обоработки данных иы и пишем на TSQL.

    А что за логика еще есть в вашем приложении? Презентационная что ли?
    Зачем вам тогда C#. Возмите tcl/tk, например.

    Tom>Так я и не смпорбю что ВЕКТОР правильный, а реализация пока кривенькая. Вот будет DML тогда и будем переписывать.


    Но вот и мы о том же. Только ждать милости от природы не в наших правилах.

    Tom>Хотя для некоторых сложных запросов мы попытаемся сделать декомпозицию с помощью линка. Посмотрим насколько это реально.


    ОК. Можешь обращаться за помощь. Думаю многие согласятся помочь советами в этом деле.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 12:50
    Оценка:
    VD>А что за логика еще есть в вашем приложении? Презентационная что ли?
    GUI стоят в сторонке. Они есть конечно, нескольких типов но тут не сильно много логики. Есть ещё работа с железяками, custom scripting (programmability),

    VD>ОК. Можешь обращаться за помощь. Думаю многие согласятся помочь советами в этом деле.

    Боюсь за@бу я всех тогда

    У нас сейчас планируется первая часть рефакторинга — полное переползание на .NET (да да да, только сейчас... ((( )
    будут и другие, связанные с базой. Через годик. Может тогда на рынке будут достойные решения работы с БД.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[17]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 13:05
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>А написать своё провайдер или DSL дял работы с данными так меня просто не поймут.

    Tom>Представь сколько усилий понадобится на поддержку и развитие этого решения.
    Tom>Да и работа с данными станет проще конечно но не на порядок.

    Как показывает практика для некоторых задач создание специализированного под задачу ДСЛ-я позволяет упростить решение на порядки.
    Дело тут в том, что реализация ДСЛ-я — это весьма механистичная работа. Задача же описанная на ДСЛ-е содержит меньше ошибок (ДСЛ можно составить так, чтобы ошибки были невозможны, или чтобы был контроль) и ее намного проще осознать (так как объем и читабельность кода при этом снижаются на порядки).
    Но это если справедливо для ДСЛ-ей описывающих прикладную задачу. ДСЛ доступа к данным конечно же такого выигрыша дать не может, так как один фиг будет много другого кода.

    Tom>О, тогад вопрос, есть ли смысл в linq 2 entity? Ведь это попытка как я понимаю как раз делать запросы над некой обьектной структурой.


    Ключевое слово тут "entity". Entity и объект — это не одно и то же. EF ушел не туда в некоторых областях, но темнеменее его дизайн строится на основе модели данных. Я еще в 1995-ом проектировал БД с использованием EF-Win. Это такой Entity-моделлер. Поверь в EF-Win не было ни слова про объекты. Так же и в EF. Модель там от объектов не зависит. На объекты делается только отображение. А без этого никак. Ты же не можешь в ООЯ работать с понятием "запись БД"? В прочем, анонимные типы — это аналог кортежей БД. Так что... Но они и используются при работе с EF. Что плохо в EF — так это то же отсуствие поддержки DML и очень плохая поддержка функций конкретной СУБД.

    Tom>>>Вот тогда всё бы стало на свои места. Пишем себе на managed языке обьекты, сохраняим их в обьектнуцю БД и выбираем данные на том же языке на котором описаны сами данные.


    VD>>Ты меня извини, но я тебе скажу правду от которой ты можешь обидится, но эта действительно правда. Ты смотришь на мир глазами незнайки. ООП далеко не лучшее решение во всех случаях. Обработка данных — это как раз тот случай где ООП практически ничего путного предложить не может.

    Tom>А гед я спорю с этим?

    Ты считаешь, что ООБД — это решение проблемы. На самом деле это такой же тупик как идеи ОР-маперов вроде Гибернэйта.

    Tom>Именно по этому я не предлагаю например всякую чёрную магию в виде ORM итп... А обрабатываю данные при помощи запросов


    Тогда ты уж определись. Потому что ООБД и запросы — это разные подходы.
    ООП оперирует с графами объектов. Коллекции (в ООП) не являются строительной единицей. Напротив, в РСБУД коллекция является основной строительной единицей. Запросы же манипулируются с коллекциями. И именно по этому ООП и БД так плохо совмещаются.

    На мой взгляд РСУБД — это самый правильный механизм хранения и обработки данны. А мапинг нужен только очень простой — строк таблиц на плоские объекты. Именно так было сделано в linq2sql. EF немного вышел за эти границы, но тем не мнее поддерживает эту парадигму. А вот ООБД и разные гибернэйты предлагают плясать от объектного графа, что и создает проблемы.
    Так что без разница OR-Mappre или ООБД. Это все равно тупиковый путь.

    VD>>Задумайся над тем почему ты исползуешь транзакт, а не пишешь все на С#? Или даже поставим вопрос так. Почему ты в транзакте используешь SQL?

    Tom>Не понял

    Почему ты не используешь методы, циклы и другие атрибуты императивных языков для обрботки информации?
    Почему вместо этого ты используешь запросы?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[14]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 13:44
    Оценка:
    VD>Вопрос был: сгенерирует ли твой генератор один тип для этих двух запросов, или два разных?
    Генератор сгенерирует скорее метод возвращающий анонимный тип.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[15]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 13:45
    Оценка:
    Tom>Генератор сгенерирует скорее метод возвращающий анонимный тип.

    Хотя от этого наверное гемора будет больше чем пользы. Надо в общем подумать.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[15]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 14:54
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>Вопрос был: сгенерирует ли твой генератор один тип для этих двух запросов, или два разных?

    Tom>Генератор сгенерирует скорее метод возвращающий анонимный тип.

    Гы. Анонимный тип нельзя возвратить из метода.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 15:02
    Оценка:
    VD>Гы. Анонимный тип нельзя возвратить из метода.
    С использованием чёрной магии можно
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[19]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 15:03
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Только программка называется ER-Win,


    Ага. Это я очепятался.

    G>хотя работа в ней очень похожа на работу в дизайнере EF.


    Ага. Только наоборот. И это именно потому, что они оба редактируют диаграмму сущность-связь, а не граф объектов.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 15:05
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>Гы. Анонимный тип нельзя возвратить из метода.

    Tom>С использованием чёрной магии можно

    С использованием грязных хаков.

    Кстати, о причках. В Nemerle есть кортежи которые без проблем возвращаться из методов. Плюс есть локальные функции для которых есть вывод типов. Так что даже LINQ-ом и то из него проще пользоваться.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 15:23
    Оценка:
    VD>С использованием грязных хаков.
    не то что бы сильно грязных но не очень симпатишных

    //
    // Method that returns anonymous type as objectobject
    //
    object ReturnAnonymous()
    {
      return new { City="Prague", Name="Tomas" };
    }
    
    //
    // Application entry-pointv
    //
    void Main()
    {
      // Get instance of anonymous type with 'City' and 'Name' properties
      object o = ReturnAnonymous();
      
      // This call to 'Cast' method converts first parameter (object) to the
      // same type as the type of second parameter - which is in this case 
      // anonymous type with 'City' and 'Name'properties
      var typed = Cast(o, new { City="", Name="" });
      Console.WriteLine("Name={0}, City={1}", typed.Name, typed.City);
    }
    
    // Cast method - thanks to type inference when calling methods it 
    // is possible to cast object to type without knowing the type name
    T Cast<T>(object obj, T type)
    {
      return (T)obj;
    }


    изврат конечно

    VD>Кстати, о причках. В Nemerle есть кортежи которые без проблем возвращаться из методов. Плюс есть локальные функции для которых есть вывод типов. Так что даже LINQ-ом и то из него проще пользоваться.

    Я кстате так и не понял почему анонимый тип в C# нельзя явно обьявлять. Как в других человеческих языках. (((
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[19]: Nemerle & Real Life
    От: IT Россия linq2db.com
    Дата: 10.04.09 16:46
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Обезъяна с гранатой не знает что с ней делать. А если гранатой умело воспользоваться, то можно легко изничтожить тонны тупого копипейстного кода. И поддержка такого кода только выигрывает.

    Tom>Игорь, но ведь ьты предлагаешь писать больше кода. Как минимум классы resultset-ов.

    Имеем DDL:

    CREATE TABLE Person
    (
        PersonID   int          NOT NULL IDENTITY(1,1) CONSTRAINT PK_Person PRIMARY KEY CLUSTERED,
        FirstName  nvarchar(50) NOT NULL,
        LastName   nvarchar(50) NOT NULL,
        MiddleName nvarchar(50)     NULL,
        Gender     char(1)      NOT NULL CONSTRAINT CK_Person_Gender CHECK (Gender in ('M', 'F', 'U', 'O'))
    )
    ON [PRIMARY]


    Засекаем время, копипейстим, переформатируем, получаем:

    public class Person
    {
        public int    PersonID;
        public string FirstName;
        public string LastName;
        public string MiddleName;
        public char   Gender;
    }


    На всё ушло меньше одной минуты. Можно вообще ничего не писать, есть генератор, который сделает тоже самое. Затем сгенерированный файл вставляется в проект и далее поддерживается вручную. Кстати, многие, кто использует linq2sql именно так и делают, т.е. классы генерируются один раз вначале, из них вычищается весь мусор и далее всё поддерживается ручками.

    Tom>Напела мне жизнь. Допустим в линке есть некоторая поддержва в явном виде выборки данных. и нету поддержки UPDADE/DELETE/INSERT. В выборке данных есть поддержка всего процентов наверное 10-20 от всей мощи TSQL. Вопрос, нахрена козе баян? И что делать с действительно сложными запросами, которых у нас в огромном количестве. Да и смысла подменять один язык TSQL другим linq я не вижу. Тем более, что ты упорно игнорируешь тот факт что он мёртв.


    Linq2SQL может быть и мёртв, но сама технология Linq 2 anything else вполне себе ничего. А это значит, что рано или поздно появятся другие вполне вменяемые реализации. Об этом ещё рано говорить, но сейчас я занимаюсь поддержкой linq в BLToolkit и большинство вещей, о которых ты говоришь там будут устранены изначально. На самом деле, глядя на реализацию, видно, что команда linq2sql во многих местах схалтурила и некоторые вещи можно было бы сделать гораздо более эффективно. Да и не надо было им умничать со стейтом, нужно было делать тупой генератор DML, чем я сейчас и занимаюсь.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[20]: Nemerle & Real Life
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 17:18
    Оценка:
    IT>Linq2SQL может быть и мёртв, но сама технология Linq 2 anything else вполне себе ничего. А это значит, что рано или поздно появятся другие вполне вменяемые реализации. Об этом ещё рано говорить, но сейчас я занимаюсь поддержкой linq в BLToolkit и большинство вещей, о которых ты говоришь там будут устранены изначально. На самом деле, глядя на реализацию, видно, что команда linq2sql во многих местах схалтурила и некоторые вещи можно было бы сделать гораздо более эффективно. Да и не надо было им умничать со стейтом, нужно было делать тупой генератор DML, чем я сейчас и занимаюсь.

    Это уже больше похоже на что то что можно будет применять. Интересно сколько это всё займёт кода.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[20]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 17:18
    Оценка:
    G>Наверное потому что он будет неанонимным
    Ответ неправильный. НЕ анонимный тип имеет имя. По этому имени его можно использовать.
    Анонимный тип имени не имеет, но имеет тип, по которому его можно использовать.
    Например как то так:
    {string, int} t = new {Name="", 123}


    Плюс от такого подхода очевиден?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[17]: Nemerle & Real Life
    От: IT Россия linq2db.com
    Дата: 10.04.09 17:36
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Ну так MS и в твой генератор ресурсы вкладывать не будет.

    Tom>как это не будет если они его написали T4 используется в самой студии и для того же линка.

    Дык linq2sql они тоже написали, где гарантия, что они не похоронят и T4?

    IT>>Что касается спроков, то здесь у BLToolkit конкурентов нет. Вообще.

    Tom>От стор мы отказываемся, для On Demand систем это зло которое затрудняет обновление системы без downtime-а

    А как же 1000 хранимок в легаси-коде?

    Tom>Весь разговор сводится к тому что BLToolkit это хорошо, но на мои аргументы я так ответа твоего не услышал.


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

    Tom>Ещё раз повторю:

    Tom>При использовании BLToolkit-а приходится:

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

    Tom>1. Писать руками классы акцэсоров/resultset-ов. Что в свою очередь:


    Классы аксессоров пишутся на уровне декларации, код аксессоров писать не нужно, только объявление метода.

    Tom>1.1 Затрудняет поддержку. Так как если селект возвращает новое поле, или не возвращает поля вообще то во время компиляции ты об этом никогда не узнаешь.


    У вас селекты и бизнес-логику пишут разные люди? Или всё же девелопер добавляет поле в селект, добавляет его в entity, проверяет что его затея удалась и только потом отчитывается о проделанной работе?

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

    Tom>1.2 делает невозможным переход на BLToolkit для Legacy прилоджений. Допустим у нас 1000 хранимок возвращабщих resultset. Никто не будет руками писать и поддерживать эту 1000 классов.


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

    Tom>2 Поощеряет написание TSQL в коде. Что усложняет поддержку. А именно:

    Tom>2.1 Проверить синтаксис TSQL можно только в runtime.

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

    Tom>2.2 Делает невозможным использовать средства рефакторинга/анализа TSQL кода, такие как VSTS Database Edition GDR и прочие.


    Читай выше.

    Tom>2.3 Делает невозможным валидацию кода в compile time средствами, которые являются аналогом Fx Cop но для TSQL. (фактически анализ кода)


    Без понятия что это такое, но если это опять имеет отношение к внешнему SQL, то с этим проблем нет.

    Tom>Если интересно продолжать то хотелось бы аргументированно и с примерами.


    Примерами чего?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[21]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 10.04.09 17:46
    Оценка:
    Здравствуйте, Tom, Вы писали:

    G>>Наверное потому что он будет неанонимным

    Tom>Ответ неправильный. НЕ анонимный тип имеет имя. По этому имени его можно использовать.
    Tom>Анонимный тип имени не имеет, но имеет тип, по которому его можно использовать.
    Тип и есть тип. В случае анонимного типа мы не можем написать его в программе, потому что не знаем его имени, если знаем имя, то тип перестает быть анонимным.

    Tom>Например как то так:

    Tom>
    Tom>{string, int} t = new {Name="", 123}
    Tom>


    Полу-именнованный кортеж чтоли? Такое хоть где-то работает?
    {string, int} t1 = new {FirstName="", 123}
    {string, int} t2 = new {LastName="", 123}
    t1.GetType() == t2.GetType() //? как оно вообще работает?
    
    //если у нас функция
    void func({string, int} p) //Она вообще что принимает?



    Tom>Плюс от такого подхода очевиден?

    Нет, это бредятина какая-то.
    Re[15]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 10.04.09 18:17
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>Вопрос был: сгенерирует ли твой генератор один тип для этих двух запросов, или два разных?

    Tom>Генератор сгенерирует скорее метод возвращающий анонимный тип.

    Анонимный тип нельзя возвращать из метода.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[19]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 10.04.09 18:19
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>изврат конечно


    Будет работать только в пределах одной сборки.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[21]: Nemerle & Real Life
    От: IT Россия linq2db.com
    Дата: 10.04.09 18:22
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Это уже больше похоже на что то что можно будет применять. Интересно сколько это всё займёт кода.


    Реализация самого провайдера? А какая разница?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[22]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 19:01
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Полу-именнованный кортеж чтоли? Такое хоть где-то работает?


    Да. Во многих ФЯ. В ОКамле, например. Называется запись (record).
    Но в ФЯ типы кортежей совместимы по структуре. Это называется структурной идентичностью.
    Если объявить две записи с одним набором полей (и типов у каждого поля), то их объекты будут иметь один тип и их можно будет использовать друг вместо друга. Так же их можно будет сравнивать и копировать.

    Но такая фича не поддерживается в дотнете. По этому даже ФЯ реализованные на дотнете не поддерживают записей (по крайней мере в полной мере).
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 10.04.09 19:02
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Поздравляю, ты только что изобрёл tuple Только в Немерле он записывается так string * int.


    Скорее record которого нет ни в Немерле, ни в Шарпе.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: Nemerle & Real Life
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 20:25
    Оценка:
    IT>Если ты называешь манипуляцией данными то, что ты привёл выше, то это скорее бизнес логика, написанная на TSQL. Это нужно устранять в первую очередь. SQL должен заниматься исключительно тем, для чего он создавался — манипуляцией данными, т.е. исключительно запросами вида SELECT/INSERT/UPDATE/DELETE.

    Ну тогда тебе в ORM лагерь.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[22]: Nemerle & Real Life
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 20:28
    Оценка:
    IT>Реализация самого провайдера? А какая разница?
    Ну как же, если это предпологаемое решения для работы с данными — и оно написано руками то поддерживать его придётся.
    Вот мне и интересно, насколько игра стоит свеч.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[16]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 20:28
    Оценка:
    IT>Компилятор то тут при чём?
    Мне кажется без изменения компилятора и синтаксиса языка полноценную работу с данными в него не впихнуть.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[23]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 10.04.09 20:30
    Оценка:
    VD>Скорее record которого нет ни в Немерле, ни в Шарпе.
    А в чём разница между tuple и record?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[23]: Nemerle & Real Life
    От: IT Россия linq2db.com
    Дата: 10.04.09 21:42
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Ну тогда тебе в ORM лагерь.


    Это смотря какой ORM? ORM'ы бывают разные. Бывают heavy ORM, бывают lightweight ORM. BLToolkit относится ко второй категории.

    Что же касается бизнес логики на TSQL, которую ты здесь привёл, то это одно из двух: либо пережиток старого, либо дурь. Надеюсь первое. Разумного оправдания такой практике сегодня нет.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[23]: Nemerle & Real Life
    От: IT Россия linq2db.com
    Дата: 10.04.09 21:44
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Реализация самого провайдера? А какая разница?

    Tom>Ну как же, если это предпологаемое решения для работы с данными — и оно написано руками то поддерживать его придётся.
    Tom>Вот мне и интересно, насколько игра стоит свеч.

    Я не пойму о чём ты. О коде, который я сейчас пишу или о коде, который ты потом будешь писать?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[17]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 10.04.09 21:52
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Компилятор то тут при чём?

    Tom>Мне кажется без изменения компилятора и синтаксиса языка полноценную работу с данными в него не впихнуть.

    Если ты имеешь ввиду расширение синтаксиса для поддержки Linq, то компилятор всего лишь преобразовывает этот синтаксис в последовательность вызовов методов с определённой сигнатурой. А самому linq2sql всё равно каким из следующих двух способов ты выразишь свой запрос:

    var q1 = from p in db.Person where p.ID == 1 select p;
    var q2 = db.Person.Where(p => p.ID == 1).Select(p => p);

    Если написать соответствующие методы Update/Insert/Delete и обучить linq провайдера их понимать, то проблема решена. Без участия компилятора.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[18]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 11.04.09 00:35
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Если написать соответствующие методы Update/Insert/Delete и обучить linq провайдера их понимать, то проблема решена. Без участия компилятора.


    А в каком примерно синтаксисе это будет?
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[19]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 11.04.09 01:29
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    IT>>Если написать соответствующие методы Update/Insert/Delete и обучить linq провайдера их понимать, то проблема решена. Без участия компилятора.


    V>А в каком примерно синтаксисе это будет?


    Delete просто Delete()
    Insert я бы сделал как .Insert(p => new Person { ID = p.ID, ...})
    Update скорее всего так же как и Insert, но можно рассмотреть и другие варианты, семантически более близкие к соответствующей операции.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[16]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 11.04.09 02:50
    Оценка:
    Здравствуйте, VladD2, Вы писали:


    VD>Тем более, что вопрос ООБД крайне спорный. Я не считаю ООБД перспективной идеей. ООП банально более примитивная технология нежели ФП. Современные СУБД гораздо ближе к ФП и потому их средства обработки данных (запросы) намного мощнее.


    От ООБД можно взять "типизированность" кортежей. Да и вообще, побольше бы типизированности всего. Просто есть что-то не то в том, что по union можно в один столбец явно, или по ошибке склеить числовые и строковые данные, и никто не тебе ругнётся на это.
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[23]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 06:52
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    G>>Полу-именнованный кортеж чтоли? Такое хоть где-то работает?


    VD>Да. Во многих ФЯ. В ОКамле, например. Называется запись (record).

    VD>Но в ФЯ типы кортежей совместимы по структуре. Это называется структурной идентичностью.
    VD>Если объявить две записи с одним набором полей (и типов у каждого поля), то их объекты будут иметь один тип и их можно будет использовать друг вместо друга. Так же их можно будет сравнивать и копировать.

    VD>Но такая фича не поддерживается в дотнете. По этому даже ФЯ реализованные на дотнете не поддерживают записей (по крайней мере в полной мере).


    Я в курсе что такое записи, я не понял как будет работать в такой записи:

    {string, int} t = new {Name="", 123}


    Как компилятор будет понимать {string, int}? И как будет выводить имя второго поля в записи new {Name="", 123}?
    Re[24]: Nemerle & Real Life
    От: Tom Россия http://www.RSDN.ru
    Дата: 11.04.09 07:17
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    Tom>>Ну тогда тебе в ORM лагерь.


    IT>Это смотря какой ORM? ORM'ы бывают разные. Бывают heavy ORM, бывают lightweight ORM. BLToolkit относится ко второй категории.


    IT>Что же касается бизнес логики на TSQL, которую ты здесь привёл, то это одно из двух: либо пережиток старого, либо дурь. Надеюсь первое. Разумного оправдания такой практике сегодня нет.


    Если серьёзно, ты можешь показать на данном примере как грамотно это дело порефакторить.
    Сейчас мы этого не сможем сделать но в следующей версии рефакторинг базы конечно надо будет делать.
    Я просто хочу понять основные принципы. Или ты опять о тотальном переносе всего в C#?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[24]: Nemerle & Real Life
    От: Tom Россия http://www.RSDN.ru
    Дата: 11.04.09 07:17
    Оценка:
    IT>Я не пойму о чём ты. О коде, который я сейчас пишу или о коде, который ты потом будешь писать?
    О коде который ты сейчас пишешь. Провайдер.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[25]: Nemerle & Real Life
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 08:31
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Если серьёзно, ты можешь показать на данном примере как грамотно это дело порефакторить.

    Tom>Сейчас мы этого не сможем сделать но в следующей версии рефакторинг базы конечно надо будет делать.
    Tom>Я просто хочу понять основные принципы. Или ты опять о тотальном переносе всего в C#?

    Переписывать за тебя это вряд ли кто станет. Но советы можно дать.
    1. Избавиться ото всех курсоров.
    2. Избавиться ото всех временных таблиц.
    3. Разделить логику выборки и логику вставки/обновления данных, так чтобы четко было видно, что за информация вычисляется и как она обновляется в таблицах.

    Пункты 1 и 2 можно сделать если использовать табличные переменные и/или хранимые функции.

    Собственно как только вы это сделаете, то вопрос перобразования этого дела в тот же linq+ будет вопросом чисто механическим.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[25]: Nemerle & Real Life
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 08:34
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Я не пойму о чём ты. О коде, который я сейчас пишу или о коде, который ты потом будешь писать?

    Tom>О коде который ты сейчас пишешь. Провайдер.

    Ну, дык, этот же код он будет поддерживать. Тебе то что?

    Тут важен не объем кода, а его качество (читаемость, структурированость).
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 08:48
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>Скорее record которого нет ни в Немерле, ни в Шарпе.

    Tom>А в чём разница между tuple и record?

    В том, что поля у последнего именованные.
    Проблема в том, что tuple можно разместить в библиотеке и использовать для всех экзепляров один и тот же тип (generic, естественно). А вот record не может быть помещен в библиотеку так как имена полей различаются.

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

    А record нужно было бы ввести на уровне CLR. Тогда его поддержка в компиляторе была бы элементарным делом.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 08:51
    Оценка:
    Здравствуйте, dotneter, Вы писали:

    VD>>Вот только в 4-ом дотнете, где будет новый рантайм, все равно ничего для поддержки структурной идентичности сделано не будет.

    D>И еще раз http://channel9.msdn.com/pdc2008/TL02/

    Что значит "еще раз"? У меня нет времени смотреть мультфильмы.

    Хочешь сказать, что поддержка структурной идентичности все же будет в 4.0?
    Я слышал обратное. В прочем я слышал это о C#.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 09:02
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Я в курсе что такое записи, я не понял как будет работать в такой записи:


    G>
    G>{string, int} t = new {Name="", 123}
    G>


    Эта запись — фантазия человека. Конечно разумнее было бы использовать более классическую запись вроде:
    Name : string * ID : int


    G>Как компилятор будет понимать {string, int}? И как будет выводить имя второго поля в записи new {Name="", 123}?


    Никак. Это, скорее всего, просто ошибка автора того сообщения. Конечно имя должно задаваться явно. Или при описании типа, или внутри выражения. Если уж есть описание типа, то конечно в нем.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[26]: Nemerle & Real Life
    От: Tom Россия http://www.RSDN.ru
    Дата: 11.04.09 10:03
    Оценка:
    VD>Ну, дык, этот же код он будет поддерживать. Тебе то что?
    Если вдруг мы решим его использовать то ждать пока кто то пофиксит там баг который для нас является критическим конечно мы не будем.
    ну и просто что бы оценить сложность решения хотелось бы понять его обьём.

    VD>Тут важен не объем кода, а его качество (читаемость, структурированость).

    Кто же спорит
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[25]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 11.04.09 10:03
    Оценка:
    VD>Никак. Это, скорее всего, просто ошибка автора того сообщения.
    Моя описка
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[2]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 11.04.09 10:03
    Оценка:
    A>Почитал дискуссию,
    Ну ты монстр

    A>A>не согласен со всеми



    A>Суть задачи в том, чтобы сгенерировать DAL и немножечко бизнес логики (ну сколько получится). DAL в свою очередь, грубо говоря, состоит из SQL и C#. При этом почему-то ошибочно предполагается что C# или SQL могут хранить всю информацию, необходимую для генерации части на другом языке или даже могут это делать удобно. Враки это всё. Хуже того, сгенерировать DAL это пол-беды,



    A>надо уметь удобно переезжать со старой версии на новую, модифицируя схему БД.

    Обновление системы и БД это отдельный разговор. В этой ветке его лучше не упоминать.

    A>C# генерировать из SQL нельзя по той простой причине, что SQL менее типизирован и понять что именно возвращает запрос: один объект, список объектов предопределённого типа, просто какие-то табличные данные, нельзя.

    На самом деле мне тоже так показалось. Давай рассмотрим случай когда нам надо вернуть один обьект или несколько. Допустим у нас есть функции ***GetById и ***GetAll. Допустим в первой мы хотим возвращать один обьект а во второй List<Ы> обьектов. Пока всё хорошо. Теперь рассмотрим случай когда в БД для обоих вызовов не нашлось записи. Что возвращать в таком случае? Для первой функции вариантов только два, null или исключение. Для второй больше. null, пустой список, исключение. В варианте null для первой функции у нас добавляется дополнительное действие. После вызова функции — проверка что обьект не null. А следовательно, мы смело можем возвращать всегда список, для обоих функций. Тоесть и из ***GetById и ***GetAll возвращать List<>. С одной стороны это выглядит как то не так, а с другой, если возвращаться один обьект, то всё равно проверку на null надо будет делать а тогда какая разница.

    A>К тому же сам SQL, как способ описания сущностей, неприемлем. Один объект может храниться в нескольких таблицах, связи между объектами (FK) устанавливаются не очень удобно и не несут однозначного смысла.

    Открою тебе секрет. Понятия сущность в природе не существует. В природе существуют два других — таблица и выборка. В таблицу надо делать вставки и обновления. А выборка может жить собственной жизнью, и набор полей зависит только от логики самой выборки.

    A>SQL из C# сгенерировать можно, но поддерживать это хозяйство сложно. Много чего приходится указывать вручную. Нет никакого нормального механизма обновления схемы без потери данных.

    Обновление схемы — это отдельный вопрос. Вопрос решаемый разными путями, предлагаю обсуждать не тут.

    A>DAL не просто можно, его обязательно нужно генерировать. Но не C# из SQL или SQL из C#. И то и другое надо генерировать из третьего, более приспособленного для хранения условий задачи, источника.м-

    Об этом говорил Влад, что и то и то надо генерить по некоторой модели. Но на данный момент есть легаси приложение которое надо переносить на .NET причём эволюционным путём. Переписыть всё с нуля — такой подход невозможен.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[3]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 10:27
    Оценка:
    Здравствуйте, Tom, Вы писали:

    A>>надо уметь удобно переезжать со старой версии на новую, модифицируя схему БД.

    Tom>Обновление системы и БД это отдельный разговор. В этой ветке его лучше не упоминать.

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

    A>>C# генерировать из SQL нельзя по той простой причине, что SQL менее типизирован и понять что именно возвращает запрос: один объект, список объектов предопределённого типа, просто какие-то табличные данные, нельзя.

    Tom>На самом деле мне тоже так показалось. Давай рассмотрим случай когда нам надо вернуть один обьект или несколько. Допустим у нас есть функции ***GetById и ***GetAll. Допустим в первой мы хотим возвращать один обьект а во второй List<Ы> обьектов. Пока всё хорошо. Теперь рассмотрим случай когда в БД для обоих вызовов не нашлось записи. Что возвращать в таком случае? Для первой функции вариантов только два, null или исключение. Для второй больше. null, пустой список, исключение. В варианте null для первой функции у нас добавляется дополнительное действие. После вызова функции — проверка что обьект не null. А следовательно, мы смело можем возвращать всегда список, для обоих функций. Тоесть и из ***GetById и ***GetAll возвращать List<>. С одной стороны это выглядит как то не так, а с другой, если возвращаться один обьект, то всё равно проверку на null надо будет делать а тогда какая разница.

    ИМХО всё не так. Для GetById надо откуда-то взять этот самый Id. Отсутствие объекта это исключительная ситуация и никаким null тут и не пахнет. К тому же ты пропустил вариант "просто какие-то табличные данные", что весьма типично для отчётов.

    Tom>Открою тебе секрет. Понятия сущность в природе не существует. В природе существуют два других — таблица и выборка. В таблицу надо делать вставки и обновления. А выборка может жить собственной жизнью, и набор полей зависит только от логики самой выборки.


    Понятие сущности есть. Есть сущность — клиент. У него есть множество предопределённых свойств хранящихся в таблице Customers и множество добавленных пользователями, хранящихся в таблице CustomerProperties в виде (CustomerID, PropertyName, PropertyValue). Соответственно есть extandable сущность customer. Этого определения вполне достаточно, чтобы сгенерировать схему БД, а так же все операции вставки, обновления и выборки.

    A>>SQL из C# сгенерировать можно, но поддерживать это хозяйство сложно. Много чего приходится указывать вручную. Нет никакого нормального механизма обновления схемы без потери данных.

    Tom>Обновление схемы — это отдельный вопрос. Вопрос решаемый разными путями, предлагаю обсуждать не тут.

    Я уже выше отписался, почему считаю этот вопрос актуальным.

    Tom>Об этом говорил Влад, что и то и то надо генерить по некоторой модели. Но на данный момент есть легаси приложение которое надо переносить на .NET причём эволюционным путём. Переписыть всё с нуля — такой подход невозможен.


    А кто сказал переписывать с нуля? Можно генерировать так, чтобы получалось то же самое или почти то же самое, что есть сейчас. Внешний генератор тем и хорош, что сам по себе не видим, только результаты.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[22]: Проблемы организации OR-мапинга
    От: dotneter  
    Дата: 11.04.09 10:58
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Хочешь сказать, что поддержка структурной идентичности все же будет в 4.0?

    По крайней мере будут ее зачатки. Если два интерфейса с одинаковой структурой пометить одинаковым Guid то для clr они будут эквивалентными.

    VD>Я слышал обратное. В прочем я слышал это о C#.

    Глядишь к 5 версии чего нибудь сделают.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
    Talk is cheap. Show me the code.
    Re[27]: Nemerle & Real Life
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 12:25
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>Ну, дык, этот же код он будет поддерживать. Тебе то что?

    Tom>Если вдруг мы решим его использовать то ждать пока кто то пофиксит там баг который для нас является критическим конечно мы не будем.

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


    Tom>ну и просто что бы оценить сложность решения хотелось бы понять его обьём.


    Понятие "сложность" относительное понятие. Сложное для одного не сложно для другого. Так что это вообще смысла не имеет.
    Почему ты, к примеру, не интересующийся сложностью того же MS SQL Server? Почему тебя вдруг так начала интересовать сложность библиотечки доступа к данным?

    VD>>Тут важен не объем кода, а его качество (читаемость, структурированость).

    Tom>Кто же спорит

    Ну, дык, а что тогда спрашивать вообще не касающиеся тебя детали?
    Пойми кода может быть 2 килобайта, но ты в них вообще разобраться не сможешь. Как измерить сложность для тебя?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[23]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 12:32
    Оценка:
    Здравствуйте, dotneter, Вы писали:

    VD>>Хочешь сказать, что поддержка структурной идентичности все же будет в 4.0?

    D>По крайней мере будут ее зачатки. Если два интерфейса с одинаковой структурой пометить одинаковым Guid то для clr они будут эквивалентными.

    Это немного не то. Точнее совсем не то. Во-первых, у интерфейсов нет структуры, так что их эквивалентности добиться не сложно. Главное чтобы совпадали сигнатуры и позиции методов.
    Во-вторых, определение идентичности по гуидам может быть полезно только для интеропа. Для структурной идентичности нужно чтобы эквивалентность определялась самим рантаймом и только на основании описания типов.

    VD>>Я слышал обратное. В прочем я слышал это о C#.

    D>Глядишь к 5 версии чего нибудь сделают.

    Судя по реакции (полное молчание) Хейльсберга в шарпе точно ни фига не будет.

    С другой стороны, если достаточная поддержка будет в рантайме, то для Немерле мы ее сделаем.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[2]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 12:38
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Почитал дискуссию, не согласен со всеми


    Где-то я это уже видел... А в "Собачьем сердце".

    — Читал я эту переписку Кауткого с Троцким.
    — И что же?
    — А не согласен я!
    — С кем же, простите за любопытство?
    — Да, с обоими!
    ...
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 12:47
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    A>>Почитал дискуссию, не согласен со всеми


    VD>Где-то я это уже видел... А в "Собачьем сердце".


    VD>- Читал я эту переписку Кауткого с Троцким.

    VD>- И что же?
    VD>- А не согласен я!
    VD>- С кем же, простите за любопытство?
    VD>- Да, с обоими!
    VD>...
    VD>

    Вообще-то, действительно не со всеми, а с обоими: IT и Tom.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[2]: Проблемы организации OR-мапинга
    От: SleepyDrago Украина  
    Дата: 11.04.09 12:50
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Почитал дискуссию, не согласен со всеми

    A>Суть задачи в том, чтобы сгенерировать DAL и немножечко бизнес логики (ну сколько получится). DAL в свою очередь, грубо говоря, состоит из SQL и C#. При этом почему-то ошибочно предполагается что C# или SQL могут хранить всю информацию, необходимую для генерации части на другом языке или даже могут это делать удобно. Враки это всё. Хуже того, сгенерировать DAL это пол-беды, надо уметь удобно переезжать со старой версии на новую, модифицируя схему БД.

    A>DAL не просто можно, его обязательно нужно генерировать. Но не C# из SQL или SQL из C#. И то и другое надо генерировать из третьего, более приспособленного для хранения условий задачи, источника.м

    Прочитал тему ( что отпуск с людьми делает )
    Видел такие системы где тонны легаси "используют всю мощь xxx-sql", где в схеме данных черт ногу сломит, а описание входных/выходных xml-ек ... И к этому серверному хозяйству морды на с++/c#.
    интересно детально рассмотреть свойства "третьего" языка. Инструментарий для работы с ним. Кто и с каким образованием будет на нем писать. Потому что подход "вся логика на шарпе" — он прост в плане управления и понятен программерам. У дэбэшников от него волосы встают дыбом но это не важно. Даже участвовал в обсуждении одного ресерча как раз на эту тему так что просьба развить тему. Сейчас все наперебой говорят про dsl, но никто не предлагает понятную методику работы с ним.
    Re[3]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 12:58
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    SD>интересно детально рассмотреть свойства "третьего" языка. Инструментарий для работы с ним. Кто и с каким образованием будет на нем писать. Потому что подход "вся логика на шарпе" — он прост в плане управления и понятен программерам. У дэбэшников от него волосы встают дыбом но это не важно. Даже участвовал в обсуждении одного ресерча как раз на эту тему так что просьба развить тему. Сейчас все наперебой говорят про dsl, но никто не предлагает понятную методику работы с ним.


    Лично я в качестве третьего языка использую файл в формате-который-не-имеет-значения и графический редактор к нему. Так же есть библиотека для выдирания настроек в виде C# объектов, её использует генератор.

    P.S. На самом деле файл в XML, но это деталь реализации.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[24]: Проблемы организации OR-мапинга
    От: dotneter  
    Дата: 11.04.09 13:04
    Оценка:
    Здравствуйте, VladD2, Вы писали:


    VD>Это немного не то. Точнее совсем не то. Во-первых, у интерфейсов нет структуры, так что их эквивалентности добиться не сложно. Главное чтобы совпадали сигнатуры и позиции методов.

    Что значит нет структуры? В моем понимании то что описано в интерфейсе и есть его структура.
    VD>Во-вторых, определение идентичности по гуидам может быть полезно только для интеропа. Для структурной идентичности нужно чтобы эквивалентность определялась самим рантаймом и только на основании описания типов.
    Можно этот гуид генерировать на основании описания.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
    Talk is cheap. Show me the code.
    Re[4]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 13:17
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Вообще-то, действительно не со всеми, а с обоими: IT и Tom.


    Ром, не обижайся, но твои рассуждения в этой теме не только по форме на шариковские похожи. Они и по сути тоже не ахти. На все твои утверждения с уверенностью можно сказать, что они не верны.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[4]: Проблемы организации OR-мапинга
    От: SleepyDrago Украина  
    Дата: 11.04.09 13:25
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Лично я в качестве третьего языка использую файл в формате-который-не-имеет-значения и графический редактор к нему. Так же есть библиотека для выдирания настроек в виде C# объектов, её использует генератор.


    Ок я видел такие системы и участвовал в обсуждении.
    Пункт первый. Разработчик визуального редактора повторял (дословно! с учетом перевода на рус) следующее "Дали бы еще месяц на его доработку..." Насколько знаю никто не дал
    Пункт второй. Генератор для шарпа и плюсов в принципе понятен. Пишется на шарпе с antlr+-stringtemplate. На выходе определения сущностей и тп. Пишется как правило теми же кто и будет использовать. Вот с генераторами для xxx-sql не все так просто. Во первых люди которые "используют всю мощь" далеки от рутины программирования на шарпе — тут будут постоянные высокочастотные общения db-people с c#-people. Во вторых языки (я знаком только с оракловым вариантом так что не в курсе про мс) xxx-sql, они как бы это сказать — непростые для понимания неподготовленными людьми, а иметь монстра c#-db в одном флаконе завязанного на один высококритичный генератор ммм рискованное дело.
    В третьих — как на этом языке-с-визуальным-редактором будет описываться бизнес логика (самое объемное и важное) ? Тут нужны пояснения.

    зы. Чтобы не растекаться по древу ответы на первые два пункта можно пропустить тк это скорее кадровые проблемы.
    ззы спасибо, хоть я сейчас далек от этого, но от ... лучше не зарекаться
    Re[25]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 13:32
    Оценка:
    Здравствуйте, dotneter, Вы писали:

    D>Что значит нет структуры? В моем понимании то что описано в интерфейсе и есть его структура.


    То и значит. Нет полей. Нет "структуры".

    VD>>Во-вторых, определение идентичности по гуидам может быть полезно только для интеропа. Для структурной идентичности нужно чтобы эквивалентность определялась самим рантаймом и только на основании описания типов.

    D>Можно этот гуид генерировать на основании описания.

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

    И, главное, не ясно зачем такие сложности? Ведь все что нужно — это стрктурная идентичность типов. Это еще в С было и в Лиспе. Так что "технологии" около 50 лет.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[5]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 13:34
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    SD>Пункт первый. Разработчик визуального редактора повторял (дословно! с учетом перевода на рус) следующее "Дали бы еще месяц на его доработку..." Насколько знаю никто не дал


    О, это не проблема. Редактор очень простой. Первую версию я написал за неделю и до сих пор ей пользуюсь, даже и не думая о переписывании

    SD>Пункт второй. Генератор для шарпа и плюсов в принципе понятен. Пишется на шарпе с antlr+-stringtemplate. На выходе определения сущностей и тп. Пишется как правило теми же кто и будет использовать.


    Нет. Генератор для шарпа пишется на hypertext preprocessor.

    SD>Вот с генераторами для xxx-sql не все так просто. Во-первых, люди которые "используют всю мощь" далеки от рутины программирования на шарпе — тут будут постоянные высокочастотные общения db-people с c#-people. Во-вторых, языки (я знаком только с оракловым вариантом так что не в курсе про мс) xxx-sql, они как бы это сказать — непростые для понимания неподготовленными людьми, а иметь монстра c#-db в одном флаконе завязанного на один высококритичный генератор ммм рискованное дело. В третьих — как на этом языке-с-визуальным-редактором будет описываться бизнес логика (самое объемное и важное) ? Тут нужны пояснения.


    Нет. Редактор редактирует только модель. Генератор существует совсем отдельно и представляет собой что-то вроде PHP/ASP. В данный момент я его встраиваю в VS. Для C# вывод записывается в файл, для SQL вывод исполняется на сервере БД (ну и записывается в файл, заодно). То есть db-people вполне могут сгенерировать всё что захотят, или, для какой-то конкретной сущности, вообще всё написать руками.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[6]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 13:46
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Влад, ну ты вместо аргументированного ответа решил задеть собеседника? Когда нечего сказать по существу, лучше вообще не писать.


    Ром, аргументированный ответ можно дать только на аргументированное утверждение. А ты всего лишь декларировал некоторые постулаты которые попросту не верны.

    Взять хотя бы утверждение "SQL менее типизирован и понять что именно возвращает запрос: один объект, список объектов предопределённого типа, просто какие-то табличные данные, нельзя".

    1. В РСБУД и в SQL вообще нет объектов. Стало быть разговор о их возврате — это ээ... ну, сам придумай как это по мягче назвать, в общем.
    2. Утверждение о нетипизированности запросов стоило бы обосновать. Оно явно не верно, но без твоего обоснования я должен тратить свои силы на обоснование очевидного факта.
    3. Запрос, в РСУБД, всегда возвращает список записей (они не даром так называются, запись это кортеж с именованными полями). Единичное (скалярное) значение не более чем частный случай — список состоящий из одной записи которая в свою очередь состоит из одного элемента (поля).

    Если запрос делается над таблицами (которые тоже являются списками записей) типы полей которых, вывести тип возвращаемого значения не проблема.

    Теперь о причинах по которым тебе тяжело будет объяснить почему ты не прав.
    Дело в том, что ты исходишь из узкого и не верного трактования действительности. Ты смотришь на доступ к данным через призму ООП-теории. Этот взгляд не может привести к пониманию обсуждаемого в данной теме. Отсюда все разговоры о выборе объектов из базы. О каких то там связях частей объектов и т.п.
    Так что первое что нужно понять для понимания этой темы — в БД нет объектов. И мы просто предлагаем вместо работы с объектами в БД, работать с данными вынимаемыми из БД и размещаемыми структурах удобных для обработки в прикладном языке программирования.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 13:58
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Влад, ну ты вместо аргументированного ответа решил задеть собеседника? Когда нечего сказать по существу, лучше вообще не писать.


    Ром. Ну, ты же пишешь чёрт знает что и даже не думаешь об обосновании своих утверждений?
    Пойми, такой уровень разговора не располагает к аргументированному ответу. Первое что захотелось сделать в ответ на твое сообщение это отквотить его и написать "чушь" к каждому утверждению. Я сдержался и ответил спокойно.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: Проблемы организации OR-мапинга
    От: SleepyDrago Украина  
    Дата: 11.04.09 14:01
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    SD>>Пункт первый. Разработчик визуального редактора повторял (дословно! с учетом перевода на рус) следующее "Дали бы еще месяц на его доработку..." Насколько знаю никто не дал


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

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

    SD>>Пункт второй. Генератор для шарпа и плюсов в принципе понятен. Пишется на шарпе с antlr+-stringtemplate. На выходе определения сущностей и тп. Пишется как правило теми же кто и будет использовать.


    A>Нет. Генератор для шарпа пишется на hypertext preprocessor.

    Не важно. Его пишут programmers.

    SD>> как на этом языке-с-визуальным-редактором будет описываться бизнес логика (самое объемное и важное) ?


    A>Нет. Редактор редактирует только модель. Генератор существует совсем отдельно ...

    именно это и было сделано. Редактор ооп модели. Вам же в теме показывали листинги "сложных запросов" Чем вы предлагаете их заменить? Это в чистом виде бизнес логика. Причем в терминах, к которым ооп имеет отдаленное отношение Плюс протокол общения клиента и сервера. Те самые result set'ы. Это ж отдельная копилка багов на обоих сторонах. В процессе эволюции там происходят такие мутации что Я даже видел попытку сделать несколько языков. Один для протокола другой для логики и тп.
    В общем есть мнение что от количества сгенерированных сущностей размер работы не уменьшается. Вот если для сущности генерировать настраиваемую на каждом этапе цепочку (визуальный редактор — протокол обмена с сервером данными — тупая бизнес логика — структура хранения) это было бы интересно. Языки описания этого всего в один не-скажу-какого формата файл явно не лезут для типичных систем. Для простоты можно ui отбросить тк это все равно трудоемкая часть и там прорыва в ближайшее время можно не ждать. Обмен данными с сервером и их обработка на сервере — это то о чем здесь ломают копья (и не в первый раз).
    Re[26]: Проблемы организации OR-мапинга
    От: dotneter  
    Дата: 11.04.09 14:03
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>То и значит. Нет полей. Нет "структуры".

    Тоесть для интерфейса понятие структурной эквивалентности не применимо?
    И
    interface IValue
    {
      int Value {get;set;}
    }
    
    class A: IValue
    {
      public int Value {get;set;}
    }
    
    interface IValue2
    {
      int Value{get;set;}
    }
    
    public void Test(IValue2 value);
    Test(new A())

    нельзя назвать эквивалентностью интерфейсов?

    Можно тогда какой нибудь пример применения этой самой структурной эквивалентности?


    VD>Крут ты! Я вот не знаю как такое сделать, да еще чтобы при этом не пересечься с гуидами сгенерированными другими средствами.

    Ну а чего, для IValue берем строку вида "int,Value" и генерим по ней Guid, дешево и сердито.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
    Talk is cheap. Show me the code.
    Re[7]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 14:12
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    A>>Нет. Редактор редактирует только модель. Генератор существует совсем отдельно ...

    SD>именно это и было сделано. Редактор ооп модели. Вам же в теме показывали листинги "сложных запросов" Чем вы предлагаете их заменить?

    Я задачу "генерировать всё" вообще никогда перед собой не ставил. Нет и не может быть удобного универсального генератора для всего. Я ставил задачу сгенерировать 90%, и позволить остальные 10% писать руками так, чтобы они органично вливались в сгенерированный код.
    Скажем для запросов, я хочу перейти на Linq, а не писать sQL код, потому что это увеличит типобезопасность. Но даже так, основной выигрыш налицо — руки писать надо гораздо меньше.

    SD>Обмен данными с сервером и их обработка на сервере — это то о чем здесь ломают копья (и не в первый раз).


    Не совсем понял, проблема в том что передавать или в том как?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[25]: Nemerle & Real Life
    От: IT Россия linq2db.com
    Дата: 11.04.09 15:25
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Если серьёзно, ты можешь показать на данном примере как грамотно это дело порефакторить.


    Этот код не надо рефакторить. Его нужно переписывать.

    Tom>Сейчас мы этого не сможем сделать но в следующей версии рефакторинг базы конечно надо будет делать.

    Tom>Я просто хочу понять основные принципы. Или ты опять о тотальном переносе всего в C#?

    Что значит тотальном? В моих приложениях императивная логика на TSQL отсутствует или устраняется, если есть в старом коде, при первой же возможности. SQL (в моём случае Sybase) выполняет только одиночные запросы без всяких IF и WHILE в SQL. Бывают, конечно, исключения, как правило это ситуации, когда необходимо нагенерировать большое количество записей по данным в БД и вставить эти записи обратно в БД. Если генерацию делать на клиенте, то вставка в базу происходит долго, гораздо эффективнее это делать скриптом. Но и здесь пока мне удавалось избегать IF и WHILE. Если же случай совсем невменяемый, то я предпочитаю сгенерировать SQL под конкретную задачу на клиенте и затем выполнить его. Как показывает практика поддержка такого решения гораздо проще, чем поддержка императивщины на TSQL.

    Но это всё случаи из разряда два процента от всей работы с SQL и подход к ним отдельный. Хотя подумать над тем как генерировать на linq подобные скрипты всё же стоит.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[25]: Nemerle & Real Life
    От: IT Россия linq2db.com
    Дата: 11.04.09 15:32
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Я не пойму о чём ты. О коде, который я сейчас пишу или о коде, который ты потом будешь писать?

    Tom>О коде который ты сейчас пишешь. Провайдер.

    Даже не знаю, никогда не задавался этим вопросом. Сколько получится, столько и будет. Ну может 7-10 тысяч строк наберётся, смотря как считать. В BLToolkit уже многие вещи реализованы, такие как маппинг, БД провайдеры, SqlBuilder тоже имеет отдельную ценность и непонятно нужно его включать в рассмотрение или нет. Сам парсер будет 1,5-2 тыщи строк, всякие полезняшки там. Больше всего кода это всевозможные методы обхода Expression Tree. Код тупой, но никуда не денешься. На Немерле как раз такие вещи было бы делать на порядок проще.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[22]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 11.04.09 15:37
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Хочешь сказать, что поддержка структурной идентичности все же будет в 4.0?

    VD>Я слышал обратное. В прочем я слышал это о C#.

    Я одним глазом глянул. Если я правильно понял, речь идёт о структурной идентичности интерфейсов. Т.е. помечается интерфейс специальными атрибутами и два интерфейса в разных сборках считаются одинаковыми. Нужно для интеропа, чтобы не таскать с собой интеропные офисные сборки по 10 мег, а встраивать в свои сборки только используемые интерфейсы.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[8]: Проблемы организации OR-мапинга
    От: SleepyDrago Украина  
    Дата: 11.04.09 17:40
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Нет. Редактор редактирует только модель. Генератор существует совсем отдельно ...

    SD>>именно это и было сделано. Редактор ооп модели. Вам же в теме показывали листинги "сложных запросов" Чем вы предлагаете их заменить?

    A>Я задачу "генерировать всё" вообще никогда перед собой не ставил. Нет и не может быть удобного универсального генератора для всего. Я ставил задачу сгенерировать 90%, и позволить остальные 10% писать руками

    В общем проясним сразу. Сущности ООП модели — 10% клиентского кода. Они не понятны и неприемлемы ни для dba ни для спецов предметной области. На удивленные возгласы мол если спецы предметной области в софт конторе не знают ооп то могут искать другую работу, ответ очень простой — спецы бесценны, а ооп нет. Это означает что от модели предметной области до решения покрывающего 90% кода тесно связанного с обработкой данных — как до пекина раком. Так что согласны вы с Tom или нет предложить вам ему нечего тк у него основная масса логики в базе. Вариант "просто переписать все на С#/Linq" любым разумным менеджером будет послан, разве что систему будут утилизировать и будет финансирование "с чистого листа".

    зы сорри за прямоту — не со зла, просто это уже съеденные собаки
    Re[9]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 17:44
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    SD>В общем проясним сразу. Сущности ООП модели — 10% клиентского кода. Они не понятны и неприемлемы ни для dba ни для спецов предметной области. На удивленные возгласы мол если спецы предметной области в софт конторе не знают ооп то могут искать другую работу, ответ очень простой — спецы бесценны, а ооп нет. Это означает что от модели предметной области до решения покрывающего 90% кода тесно связанного с обработкой данных — как до пекина раком.


    Стоп, а разве я описываю объектную модель? Вовсе нет. Я описываю сущности. Как может специалист предметной области не разбираться в сущностях?

    SD>Так что согласны вы с Tom или нет предложить вам ему нечего тк у него основная масса логики в базе. Вариант "просто переписать все на С#/Linq" любым разумным менеджером будет послан, разве что систему будут утилизировать и будет финансирование "с чистого листа".


    Систему где бизнес логика в SQL надо переписывать вне зависимости от используемых технологий.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[7]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 18:14
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>"получить конкретный элемент по идентификатору" относится к бизнес-логике, а не к доступу к данным.


    С какой это стати? Осмысливания содержимого элемента и обработки тут нет. Никакая это не бизнес-логика.

    G>Хоть убей не пойму зачем тому же IQueryable учитывать возможность рефакторинга БД.


    IQueryable не надо, надо методике доступа к БД, которая включает в себя Linq.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[10]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 18:34
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Систему где бизнес логика в SQL надо переписывать вне зависимости от используемых технологий.


    Вот тут нельзя не согласиться. Только с одной поправкой не SQL, а в TSQL.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[8]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 19:07
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>"получить конкретный элемент по идентификатору" относится к бизнес-логике, а не к доступу к данным.

    A>С какой это стати? Осмысливания содержимого элемента и обработки тут нет. Никакая это не бизнес-логика.
    Сам факт обработки некоторой выборки уже относится к BL, для DAL достаточно вернуть выборку в удобном для обработки виде.

    G>>Хоть убей не пойму зачем тому же IQueryable учитывать возможность рефакторинга БД.

    A>IQueryable не надо, надо методике доступа к БД, которая включает в себя Linq.
    Linq = IEnumerable\IQueryable + extension methods + anonimous types + object initializers + sql-подобный синтаксис.
    Для полноценной работы с данными не хватает только DML — insert\update\delete.
    Зачем этому всему учитывать возможность рефакторинга БД ?

    Или всетаки имеются ввиду конкретные реализации Linq-провайдеров: схемы маппинга, кеширования и прочего?
    Так они вообще-то мало зависят от самого Linq.
    Re[27]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 19:25
    Оценка:
    Здравствуйте, dotneter, Вы писали:

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


    VD>>То и значит. Нет полей. Нет "структуры".

    D>Тоесть для интерфейса понятие структурной эквивалентности не применимо?

    Естественно. У них интерфейсная эквивалентность.
    Интерфейсно эквивалентными могут быть два разных типа.
    Просто теперь интерфейсная эквивалентность будет работать и для разных интерфейсов имеющих один гуид, и одинаковую сигнатуру. Сделано это для интеропа и для плагинов.

    D>нельзя назвать эквивалентностью интерфейсов?


    Можно. Но именно интерфейсов, а не структуры типа.

    D>Можно тогда какой нибудь пример применения этой самой структурной эквивалентности?


    Вот если бы можно было бы написать что-то воде:
    struct A { int a; }
    struct B { int a; }
    A a = new A();
    B b = a;

    То была бы структурная эквивалентность.

    Причем для именованных типов это особо и не нужно. А вот для анонимных нужно и очень.

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

    VD>>Крут ты! Я вот не знаю как такое сделать, да еще чтобы при этом не пересечься с гуидами сгенерированными другими средствами.

    D>Ну а чего, для IValue берем строку вида "int,Value" и генерим по ней Guid, дешево и сердито.

    Здорово. Только вот в Guid 128 бит. Что будем делать если встретятся описания которые больше 128 бит в запакованном виде?
    И что будем делать если один из гуидов пересечется с тем, что был сгенерирован как обычный гуид?

    В общем, это не решение.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[26]: Nemerle & Real Life
    От: Tom Россия http://www.RSDN.ru
    Дата: 11.04.09 19:25
    Оценка:
    IT>Но это всё случаи из разряда два процента от всей работы с SQL и подход к ним отдельный. Хотя подумать над тем как генерировать на linq подобные скрипты всё же стоит.
    Хорошо, пункт один — императивная логика. Мне правда пока не совсем понятно почему в TSQL её лучше не использовать, но возможно позже понимание придёт. Что ещё можно сделать что бы улучшить этот код. Влад например предлагал устранить временные таблицы и курсоры. насчёт курсоров конечно понятно что лучше без них. Насчёт временных таблиц я пока не уверен что тотальное их устранение улучшит понимание кода.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[27]: Nemerle & Real Life
    От: Tom Россия http://www.RSDN.ru
    Дата: 11.04.09 19:25
    Оценка:
    G>3)Врмененные таблицы позаменять на табличные переменные
    А чем это улучшит код?

    G>4)Для получения значений #tz можно использовать table-valued function

    Не понял четно говоря.

    G>Желательно отказаться от операторов IF ELSE в TSQL коде и перенести выбор в клиентский код.

    Обьясните почему? Почему в C# ты от if не отказываешься а в TSQL решаешь отказаться? Просто что бы уменьшить обьём кода в функции?

    G>Если ко времени окончания рефакторинга появится DML для Linq, то можно поотказываться от фунцкий и динамически строить запросы с помощью Linq, а потом передавать нужные значения в INSERT и UPDATE.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[23]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 19:27
    Оценка:
    Здравствуйте, IT, Вы писали:

    VD>>Хочешь сказать, что поддержка структурной идентичности все же будет в 4.0?

    VD>>Я слышал обратное. В прочем я слышал это о C#.

    IT>Я одним глазом глянул.


    Я тоже.

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


    У интерфейсов нет стуктуры. Они потому так и называются "интерфейс". Толку с интерфейсов в данном случае — нет. Мы же не об интеропе говорим.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[9]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 19:34
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Рама, забудь свои знания С. Они тут тебе не помогут.

    VD>"Запись", о которой я говорил — это тип данных, а не понятие из РСУБД (где, впрочем они рассматриваются так же, прост ты не привык). Запись есть набор разнотипных именованных значений. Скажем в C# 3.0 ей аналогичны анонимные типы. Не полностью аналогичны, правда... с ограничениями... но все же для возврата значений из БД анонимных типов более чем достаточно.

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

    VD>Так что нет никаких "частей записи". Это и есть запись. Только другая. Запрос просто преобразует набор одних записей (возможно даже множество наборов) в другой набор других записей.


    Да в том то всё и дело что часть, потому что одна возвращённая запись влияет (отображается) на несколько объектов C#.

    A>>Я ответил выше — результаты запроса никак не могут быть связаны с типом C#, попросту не хватает информации.

    VD>Очень смешно!

    Да нет, весьма грустно.

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


    Проблема, по той простой причине, что одному типу C# может соответствовать не одна таблица БД, и напротив одна таблица может содержать данные для разных типов C#. Если ты не придумал искуственный интеллект, то проблема не решена.

    VD>С удовольствием послушаю обоснование. Особенно это интересно в контексте linq.


    Linq не работает не с бизнес-сущностями, а с DTO.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[28]: Nemerle & Real Life
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 19:45
    Оценка:
    Здравствуйте, Tom, Вы писали:

    G>>3)Врмененные таблицы позаменять на табличные переменные

    Tom>А чем это улучшит код?
    Никак, это типа best-practicies.
    Хотя в сочетании с table parameters (MS SQL 2008) можно получить функционально чистое решение даже на TSQL.

    G>>Желательно отказаться от операторов IF ELSE в TSQL коде и перенести выбор в клиентский код.

    Tom>Обьясните почему? Почему в C# ты от if не отказываешься а в TSQL решаешь отказаться? Просто что бы уменьшить обьём кода в функции?
    Чтобы уменьшить сложность TSQL кода. Править C# гораздо проще, чем TSQL.
    Кроме того к разными веткам IF в SQL могут приводить совершенно разные сценарии в программе.
    Re[28]: Nemerle & Real Life
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 19:48
    Оценка:
    Здравствуйте, Tom, Вы писали:

    G>>Желательно отказаться от операторов IF ELSE в TSQL коде и перенести выбор в клиентский код.

    Tom>Обьясните почему? Почему в C# ты от if не отказываешься а в TSQL решаешь отказаться? Просто что бы уменьшить обьём кода в функции?

    Поддержка и развитие кода на T-SQL дороже. Вынеся логику в C#, съэкономишь в будущем много времени.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[11]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 20:10
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Анонимные типы, очень хорошая аналогия, только пользы от них в данном случае никакой нет. Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести.

    G>Это решется с помощью метаданных. Причем метаданные могут быть выведены автоматически (следующая версия EF это будет уметь)

    А откуда они возьмуться? Дай угадаю, надо указывать вручную...

    A>>Да в том то всё и дело что часть, потому что одна возвращённая запись влияет (отображается) на несколько объектов C#.

    G>Что значит влияет?

    Например, у тебя есть отношение N<->M между сущностями А и В. У экземпляра класса A есть метод GetRelatedBs(), а у экземпляра класса B — GetRelatedAs() (не объязательно у них самих, возможно у внешних манипуляторов). Очевидно чтение таблицы A2B_Mapping влияет на экземпляры обоих типов. То есть тут вообще довольно хреновая ситуация, чтение этой таблицы вообще не связано с созданием новых экземпляров, только с модицикацией существующих. Читать таблицу именно как серию запросов GetRelatedX плохо по соображениям производительности.

    G>Это проблема решается явным указанием того что надо получить. Ведь даже когда пишешь обычную строчку с SQL кодом представляешь себе что хочешь получить, вот и коде на C# надо указывать.


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

    VD>>>С удовольствием послушаю обоснование. Особенно это интересно в контексте linq.

    A>>Linq не работает не с бизнес-сущностями, а с DTO.
    G>Linq работает с данными, или с записями если угодно (одно и тоже). DTO — костыль для изначально хреновой жирной модели.

    Тем не менее, с бизнес-сущностями Linq не работает и то что возвращает Linq всё равно надо пересобирать.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[12]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 20:30
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Анонимные типы, очень хорошая аналогия, только пользы от них в данном случае никакой нет. Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести.

    G>>Это решется с помощью метаданных. Причем метаданные могут быть выведены автоматически (следующая версия EF это будет уметь)
    A>А откуда они возьмуться? Дай угадаю, надо указывать вручную...

    Для любых метаданных есть 3 варианта (в порядке удобства использования)
    1)Сограшения — отсуствие явного задания метаданных
    2)Метаданные в коде (атрибуты в .NET)
    3)Внешние метаданные

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

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

    A>>>Да в том то всё и дело что часть, потому что одна возвращённая запись влияет (отображается) на несколько объектов C#.

    G>>Что значит влияет?

    A>Например, у тебя есть отношение N<->M между сущностями А и В. У экземпляра класса A есть метод GetRelatedBs(), а у экземпляра класса B — GetRelatedAs() (не объязательно у них самих, возможно у внешних манипуляторов). Очевидно чтение таблицы A2B_Mapping влияет на экземпляры обоих типов. То есть тут вообще довольно хреновая ситуация, чтение этой таблицы вообще не связано с созданием новых экземпляров, только с модицикацией существующих. Читать таблицу именно как серию запросов GetRelatedX плохо по соображениям производительности.

    Я уже давно пользуюсь EF, у меня таких проблем нет.

    G>>Это проблема решается явным указанием того что надо получить. Ведь даже когда пишешь обычную строчку с SQL кодом представляешь себе что хочешь получить, вот и коде на C# надо указывать.

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

    Кроме того пометки по коду не разрабрасываются, а собираются в объекте-контексте.

    VD>>>>С удовольствием послушаю обоснование. Особенно это интересно в контексте linq.

    A>>>Linq не работает не с бизнес-сущностями, а с DTO.
    G>>Linq работает с данными, или с записями если угодно (одно и тоже). DTO — костыль для изначально хреновой жирной модели.
    A>Тем не менее, с бизнес-сущностями Linq не работает и то что возвращает Linq всё равно надо пересобирать.
    Вы думаете что вам надо пересобирать от этого и проблемы, другие ничего не пересобирают и живут счастливо.
    Re[28]: Проблемы организации OR-мапинга
    От: dotneter  
    Дата: 11.04.09 20:32
    Оценка:
    Здравствуйте, VladD2, Вы писали:


    VD>Тогда можно было бы просто объявить два разных анонимных типа в разных сборках и использовать их не думая где был объявлен какой переменной.


    А что мешает оперировать интерфейсами? К каждому генерящемуся анонимному типу генерить еще и интерфейс который он реализует и если работать с интерфейсами то нас не волнует в какой сборке они были объявлены.

    struct A:Ia1 { int a{get;set;} }
    struct B:Ia2 { int a{get;set;} }
    Ia1 a = new A();
    Ia2 b = a;

    VD>Здорово. Только вот в Guid 128 бит. Что будем делать если встретятся описания которые больше 128 бит в запакованном виде?
    VD>И что будем делать если один из гуидов пересечется с тем, что был сгенерирован как обычный гуид?
    Гуид можно сгенерировать для строки любой длинны. А то что он не является уникальным и с чем то может пересекатся зависит от того какие требования на него наложены, может там достаточно что бы у интерфейсов с одинаковой структурой были иденичные гуиды а все остальное не важно.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
    Talk is cheap. Show me the code.
    Re[12]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 20:37
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Так, ещё раз. Если я говорю "Найди мне клиента по имени Иван" (FindByFirstName), а Вани нет, то это нормальная ситуация. Если я говорю, "верни мне клиента с идентификатором {356F893B-68B3-4687-906B-0A50DD1612C1}" (GetById), а клиента с таким идентификатором нет, то что-то очень серьёзно не так, потому что нарушена целостность данных. Например, заказ ссылается на клиента через идентификатор, а клиента с таким идентификатором нет.

    G>>Это ты описываешь уже сильно высокоуровневую логику по сравнению с доставанием данных из БД.

    A>Это тот уровень, с которым надо работать из BL.

    Можете так думать, будете только усложнять себе жизнь.

    A>>>Сохранение ссылочной целостности данных в компетенции DAL. Нельзя стирать клиента на которого оформлены заказы.

    G>>А я думал это в компетенции БД.
    A>ИМХО ты путаешь DAL и ORM. Как бы то ни было, целостность данных должна поддерживаться уровнем ниже BL.
    Ниче не понял. Причем тут DAL и ORM ? БД — уровень ниже BL?

    A>>>Поэтому GetById, если ничего не найдено, выкидывает исключение.

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

    G>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).

    A>QueryObject нужен для нетипичных запросов, типа запросов для отчётов.
    А кто мешает GetById написать через тот же QueryObject ? Вам ведь все равно писать запрос придется.

    A>Использовать его для всего подряд просто неправильно.

    А обоснования? (рассказываю секрет: IQueryable реализует именно такую абстракцию)
    Re[13]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 20:43
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Для любых метаданных есть 3 варианта (в порядке удобства использования)

    G>1)Сограшения — отсуствие явного задания метаданных
    G>2)Метаданные в коде (атрибуты в .NET)
    G>3)Внешние метаданные
    G>Внешние метаданные могут как прописываться вручную, так и генерироваться с помощью утилит.
    G>С БД появляются некоторые особенности, так как сама БД предоставляет немалый функционал, то слабые средства вывода метаданных из соглашений и атрибутов не позволяют использовать многие возможности БД. Поэтому чаще всего применяются внешние метаданные.
    G>Кроме того эти самые внешние метаданные могут быть использоваы для генерации схемы хранения.

    Получается левой рукой правое ухо. На основе формального описания генерировать внешние метаданные на основе которых генерировать C# код ис хему БД. Проще и правильнее генерировать сразу код и схему БД на основе формального описания.

    A>>Вот, об этом я и говорю. Тут пометили руками, там пометили. В итоге куча разбросанных по всему коду пометок. Не хорошо это.

    G>Почему? Думаешь отсутствие таких пометок лучше?

    Думаю, лучше внешние метаданные.

    G>Все равно программист в каждом месте знает о типе записей выборки, которую он хочет получить.


    Откуда знает, помнит?

    G>Кроме того пометки по коду не разрабрасываются, а собираются в объекте-контексте.


    А так как объхектов много, то всё же разбрасываются.

    A>>Тем не менее, с бизнес-сущностями Linq не работает и то что возвращает Linq всё равно надо пересобирать.

    G>Вы думаете что вам надо пересобирать от этого и проблемы, другие ничего не пересобирают и живут счастливо.

    Выше я про M<->N уже написал. Пересобирать таки надо.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[13]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 20:48
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Это тот уровень, с которым надо работать из BL.

    G>Можете так думать, будете только усложнять себе жизнь.

    Ну а альтернатива какая? Усложнить BL введя логику обработки повреждённых данных? Что-то не впечатляет.

    A>>ИМХО ты путаешь DAL и ORM. Как бы то ни было, целостность данных должна поддерживаться уровнем ниже BL.

    G>Ниче не понял. Причем тут DAL и ORM ? БД — уровень ниже BL?

    БД, уровень, безусловно ниже BL.

    A>>Если ничего не найдено GetById, то нарушена целостность данных. Это такая попа, что тут даже исключения мало.

    G>Почему? Какая разница методу GetById почему его вызвали с Id которого нет в базе?

    Разница такая, что его не имеют права вызывать с Id которого нет в базе. Если подобное случилось, значит где-то баг, который надо исправить.

    A>>Использовать его для всего подряд просто неправильно.

    G>А обоснования? (рассказываю секрет: IQueryable реализует именно такую абстракцию)

    Ты всегда приводишь IQueryable как обоснование своей позиции
    Открою секрет — в базе данных есть индексы. Нельзя одинаково эффективно выполнять выборку по разным условиям. Поэтому, надо явно выделять эффективные случаи в специализированные методы доступа. Если этого не делать, получается абсолютно некотроллируемый рост похожих запросов. Оптимизировать базу под все из них невозможно, а если подумать, все и не нужны вовсе. Только вот в твоём варианте, какие лучше нигде в интерфейсе DAL не светится.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[14]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 20:53
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Для любых метаданных есть 3 варианта (в порядке удобства использования)

    G>>1)Сограшения — отсуствие явного задания метаданных
    G>>2)Метаданные в коде (атрибуты в .NET)
    G>>3)Внешние метаданные
    G>>Внешние метаданные могут как прописываться вручную, так и генерироваться с помощью утилит.
    G>>С БД появляются некоторые особенности, так как сама БД предоставляет немалый функционал, то слабые средства вывода метаданных из соглашений и атрибутов не позволяют использовать многие возможности БД. Поэтому чаще всего применяются внешние метаданные.
    G>>Кроме того эти самые внешние метаданные могут быть использоваы для генерации схемы хранения.

    A>Получается левой рукой правое ухо. На основе формального описания генерировать внешние метаданные на основе которых генерировать C# код ис хему БД. Проще и правильнее генерировать сразу код и схему БД на основе формального описания.


    А почему формальное описание не может служить метаданными?

    A>>>Вот, об этом я и говорю. Тут пометили руками, там пометили. В итоге куча разбросанных по всему коду пометок. Не хорошо это.

    G>>Почему? Думаешь отсутствие таких пометок лучше?
    A>Думаю, лучше внешние метаданные.
    Внешние метаданные — самые неудобные в использовании в программе, указание типа — является своего рода метаданными в коде.
    Кстати при наличии внешних метаданных можно аннотации типов сгенерировать (что собственно и делается).

    G>>Все равно программист в каждом месте знает о типе записей выборки, которую он хочет получить.

    A>Откуда знает, помнит?
    Хорошо если помнит, иначе ему придется реверсить то что понаписано. В этом собственно и заключается основная проблема при работе с SQL.
    DAL в виде GetByIi, GetAll и прочих методов создается как раз чтобы сконцентрировать этот sacral knoweledge в одном месте. Это позволяет программисту понимать что происходит, но не дает никаких гарантий (не проверяется при компиляции).

    G>>Кроме того пометки по коду не разрабрасываются, а собираются в объекте-контексте.

    A>А так как объхектов много, то всё же разбрасываются.
    Да ну? Объект-контекст — один (ну максимум два) и генерируется автоматически.

    A>>>Тем не менее, с бизнес-сущностями Linq не работает и то что возвращает Linq всё равно надо пересобирать.

    G>>Вы думаете что вам надо пересобирать от этого и проблемы, другие ничего не пересобирают и живут счастливо.
    A>Выше я про M<->N уже написал. Пересобирать таки надо.
    Это вы так думаете. Мне например ничего пересобирать ни разу не приходилось.
    Re[15]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 20:58
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Получается левой рукой правое ухо. На основе формального описания генерировать внешние метаданные на основе которых генерировать C# код ис хему БД. Проще и правильнее генерировать сразу код и схему БД на основе формального описания.

    G>А почему формальное описание не может служить метаданными?

    А тогда о чём ты споришь? Я именно это с самого начала и предлагаю.

    G>Внешние метаданные — самые неудобные в использовании в программе, указание типа — является своего рода метаданными в коде.

    G>Кстати при наличии внешних метаданных можно аннотации типов сгенерировать (что собственно и делается).

    Внешние метанданные неудобные если служат для конфигурации программы, а не для её генерации.

    G>DAL в виде GetByIi, GetAll и прочих методов создается как раз чтобы сконцентрировать этот sacral knoweledge в одном месте. Это позволяет программисту понимать что происходит, но не дает никаких гарантий (не проверяется при компиляции).


    Вот. А если использовать генерацию кода, то вероятность рассинхронизации названия и смысла падает до нуля.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[29]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 21:11
    Оценка:
    Здравствуйте, dotneter, Вы писали:

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



    VD>>Тогда можно было бы просто объявить два разных анонимных типа в разных сборках и использовать их не думая где был объявлен какой переменной.


    D>А что мешает оперировать интерфейсами? К каждому генерящемуся анонимному типу генерить еще и интерфейс который он реализует и если работать с интерфейсами то нас не волнует в какой сборке они были объявлены.


    А смысл? Основные функции записей — это сравнение и копирование. Как этому помогут интерфейсы?
    Да и опять же сгенерировать одинаковые гуиды для одинаковых записей нельзя.

    VD>>Здорово. Только вот в Guid 128 бит. Что будем делать если встретятся описания которые больше 128 бит в запакованном виде?

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

    Это нонсенс.

    D>А то что он не является уникальным и с чем то может пересекатся зависит от того какие требования на него наложены,


    Требование одно. Структурная идентичность. Гуиды должны совпадать только у тех типов которые структурно идентичны.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 21:17
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Получается левой рукой правое ухо. На основе формального описания генерировать внешние метаданные на основе которых генерировать C# код ис хему БД. Проще и правильнее генерировать сразу код и схему БД на основе формального описания.

    G>>А почему формальное описание не может служить метаданными?

    A>А тогда о чём ты споришь? Я именно это с самого начала и предлагаю.

    Так оно и так используется (в Linq2SQL сейчас есть, в EF будет), правда в ограниченном объеме.

    G>>Внешние метаданные — самые неудобные в использовании в программе, указание типа — является своего рода метаданными в коде.

    G>>Кстати при наличии внешних метаданных можно аннотации типов сгенерировать (что собственно и делается).
    A>Внешние метанданные неудобные если служат для конфигурации программы, а не для её генерации.
    Генерация по метаданным — способ победить некоторые неудобства.
    Например контексты Linq2SQL и EF можно использовать без генератора.

    G>>DAL в виде GetByIi, GetAll и прочих методов создается как раз чтобы сконцентрировать этот sacral knoweledge в одном месте. Это позволяет программисту понимать что происходит, но не дает никаких гарантий (не проверяется при компиляции).

    A>Вот. А если использовать генерацию кода, то вероятность рассинхронизации названия и смысла падает до нуля.
    Это нужно очень крутое описание чтобы сгенерировать кучу методов GetById, GetAll, FindByDickLength итп.
    Re[15]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 21:17
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Так и пусть целостность данных на уровне БД будет, и не надо BL усложнять. И волки сыты и овцы — целки.


    Если ты позволяешь GetById возвращать null, ты усложняешь BL обработкой этого случая либо скрываешь ошибку необработкой.

    A>>Разница такая, что его не имеют права вызывать с Id которого нет в базе. Если подобное случилось, значит где-то баг, который надо исправить.

    G>Почему не имеют? Это же просто метод доступа к данным, какая вообще разница зачем его вызывают? Как обрабаотывать случай отсутсвия в базе записи с нужным ID — уже дело BL, причем способ обработки сильно зависит от варианта использования.

    BL не должен содержать код обработки нецелостных данных.

    A>>Открою секрет — в базе данных есть индексы. Нельзя одинаково эффективно выполнять выборку по разным условиям. Поэтому, надо явно выделять эффективные случаи в специализированные методы доступа.

    G>Вау, оказывается DAL — это premature optimization для работы с БД?

    Нет. Но DAL не может состоять из одного только метода Query.

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

    G>А под все оптимизировать и не надо, надо только под тормозящие. Для этого профайлер в зубы и смотрим, обычно в программе меньше пяти Особо Торозящих Запросов.

    Тормозящие понятие относительное. Ты этоо измеряешь, может, в секундах, а я сталкивался с творениями любителей HQL и прочих "вкусностей", которые так сильно тормозили, что приходилось менять бизнес-процессы. Оптимальные запросы должны быть выделены. Это не прихоть, а практическая необходимость.

    A>>Только вот в твоём варианте, какие лучше нигде в интерфейсе DAL не светится.

    G>Не надо преждевременной оптимизацие заниматься.

    Она не преждевременная, так как схема БД (включая индексы) уже есть.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[17]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 21:21
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>>>А почему формальное описание не может служить метаданными?

    A>>А тогда о чём ты споришь? Я именно это с самого начала и предлагаю.
    G>Так оно и так используется (в Linq2SQL сейчас есть, в EF будет), правда в ограниченном объеме.

    Нет, это генерация run-time или одноразовая типа add reference. Я о compile-time генерации говорю.

    G>Это нужно очень крутое описание чтобы сгенерировать кучу методов GetById, GetAll, FindByDickLength итп.


    Вовсе нет. Достаточно уметь генерировать все типичные методы. Нетипичные, это либо попытка запихать логику в БД и надо от этого избавляться, либо разного рода отчёты и с этим справится Query Object.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[16]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 21:28
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Так и пусть целостность данных на уровне БД будет, и не надо BL усложнять. И волки сыты и овцы — целки.


    A>Если ты позволяешь GetById возвращать null, ты усложняешь BL обработкой этого случая либо скрываешь ошибку необработкой.

    Я этого не предлагаю. Я предлагаю возвращать выборку, а уже BL уже будет обработка случая пустой выборки — это супер-мега ошибка или нормальный случай. Код будет такой же, только переедет на тот уровень где ему положено обитать. DAL в этом случае упростится.
    Так что все будут в выйгрыше.

    A>>>Разница такая, что его не имеют права вызывать с Id которого нет в базе. Если подобное случилось, значит где-то баг, который надо исправить.

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

    A>>>Открою секрет — в базе данных есть индексы. Нельзя одинаково эффективно выполнять выборку по разным условиям. Поэтому, надо явно выделять эффективные случаи в специализированные методы доступа.

    G>>Вау, оказывается DAL — это premature optimization для работы с БД?
    A>Нет.
    Почему? предыдущее сообщение показывает обратное.

    A>Но DAL не может состоять из одного только метода Query.

    Да, нужны еще update, insert, delete. Этого достаточно.

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

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

    A>>>Только вот в твоём варианте, какие лучше нигде в интерфейсе DAL не светится.

    G>>Не надо преждевременной оптимизацие заниматься.
    A>Она не преждевременная, так как схема БД (включая индексы) уже есть.
    Ага, значит кто-то до вас уже соптимизировал БД
    Re[12]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 21:32
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>...Читать таблицу именно как серию запросов GetRelatedX плохо по соображениям производительности.


    Ром. Попробуй встяхнуть головой и представить, что можно жить без методов GetRelatedX вообще. Вместо этого можно прямо в запросе использовать JOIN.

    У тебя же нет проблем при вынимании аналогичных данных средствами SQL в БД? Ну, а откуда же они берутся когда запрос становится описанным в ООЯ вроде C#?

    A>Вот, об этом я и говорю. Тут пометили руками, там пометили. В итоге куча разбросанных по всему коду пометок. Не хорошо это.


    Не пометил, а указал. Написал: ...select new { c.Name, c.Amount } и получил только два нужных поля.

    Ты вообще, linq-ом то пользовался?

    A>Тем не менее, с бизнес-сущностями Linq не работает и то что возвращает Linq всё равно надо пересобирать.


    А надо? Зачем вообще эти бизнес-сущности. Тебе данные надо обрабатывает или об объектах думать?

    Зачем тебе вообще нужны объекты для хранения данных вынутых из БД?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 21:33
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>То что кто-то написал хреновый запрос является аргументом?


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

    A>>Она не преждевременная, так как схема БД (включая индексы) уже есть.

    G>Ага, значит кто-то до вас уже соптимизировал БД

    Просто создал. На самом деле всё гораздо хуже. Если в результате оптимизации какие-то индексы будут убраны, то какие-то запросы перестанут быть супербыстрыми и спецметоды для них больше не будут генерироваться. Таким образом о проблеме я узнаю не тогда, когда позвонит клиент и скажет, что начало тормозить то, что раньше не тормозило, а на этапе компиляции.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[27]: Nemerle & Real Life
    От: IT Россия linq2db.com
    Дата: 11.04.09 21:33
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Ну почему же, приведенный кусок го... TSQLя можно и отрефакторить.


    Это называется переписать
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[18]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 21:33
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>>>А почему формальное описание не может служить метаданными?

    A>>>А тогда о чём ты споришь? Я именно это с самого начала и предлагаю.
    G>>Так оно и так используется (в Linq2SQL сейчас есть, в EF будет), правда в ограниченном объеме.

    A>Нет, это генерация run-time или одноразовая типа add reference. Я о compile-time генерации говорю.

    О генерации чего вы сейчас говорите?

    G>>Это нужно очень крутое описание чтобы сгенерировать кучу методов GetById, GetAll, FindByDickLength итп.

    A>Вовсе нет. Достаточно уметь генерировать все типичные методы. Нетипичные, это либо попытка запихать логику в БД и надо от этого избавляться, либо разного рода отчёты и с этим справится Query Object.
    Критерий "типичности" метода в студию.
    Re[16]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 21:39
    Оценка:
    Здравствуйте, adontz, Вы писали:

    G>>DAL в виде GetByIi, GetAll и прочих методов создается как раз чтобы сконцентрировать этот sacral knoweledge в одном месте. Это позволяет программисту понимать что происходит, но не дает никаких гарантий (не проверяется при компиляции).


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


    Тебе намекают, что все эти GetById и GetAll — просто не нужны, если есть возможность использовать типизированные запросы прямо в языке на котором описывается бизнес-логика. И DAL как таковой не нужен, так как срывать становится не чего.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 21:40
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>То что кто-то написал хреновый запрос является аргументом?

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

    A>>>Она не преждевременная, так как схема БД (включая индексы) уже есть.

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

    Само наличие индектов еще не сделает запрос супербыстрым.

    Кстати как будете обеспечивать синхронность базы и кода у клиента? Вдруг "грамотный" админ залезет в базу и грохнет индекс?
    Re[16]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 21:46
    Оценка:
    Здравствуйте, MozgC, Вы писали:

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


    Предположим... У нас есть веб-страничка в которой список тем. Ты хочешь прочесть тело сообщения, но сообщение к этому времени уже удалил модератор. Что тут исключительного?

    Почему нельзя сделать метод или запрос который просто вернет некий признак отсутствия данных?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[13]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 21:48
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Ром. Попробуй встяхнуть головой и представить, что можно жить без методов GetRelatedX вообще. Вместо этого можно прямо в запросе использовать JOIN.

    VD>У тебя же нет проблем при вынимании аналогичных данных средствами SQL в БД? Ну, а откуда же они берутся когда запрос становится описанным в ООЯ вроде C#?

    JOIN тут никак не поможет. Объясняю данный пример подробно. Есть таблицы А и B вида
    id | name
     1 | first
     2 | second
     3 | third

    а так же таблица A2B вида
    aId | dId
      1 |   1
      1 |   2
      2 |   1
      2 |   3
      3 |   1
      3 |   5

    Если читать её не целиком, а кусками (не важно по aID будет выборка или по bID) ты в самом лучшем случае замедлишь всё в O(ln(n)) раз.

    A>>Вот, об этом я и говорю. Тут пометили руками, там пометили. В итоге куча разбросанных по всему коду пометок. Не хорошо это.

    VD>Не пометил, а указал. Написал: ...select new { c.Name, c.Amount } и получил только два нужных поля.
    VD>Зачем тебе вообще нужны объекты для хранения данных вынутых из БД?

    Затем чтобы, например, прибайндить IBindingList<мои объекты> сразу в несколько View. И чтобы они обновлялись нормально, без "паркинсона" на кнопке F5, а для этого, кстати, нужен INotifyPropertyChanged и вообще много разных мелких инфраструктурных штучек. А ещё, могу захотеть кешировать, причём даже не весь объект, а его часть. Если чтение производится где попало через Query, мне это вряд ли удасться сделать.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[27]: Nemerle & Real Life
    От: IT Россия linq2db.com
    Дата: 11.04.09 21:49
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Хорошо, пункт один — императивная логика. Мне правда пока не совсем понятно почему в TSQL её лучше не использовать, но возможно позже понимание придёт.


    Отладка. Если есть проблема, то пройтись по шагам по такой логике будет проблематично. Если же SQL генерируется, то в конце концов ты получаешь один единственный скрипт, который можно прогнать и увидеть есть ли в нём проблемы.

    Tom>Что ещё можно сделать что бы улучшить этот код. Влад например предлагал устранить временные таблицы и курсоры. насчёт курсоров конечно понятно что лучше без них. Насчёт временных таблиц я пока не уверен что тотальное их устранение улучшит понимание кода.


    Временные таблицы точно также затрудняют анализ скрипта, но с ними всё же как-то можно бороться.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[9]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 11.04.09 21:52
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    SD>Так что согласны вы с Tom или нет предложить вам ему нечего тк у него основная масса логики в базе. Вариант "просто переписать все на С#/Linq" любым разумным менеджером будет послан, разве что систему будут утилизировать и будет финансирование "с чистого листа".


    Тому самому себе предложить нечего. Легаси код нужно прежде всего завернуть в новые обёртки и как раз здесь ему всё давно предложили.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[19]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 21:52
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Нет, это генерация run-time или одноразовая типа add reference. Я о compile-time генерации говорю.

    G>О генерации чего вы сейчас говорите?

    Как схемы БД, так и кода для работы с БД. Да, вот забыл упомянуть, что делать с row level security? Боюсь, если хранимки не генерировать, будет беда.

    G>>>Это нужно очень крутое описание чтобы сгенерировать кучу методов GetById, GetAll, FindByDickLength итп.

    A>>Вовсе нет. Достаточно уметь генерировать все типичные методы. Нетипичные, это либо попытка запихать логику в БД и надо от этого избавляться, либо разного рода отчёты и с этим справится Query Object.
    G>Критерий "типичности" метода в студию.

    Строго формального критерия нет. Практически все Insert/Update/Delete типичные. Есть исключения, но они крайне редки. Выборки, если это Select All или Select by Foreign Key, тоже типичные.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[28]: Nemerle & Real Life
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 11.04.09 21:53
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Временные таблицы точно также затрудняют анализ скрипта, но с ними всё же как-то можно бороться.

    Вообще временные таблицы иногда могут помочь упростить запрос.
    Re[14]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 21:55
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>JOIN тут никак не поможет. Объясняю данный пример подробно. Есть таблицы А и B вида

    A>
    A>id | name
    A> 1 | first
    A> 2 | second
    A> 3 | third
    A>

    A>а так же таблица A2B вида
    A>
    A>aId | dId
    A>  1 |   1
    A>  1 |   2
    A>  2 |   1
    A>  2 |   3
    A>  3 |   1
    A>  3 |   5
    A>

    A>Если читать её не целиком, а кусками (не важно по aID будет выборка или по bID) ты в самом лучшем случае замедлишь всё в O(ln(n)) раз.
    А с какой целью её читать вообще?

    A>>>Вот, об этом я и говорю. Тут пометили руками, там пометили. В итоге куча разбросанных по всему коду пометок. Не хорошо это.

    VD>>Не пометил, а указал. Написал: ...select new { c.Name, c.Amount } и получил только два нужных поля.
    VD>>Зачем тебе вообще нужны объекты для хранения данных вынутых из БД?

    A>Затем чтобы, например, прибайндить IBindingList<мои объекты> сразу в несколько View. И чтобы они обновлялись нормально, без "паркинсона" на кнопке F5, а для этого, кстати, нужен INotifyPropertyChanged и вообще много разных мелких инфраструктурных штучек. А ещё, могу захотеть кешировать, причём даже не весь объект, а его часть. Если чтение производится где попало через Query, мне это вряд ли удасться сделать.

    View, f5... надеюсь это не о вебе.
    Re[17]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 11.04.09 21:55
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Предположим... У нас есть веб-страничка в которой список тем. Ты хочешь прочесть тело сообщения, но сообщение к этому времени уже удалил модератор. Что тут исключительного?

    VD>Почему нельзя сделать метод или запрос который просто вернет некий признак отсутствия данных?

    Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.
    Вообще так можно про все сказать "что тут исключительного". К примеру пытаемся прочитать файл, а такого файла нет (его уже пользователь удалил), ну а что тут исключительного, давайте признак возвращать.
    Re[19]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 21:55
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Само наличие индектов еще не сделает запрос супербыстрым.


    Зная какие есть индексы, можно предсказать какие выборки будут супербыстрыми. Никакой магиитут нет.

    G>Кстати как будете обеспечивать синхронность базы и кода у клиента? Вдруг "грамотный" админ залезет в базу и грохнет индекс?


    А что, ваш метод защищает от "грамотного" админа? Да и вообще, насколько актуальна эта проблема?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[17]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 21:59
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Предположим... У нас есть веб-страничка в которой список тем. Ты хочешь прочесть тело сообщения, но сообщение к этому времени уже удалил модератор. Что тут исключительного?


    Сам факт модерирования исключителен

    VD>Почему нельзя сделать метод или запрос который просто вернет некий признак отсутствия данных?


    По-моему, в твоём примере налицо race condition. Надо либо запретить удалять из базы данных (я за этот метод), а только помечать сообщение как удалённое, либо смириться с тем что DAL кинет исключение, потому что блокировать ресурс-сообщение нельзя. В BL его можно обработать, а можно даже не обрабатывать. В конце концов я могу прямо в URL вбить номер несуществующего сообщения.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[20]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 21:59
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Нет, это генерация run-time или одноразовая типа add reference. Я о compile-time генерации говорю.

    G>>О генерации чего вы сейчас говорите?

    A>Как схемы БД, так и кода для работы с БД. Да, вот забыл упомянуть, что делать с row level security? Боюсь, если хранимки не генерировать, будет беда.

    тогда метаинформация нужна по мощности сравнимая с SQL, такое могут еще нескоро придумать. Может быть MSовский Oslo таким будет.
    Re[10]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 11.04.09 22:01
    Оценка:
    Здравствуйте, adontz, Вы писали:

    G>>Сам факт обработки некоторой выборки уже относится к BL, для DAL достаточно вернуть выборку в удобном для обработки виде.


    A>Так, ещё раз. Если я говорю "Найди мне клиента по имени Иван" (FindByFirstName), а Вани нет, то это нормальная ситуация. Если я говорю, "верни мне клиента с идентификатором {356F893B-68B3-4687-906B-0A50DD1612C1}" (GetById), а клиента с таким идентификатором нет, то что-то очень серьёзно не так, потому что нарушена целостность данных. Например, заказ ссылается на клиента через идентификатор, а клиента с таким идентификатором нет. Сохранение ссылочной целостности данных в компетенции DAL. Нельзя стирать клиента на которого оформлены заказы. Поэтому GetById, если ничего не найдено, выкидывает исключение. Про orphan records слышал?


    Это нормальная/ненормальная ситуация не для БД и даже не для DAL, а для гораздо более высокоуровневой логики.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[20]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 22:04
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Само наличие индектов еще не сделает запрос супербыстрым.

    A>Зная какие есть индексы, можно предсказать какие выборки будут супербыстрыми. Никакой магиитут нет.
    Нельзя в принципе. Даже сама СУБД не умеет так.
    Думаешь почему есть Estimated Execution Plan, а есть реальный план исполнения запроса?

    Пожно только предположить, а это как раз преждевременная оптимизация, которая ни к чему хорошему не ведет.

    G>>Кстати как будете обеспечивать синхронность базы и кода у клиента? Вдруг "грамотный" админ залезет в базу и грохнет индекс?

    A>А что, ваш метод защищает от "грамотного" админа? Да и вообще, насколько актуальна эта проблема?
    Мой метод не защищает, и не дает иллюзию защиты, в отличие от ...
    Re[12]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 11.04.09 22:06
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    A>>>Linq не работает не с бизнес-сущностями, а с DTO.

    G>>Linq работает с данными, или с записями если угодно (одно и тоже). DTO — костыль для изначально хреновой жирной модели.

    IT>Я предпочитаю называть набор классов, соответсвующих схеме БД моделью данных приложения. Как правило этот термин интуитивно понятен большинству, не противопоставляет себя объектной модели приложения и не вызывает бурных возражений


    Я тоже так предпочитаю называть, только у многих модель данных ассоциируется с domain model, что приводит у ненужному терминологическому спору.
    Re[12]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 22:09
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Влад, ты рассуждаешь так, как будто кроме DAL ничего нет.


    О. Ты будешь потрясен. Я рассуждаю так, как будто DAL больше не нужен. Это еще прикольнее .
    Зачем мне DAL если я пользуюсь типизированными запросами? Чем в этом случе DAL отличается от бизнес-логики?

    A>Что потом делать с твоими анонимными типами?


    Обрабатывать. Наворачивать над данными сложную логику вовсе не обязательно. Те же запросы могут решить задачи в сто раз проще.

    Возьмем к примеру этот сайт. Зачем мне делать какие-то бизнес-объекты чтобы отобразить информацию о сообщениях форума? А зачем бизнес-объекты чтобы вывести список твоих оценок?

    VD>>Не надо отображать объекты на БД.


    A>О как. И как ты представляешь связь тогда?


    Для таблиц использовать простой мапинг один к одному (таблица на один простой объект). Для выборок в которых не требуются все поля из таблицы или требуются поля из разных таблиц использовать кортежи или анонимные типы.

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

    В общем, это можно назвать — назад в будущее! Мы как бы возвращаемся в прошлое когда мы писали текстовые запросы к СУБД и обрабатвали их в своем любимом языке, но на новом уровне. Теперь запросы типизированные и нам не нужен ни дал, ни сложные TSQL. Более того. Получив список мы можем продолжить обрабатывать его теми же запросами, но уже локальными.

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

    В таких условиях ООП используется скорее для организации логики программы, а не для представления данных.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 22:22
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.


    Это реализация логики на исключения. Нужны объяснения почему — это плохо?

    MC>Вообще так можно про все сказать "что тут исключительного". К примеру пытаемся прочитать файл, а такого файла нет (его уже пользователь удалил), ну а что тут исключительного, давайте признак возвращать.


    Так и есть. Если это файл документа в текстовом процессоре, то кидать исключения — это неверная политика. Это и есть реализация логики на исключениях.
    А если это конфигурационный файл который кто-то случайно стер, то исключение будет весьма к месту. Только обрабатывать его надо не в прикладном коде, а где-то в функции Main(), чтобы приложение сообщило о проблеме и тихо завершилось. В других случаях это может быть цикла обработки сообщений, чтобы при исключении в обработчике одного из них была выдана ошибка и можно было бы попытаться выполнить другую команду.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[19]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 11.04.09 22:22
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    MC>>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.

    IT>Это назвается строить логику на исключениях, практика, за которую нужно не просто отбивать пальцы линейкой, а лучше даже что-нибудь отрезать.

    Удели пожалуйста 2 минуты, объясни почему за выбрасывание исключения из DAL при отсутствии темы с заданным ID нужно что-нибудь отрезать.


    PS. "По-моему логике" выше это я прикольно написал, видимо спать пора
    Re[19]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 11.04.09 22:24
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    MC>>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.

    VD>Это реализация логики на исключения. Нужны объяснения почему — это плохо?

    Да, пожалуйста.
    Re[18]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 22:27
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Сам факт модерирования исключителен


    Да, ну? А может это вопрос той самой бизнес-логики?

    VD>>Почему нельзя сделать метод или запрос который просто вернет некий признак отсутствия данных?


    A>По-моему, в твоём примере налицо race condition. Надо либо запретить удалять из базы данных (я за этот метод), а только помечать сообщение как удалённое, либо смириться с тем что DAL кинет исключение, потому что блокировать ресурс-сообщение нельзя. В BL его можно обработать, а можно даже не обрабатывать. В конце концов я могу прямо в URL вбить номер несуществующего сообщения.


    Зачем мне мериться? Проще возвращать что надо и проверять результат.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 11.04.09 22:38
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Не нужно ничего отрезать. Вообще вопрос правильности кидания исключений — исключительно вопрос веры.

    G>Если вы верите что ненахождение чего-либо по ИД в базе — всегда исключительноая ситуация, то ваш подход верен.
    G>Но у вас обязательно возникнет ситуация, когда эта ситуация будет вполне нормальной в одном случае и ненормальной в другом.
    G>Тогда у вас будет или два метода — один — бросающий исключение, а другой такой же, но небросающий. Или у вас появится метод BL, где половина кода в try, другая половина в catch, при этом реально достаточно одного простого if.

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

    G>Короче если ваша вера непральная, то вы сами себе что-нить отрежете.


    Понятно. Не нужно думать что я везде исключения кидаю, но просто вот в приведенных 2х примерах выкинул бы и обработал выше.
    Я конечно не утверждаю что это правильно, не мне с вами всеми спорить, просто я не вижу в этом проблемы. Будет полезно если мне кто-то объяснит эту самую проблему, желательно как раз на примере с выбрасыванием исключения из DAL при ненахождении записи по ID и последующей обработке в BL — что в этом такого ужасного? (видимо теперь этот вопрос в IT & VladD2)
    Re[14]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 22:39
    Оценка:
    Здравствуйте, adontz, Вы писали:


    A>JOIN тут никак не поможет. Объясняю данный пример подробно. Есть таблицы А и B вида

    A>
    A>id | name
    A> 1 | first
    A> 2 | second
    A> 3 | third
    A>

    A>а так же таблица A2B вида
    A>
    A>aId | dId
    A>  1 |   1
    A>  1 |   2
    A>  2 |   1
    A>  2 |   3
    A>  3 |   1
    A>  3 |   5
    A>

    A>Если читать её не целиком, а кусками (не важно по aID будет выборка или по bID) ты в самом лучшем случае замедлишь всё в O(ln(n)) раз.

    Я уже устал от бесполезных разговоров. Что помешает сделать джоин? И зачем выбирать эти данные (в чем задача?)?

    A>Затем чтобы, например, прибайндить IBindingList<мои объекты> сразу в несколько View. И чтобы они обновлялись нормально, без "паркинсона" на кнопке F5, а для этого, кстати, нужен INotifyPropertyChanged и вообще много разных мелких инфраструктурных штучек. А ещё, могу захотеть кешировать, причём даже не весь объект, а его часть. Если чтение производится где попало через Query, мне это вряд ли удасться сделать.


    А, да, да... Каширование. Туча не нужной обвески и все это ради веры в объекты там где им не место.
    А зачем, собственно? Мы ведь должны были выбрать список тем для форума. Или данные по клиенту.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 22:48
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Если читать её не целиком, а кусками (не важно по aID будет выборка или по bID) ты в самом лучшем случае замедлишь всё в O(ln(n)) раз.

    G>А с какой целью её читать вообще?

    В моём случае, для подсказок при вводе данных.

    A>>Затем чтобы, например, прибайндить IBindingList<мои объекты> сразу в несколько View. И чтобы они обновлялись нормально, без "паркинсона" на кнопке F5, а для этого, кстати, нужен INotifyPropertyChanged и вообще много разных мелких инфраструктурных штучек. А ещё, могу захотеть кешировать, причём даже не весь объект, а его часть. Если чтение производится где попало через Query, мне это вряд ли удасться сделать.

    G>View, f5... надеюсь это не о вебе.

    Нет. F5 вообще общепринятАя клавиша для операции вроде refresh.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[21]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 22:49
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Как схемы БД, так и кода для работы с БД. Да, вот забыл упомянуть, что делать с row level security? Боюсь, если хранимки не генерировать, будет беда.

    G>тогда метаинформация нужна по мощности сравнимая с SQL, такое могут еще нескоро придумать. Может быть MSовский Oslo таким будет.

    Если не пытаться генерировать совсем всё-всё-всё, метаинформация может получится довольно таки простой.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[11]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 22:52
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Это нормальная/ненормальная ситуация не для БД и даже не для DAL, а для гораздо более высокоуровневой логики.


    Я, честно говоря, не очень понимаю почему DAL долен выдавать наверх данные с заведомо нарушенной целостностью.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[20]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 22:54
    Оценка:
    Здравствуйте, MozgC, Вы писали:

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


    MC>>>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.

    VD>>Это реализация логики на исключения. Нужны объяснения почему — это плохо?

    MC>Да, пожалуйста.


    Знаешь почему люди отказались от использования goto (особенно позволяющего передать управление глобально)?
    Потому что такие программы практически невозможно отлаживать. Они не структурны и нельзя делать предположения о их поведении.
    Та же фигня с исключениями. Они позволяют передавать управление не структурно. К тому же в дотнете нельзя описать, что метод возвращает исключение, а значит нельзя гарантировать, что исключение которое планировалось как обязательное для обработки таки будет обработано. В результате когда код становится большим, то отследить полеты исключений становится очень сложно.

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

    Ну, и последнее по счету, но не по важности — это практический опыт. А он четко показывает, что там где логика организуется на исключения всегда бардак и неразбериха.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[13]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 22:58
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>О. Ты будешь потрясен. Я рассуждаю так, как будто DAL больше не нужен. Это еще прикольнее .

    VD>Зачем мне DAL если я пользуюсь типизированными запросами? Чем в этом случе DAL отличается от бизнес-логики?

    DAL отличается от бизнес-логики назначением. DAL поддерживает инфрастурктуру: целостность данных, транзакции, права доступа на уровне строк. А вот как этим всем пользоваться решает BL.

    VD>Возьмем к примеру этот сайт. Зачем мне делать какие-то бизнес-объекты чтобы отобразить информацию о сообщениях форума? А зачем бизнес-объекты чтобы вывести список твоих оценок?


    Форум это не типичное приложение.

    VD>Для таблиц использовать простой мапинг один к одному (таблица на один простой объект). Для выборок в которых не требуются все поля из таблицы или требуются поля из разных таблиц использовать кортежи или анонимные типы.


    К сожалению простой мапинг один-к-одному не всегда удачное решение, с точки зрениякак нормализации БД, так и дальнейшей поддержки.

    VD>В общем, получать списки данных и обрабатывать их. Если нужны все данные по сущности (в том числе получаемые по вязям), ну, что же создадим запрос с джоинами. Точнее linq позволяет их представить в виде свойств и избежать прямых джоинов, но это уже детали реализации. В тоге все равно будет один комплексный запрос в БД.

    VD>В общем, это можно назвать — назад в будущее! Мы как бы возвращаемся в прошлое когда мы писали текстовые запросы к СУБД и обрабатвали их в своем любимом языке, но на новом уровне. Теперь запросы типизированные и нам не нужен ни дал, ни сложные TSQL. Более того. Получив список мы можем продолжить обрабатывать его теми же запросами, но уже локальными.
    VD>Задача обработки данных превращается в задачу трансформации данных.
    VD>В таких условиях ООП используется скорее для организации логики программы, а не для представления данных.

    То что ты говоришь хорошо для веба. Более или менее толстые клиенты так не напишешь.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[14]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 23:00
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Не-не-не, дэвид блейн, не-не. Не надо ООП тянуть в организацию логики программы. Для логики подходит модель SOA.


    SOA — это очередной базворд. Раньше это называли RPC, но потом в этом названии нашли фатальный недостаток .

    Логика программы — это несколько другое. Скажем клиентское оконное приложение использует ООП для управления онками и организации цикла обработки сообщений. Веб-сервер использует ООП для организации своей структуры и инкапсуляции таких вещей как сессии.

    G>Всля логика разбивается на сервсиные классы, которые в идеале stateless, в качестве SOA-интерфейсов используются интерфейсы языка, в качестве брокера — IoC контейнер. Методы сервисов создают цепочку вызовов, которая формирует запросы, не материализуя их без необходимости.


    Это еще одна вера. Там где нужен RPC там будет список методов. Говорить в этом случае о классах конечно смешно, так как они вырождаются в модули. А stateless-классы — это вообще нонсенс порожденный базворндным бредом.

    G>IoC контейнер в возможностями перехвата (runtime AOP) позволяет также навешивать авторизацию, кеширование и другие вкусности без затрагивания логики.


    У нас свои подходы. Людям познавшим, что такое макросы костыли вроде AOP и IoC становятся не нужны.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 23:11
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    G>>Как обрабаотывать случай отсутсвия в базе записи с нужным ID — уже дело BL, причем способ обработки сильно зависит от варианта использования.

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

    Собственно, если мы договорились о том, что "Отсутвие записи с нужным ID — это исключительная ситуация" то бизнес-логике думать уже не о чем. Надо культурно уведомить об ошибке.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[21]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 23:17
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Нельзя в принципе. Даже сама СУБД не умеет так.

    G>Думаешь почему есть Estimated Execution Plan, а есть реальный план исполнения запроса?
    G>Можно только предположить, а это как раз преждевременная оптимизация, которая ни к чему хорошему не ведет.

    Предположить можно с высокой спенью достоверности. То что ты описал наблюдается по той простой причине, что SQL Server хранит и использует статистику уже выполненных запросов.
    Вместо того чтобы создавать хаос, как предлагаешь ты, а потом тюнинговать БД чтобы этот хаос работал с приемлемой скоростью, можно создать изначально упорядоченный DAL и не надо будет ничего тюнинговать.

    A>>А что, ваш метод защищает от "грамотного" админа? Да и вообще, насколько актуальна эта проблема?

    G>Мой метод не защищает, и не дает иллюзию защиты, в отличие от ...

    Ты себе что-то напридумывал...
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[14]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 23:19
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>DAL отличается от бизнес-логики назначением. DAL поддерживает инфрастурктуру: целостность данных, транзакции, права доступа на уровне строк. А вот как этим всем пользоваться решает BL.


    По возможности не надо переносить задачу контроля целостности данных (ссылочной целостности) на программы. РСБУД это делают оптимальным образом — декларативно.

    Но я не против если в приложении требущем сложной логики ввода данных будет код отвечающий за это.
    Но ты же не говорил о записи данных. Правда? Ты говорил о DAL как о месте где хранятся методы доступа.
    Это было нужно когда методы доступа внутри себя содержали SQL в виде строк. А зачем они если мы оперируем с данными типизированными запросами?

    Скажу больше. Если реализовать встроенный в язык DML, то можно будет перехватывать изменение данных прямо тут же и код обеспечения целостности данных будет аналогичен триггерам в СУБД. Нам не надо будет писать метод SaveOrder(). Мы просто подключимся к соответствующему событию и отработаем нашу логику.

    VD>>Возьмем к примеру этот сайт. Зачем мне делать какие-то бизнес-объекты чтобы отобразить информацию о сообщениях форума? А зачем бизнес-объекты чтобы вывести список твоих оценок?


    A>Форум это не типичное приложение.


    Кому как. Но это и не важно. Важно, что если гипотеза опровергается примером, то это неверная гипотеза.

    A>К сожалению простой мапинг один-к-одному не всегда удачное решение, с точки зрения как нормализации БД, так и дальнейшей поддержки.


    Нормализация БД тут не причем, так как мы не подгоняем сущности под объекты, а просто отображаем сущности (т.е. данные) на плоские типы. В общем, ООП идет лесом.

    A>То что ты говоришь хорошо для веба. Более или менее толстые клиенты так не напишешь.


    Это хорошо для любых датацентричных задач. Конечно писать так редактор документов не стоит. Но если задача работает с базой данных, то этот подход для нее отлично подойдет.

    Просто ты сросся с догмами. ОРМ-ы так замечательно навязывали свои идеи на протяжении 10 последних лет, что в итоге многие уже считают только их подход единственно возможным.
    А мы вот мастодонты. Просидели век ОРМ-ов в подвалах и вылезли на свет в момент когда они изжили себя. Но к счастью (или несчастью) в этот самый момент на арену вышел ФП. Он отлично лег на датацентричный подход и оказался более удобным для обработки данных.
    Linq — это почти то что нужно. Осталось приделать DML. Решить проблемы производительности. И мы получим отличное решение датацентричных задач.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 23:20
    Оценка:
    Здравствуйте, adontz, Вы писали:

    VD>>А зачем, собственно? Мы ведь должны были выбрать список тем для форума. Или данные по клиенту.


    A>Влад я говорю не про форум и не про отчёты с дистрибуции. Есть и другие задачи, выходящии за пределы select из таблицы Orders.


    Да, понятно, понятно. Ты считаешь, что твои задачи сложнее и круче. Но дело в том, что запросы мощнее императивной обработки и они лучше для любых задач обработки данных.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 23:26
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Влад, ты говоришь несусветную глупость.


    Я бы на твоем месте не был бы так категоричен .

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


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

    A>Вообще-то тут и говорится про обработку ошибки. Ситуация считается ошибочной и для её, ошибочной ситуации, обработки используется исключение.


    Не. Вы говорите не об ошибках. Если темы нет в БД — это не ошибка. Это нормальная ситуация, по крайней мере может быть таковой.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 23:30
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>По возможности не надо переносить задачу контроля целостности данных (ссылочной целостности) на программы. РСБУД это делают оптимальным образом — декларативно.


    Да, в большиснтве случаев так и есть.

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

    VD>Но ты же не говорил о записи данных. Правда? Ты говорил о DAL как о месте где хранятся методы доступа.

    Ну вообще-то DAL должен поддерживать запись данных

    VD>Это было нужно когда методы доступа внутри себя содержали SQL в виде строк. А зачем они если мы оперируем с данными типизированными запросами?


    Типизированный запрос всё равно должен фильтроваться правами доступа на уровне строк А JOIN которые ты пытаешься мне пихнуть, всё становится даже сложнее.

    VD>Кому как. Но это и не важно. Важно, что если гипотеза опровергается примером, то это неверная гипотеза.


    А что ты опроверг?

    A>>К сожалению простой мапинг один-к-одному не всегда удачное решение, с точки зрения как нормализации БД, так и дальнейшей поддержки.

    VD>Нормализация БД тут не причем, так как мы не подгоняем сущности под объекты, а просто отображаем сущности (т.е. данные) на плоские типы. В общем, ООП идет лесом.

    Ты забыл про "дальнейшую поддержку". Дело в том, что база данных, по возможности, не должна анализировать данные, поэтому, зачастую, сущность отображается на несколько таблиц. Типичный пример, связанная таблица (ObjectID, PropertyName, PropertyValue). Преимущество такого подхода очевидно, рефакторинг BL сущности не прокатывается цепной волной по DAL. Меньше надо писать, меньше тестировать.

    VD>Просто ты сросся с догмами. ОРМ-ы так замечательно навязывали свои идеи на протяжении 10 последних лет, что в итоге многие уже считают только их подход единственно возможным.


    Если ты заметил, я не считаю ORM лучшим решением. Как это согласуется с твоими выводами?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[20]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 23:30
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>А что надо? Сообщение может быть недоступно потому что нет прав доступа, потому что самого сообщения нет, потому что сообщение не доступно анонимным пользователям. И на все случаи жизни у нас будет return null? Бу-га-га.


    Это у вас null. А у нас будет пустой список. И никто не говорит, что это решение на все случаи. Все зависит от логики. Если речь идет об исклчении, т.е. ошибке которая возникает в случае непредвиденных (заранее) обстоятельств, то конечно будет исключение и стандартная обработка.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 23:32
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    Это может быть разумно для некоторых сценариев. Но при этом в логике не должно быть обработки таких исключений. Они должны быть где-то совсем во внешнем кольце. Так чтобы стандартно сообщить пользовтелю, что произошла ошибка и или завершить приложение, или завершить текущую обработку команды (или сессию если мы на сервере).
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 11.04.09 23:39
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Все зависит от логики. Если речь идет об исклчении, т.е. ошибке которая возникает в случае непредвиденных (заранее) обстоятельств, то конечно будет исключение и стандартная обработка.


    Ну вот допустим идет запрос производителя по ID, и тут оказывается что такого производителя нет (а должен быть). Я кидаю из DAL исключение. И обрабатываю в БД (вывожу сообщение об ошибке пользователю и логирую саму ошибку). Что не так то?
    Re[22]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 11.04.09 23:41
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>И обрабатываю в БД


    в БЛ ***
    Re[16]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 11.04.09 23:43
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Ну вообще-то DAL должен поддерживать запись данных


    Вообще? А у тебя? Ты нам все время приводишь методы вроде Find и Get. Вот их то мы и не хотим видеть.

    A>Типизированный запрос всё равно должен фильтроваться правами доступа на уровне строк А JOIN которые ты пытаешься мне пихнуть, всё становится даже сложнее.


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

    VD>>Кому как. Но это и не важно. Важно, что если гипотеза опровергается примером, то это неверная гипотеза.


    A>А что ты опроверг?


    Твои утверждения.

    VD>>Нормализация БД тут не причем, так как мы не подгоняем сущности под объекты, а просто отображаем сущности (т.е. данные) на плоские типы. В общем, ООП идет лесом.


    A>Ты забыл про "дальнейшую поддержку". Дело в том, что база данных, по возможности, не должна анализировать данные, поэтому, зачастую, сущность отображается на несколько таблиц. Типичный пример, связанная таблица (ObjectID, PropertyName, PropertyValue). Преимущество такого подхода очевидно, рефакторинг BL сущности не прокатывается цепной волной по DAL. Меньше надо писать, меньше тестировать.


    Ты повторяешься. Я уже отвечал сто раз, что ошибочны твои предположения и суждения об объектах. Они не применимы к БД. Не надо проектировать БД под объекты.

    VD>>Просто ты сросся с догмами. ОРМ-ы так замечательно навязывали свои идеи на протяжении 10 последних лет, что в итоге многие уже считают только их подход единственно возможным.


    A>Если ты заметил, я не считаю ORM лучшим решением. Как это согласуется с твоими выводами?


    Ты мыслишь их понятиями. Ты уже достал своей идеей проецирования объектов на БД. По буквам Д О С Т А Л!
    Это тупик. Счастливого пути в этом направлении.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.04.09 23:50
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Вообще? А у тебя? Ты нам все время приводишь методы вроде Find и Get. Вот их то мы и не хотим видеть.


    Ты считаешь что должен быть только один Query?

    VD>>>Кому как. Но это и не важно. Важно, что если гипотеза опровергается примером, то это неверная гипотеза.

    A>>А что ты опроверг?
    VD>Твои утверждения.

    А ну ладно, а то я не заметил.

    VD>>>Нормализация БД тут не причем, так как мы не подгоняем сущности под объекты, а просто отображаем сущности (т.е. данные) на плоские типы. В общем, ООП идет лесом.

    A>>Ты забыл про "дальнейшую поддержку". Дело в том, что база данных, по возможности, не должна анализировать данные, поэтому, зачастую, сущность отображается на несколько таблиц. Типичный пример, связанная таблица (ObjectID, PropertyName, PropertyValue). Преимущество такого подхода очевидно, рефакторинг BL сущности не прокатывается цепной волной по DAL. Меньше надо писать, меньше тестировать.
    VD>Ты повторяешься. Я уже отвечал сто раз, что ошибочны твои предположения и суждения об объектах. Они не применимы к БД. Не надо проектировать БД под объекты.

    Я проектирую БД не под объекты, а под рефакторинг. или рефакторинг ты тоже отменил?

    A>>Если ты заметил, я не считаю ORM лучшим решением. Как это согласуется с твоими выводами?

    VD>Ты мыслишь их понятиями. Ты уже достал своей идеей проецирования объектов на БД. По буквам Д О С Т А Л!
    VD>Это тупик. Счастливого пути в этом направлении.

    Влад, то что ты описываешь, это склеротичная модель обращения с данными — прочитал и забыл, потому что ничего не получитсяя локально закешировать, даже в оперативной памяти. Возвращается ведь неизвестно что, нужное только в том месте, где возвращается. Это хорошо для веба, где веб-сервер и сервер БД рядом. Для клиент-сервера подобный подхход неприемлем.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[18]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 00:05
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Ты считаешь что должен быть только один Query?


    Я считаю, что должен быть один Linq.

    A>Я проектирую БД не под объекты, а под рефакторинг. или рефакторинг ты тоже отменил?


    Да. Рефактринг — это процесс улучшения, а не цель дизайна БД.

    A>Влад, то что ты описываешь, это склеротичная модель обращения с данными — прочитал и забыл, потому что ничего не получитсяя локально закешировать, даже в оперативной памяти.


    А не стоит брать на себя еще и задачи кэширования. Пусть этим займется СУБД. У нее это отлично получается.
    Но если есть уверенность, что данные не изменятся, то можно запросить их однажды, положить в локальную коллекцию и подключать с помощью локального join-а. Самое забавное, что при использовании linq — это будет совершенно прозрачно. Просто подсунь коллекцию другого типа и данные будут браться из нее. Ты можешь смешивать запросы к БД с запросами к локальным коллекциям. Нужно только понимать, что делаешь.

    A>Возвращается ведь неизвестно что, нужное только в том месте, где возвращается.


    Как это неизвестно что? Мы же ведь к таблицам обращаемся. Значит известно что.

    A>Это хорошо для веба, где веб-сервер и сервер БД рядом. Для клиент-сервера подобный подхход неприемлем.


    Да, ну. И в чем тут уникальность веб-а? И что значит рядом? У вас что СУБД в Америке, а сервер приложений в Китае?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[19]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 00:10
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    A>>Влад, то что ты описываешь, это склеротичная модель обращения с данными — прочитал и забыл, потому что ничего не получитсяя локально закешировать, даже в оперативной памяти.

    VD>А не стоит брать на себя еще и задачи кэширования. Пусть этим займется СУБД. У нее это отлично получается.

    Беда в том, что СУБД далеко и мне от её кеша не жарко.

    VD>Но если есть уверенность, что данные не изменятся, то можно запросить их однажды, положить в локальную коллекцию и подключать с помощью локального join-а. Самое забавное, что при использовании linq — это будет совершенно прозрачно. Просто подсунь коллекцию другого типа и данные будут браться из нее. Ты можешь смешивать запросы к БД с запросами к локальным коллекциям. Нужно только понимать, что делаешь.


    Ага, только вот, из-за отсутствия стандартизированных запросов и объектов для модели данных кеши будут абсолютно ненормализованы и несогласованы.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[20]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 00:13
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Беда в том, что СУБД далеко и мне от её кеша не жарко.


    Далеко — это где?

    VD>>Но если есть уверенность, что данные не изменятся, то можно запросить их однажды, положить в локальную коллекцию и подключать с помощью локального join-а. Самое забавное, что при использовании linq — это будет совершенно прозрачно. Просто подсунь коллекцию другого типа и данные будут браться из нее. Ты можешь смешивать запросы к БД с запросами к локальным коллекциям. Нужно только понимать, что делаешь.


    A>Ага, только вот, из-за отсутствия стандартизированных запросов и объектов для модели данных кеши будут абсолютно ненормализованы и несогласованы.


    Э... как это? Ты же запрашиваешь данные из той же таблицы? Может случиться только одно. Данные в кэше устареют.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 12.04.09 00:19
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    A>>Беда в том, что СУБД далеко и мне от её кеша не жарко.

    VD>Далеко — это где?
    На другом континенте, например.

    A>>Ага, только вот, из-за отсутствия стандартизированных запросов и объектов для модели данных кеши будут абсолютно ненормализованы и несогласованы.

    VD>Э... как это? Ты же запрашиваешь данные из той же таблицы? Может случиться только одно. Данные в кэше устареют.
    А какие именно данные устареют?
    Sapienti sat!
    Re[22]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 00:21
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>На другом континенте, например.


    То есть у вас сиквел в Интернет?
    Надеюсь, хот через ВПН?

    VD>>Э... как это? Ты же запрашиваешь данные из той же таблицы? Может случиться только одно. Данные в кэше устареют.

    C>А какие именно данные устареют?

    Любые которые будут изменены.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 00:27
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    A>>Беда в том, что СУБД далеко и мне от её кеша не жарко.

    VD>Далеко — это где?

    В другом городе, как и вебсервер хостящий веб-сервис. Обычное дело.

    A>>Ага, только вот, из-за отсутствия стандартизированных запросов и объектов для модели данных кеши будут абсолютно ненормализованы и несогласованы.

    VD>Э... как это? Ты же запрашиваешь данные из той же таблицы? Может случиться только одно. Данные в кэше устареют.

    А очень просто. Я получаю список городов в виде CityName, CustomerCount (именно так мне надо для отображения), а потом список клиентов в виде FirstName, LastName, CityName. В промежутке была исправлена ошибка ввода и одному из клиентов поменяли город. Штампы времени мне не помогут, у меня последняя версия данных таблицы Cities и последняя версия данных таблицы Customers. А вот несогласованность данных налицо. Что я могу с этим сделать? Я могу нажать Refresh в окне с Cities, вот и всё что я могу. Довольно дурацкая ошибка для технологии будущего.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[23]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 12.04.09 00:38
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    C>>На другом континенте, например.

    VD>То есть у вас сиквел в Интернет?
    VD>Надеюсь, хот через ВПН?
    У меня не SQL-сервер смотрит наружу, естественно, а мой специальный сервис магической синхронизации кэшей

    VD>>>Э... как это? Ты же запрашиваешь данные из той же таблицы? Может случиться только одно. Данные в кэше устареют.

    C>>А какие именно данные устареют?
    VD>Любые которые будут изменены.
    Я понимаю. Но КАК ты собираешься обнаружить то, что тебе нужно инвалидировать в кэшах? Общий механизм, пожалуйста.
    Sapienti sat!
    Re[25]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 01:39
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    C>>У меня не SQL-сервер смотрит наружу, естественно, а мой специальный сервис магической синхронизации кэшей

    VD>Чем изобретать велосипеды проще иметь реплики БД. Тогда они будут по близости и всегда в актуальном состоянии. Это лучший вариант кэша.

    Влад, конкретному клиенту может потребоваться много данных, но даже это количество может составлять лишь малую часть от общего объёма БД. А реплицировать гигабайты информации по международным каналам просто дорого. Твои ответы наводят на мысль что мегапередовая система совершенно не подходит для создания клиент-серверных приложений.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[26]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 01:53
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    Ну, дык определись. Может вообще ничего кэшировать/реплицировать не надо. Может надо кэширова/реплицировать только часть БД.

    A> А реплицировать гигабайты информации по международным каналам просто дорого.


    Я не знаю, что у вас в Грузии. У нас это трафик не так дорог. Да и если у фирмы гигабайтный трафик в день, то она очень богата. А если это вся БД, то синхронизация в день будет копеечной. Так что не выдумывай.

    A> Твои ответы наводят на мысль что мегапередовая система совершенно не подходит для создания клиент-серверных приложений.


    Это ты пытаешся найти какие-то крайние ситуации. БД и сервер приложений на разных частях мира — это как минимум ненадежно, и уж точно неразумно.
    Если репликация не подходит, то речь можно вести только о варианте запроса текущих данных.
    А если что-то делать через задницу, то конечно можно обосновать любое самое кривое решение.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[25]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 12.04.09 02:32
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    C>>У меня не SQL-сервер смотрит наружу, естественно, а мой специальный сервис магической синхронизации кэшей

    VD>Чем изобретать велосипеды проще иметь реплики БД. Тогда они будут по близости и всегда в актуальном состоянии. Это лучший вариант кэша.
    Нереально.
    1) Контроль доступа.
    2) Время синхронизации — у меня оповещения рассылаются меньше чем за секунду.
    3) Простота клиента. У меня это просто приложение, которое пользователь запускает через WebStart. Пользователям не надо думать о файрволах, публичных IP и т.д.

    Ни одна из существовавших 3 года назад (да и сейчас) технологий этого делать не позволяет.

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

    VD>Например, при перехватывая операцию добавления записи в таблицу (предположим, что удаление и обновление в таблице запрещено).
    Я не про то.

    Представь, что у нас есть две таблицы Person (id, date_created) и PersonalDetails(id, parent_id, name, last_name). Мы делаем запрос "SELECT pers.id, det.name, det.last_name FROM Person pers, PersonalDetails det where pers.id=det.parent_id" и кладём его результаты в кэш.

    Теперь на сервере у нас поменялся PersonalDetails (Мария Иванова вышла замуж и стала Марией Петровой, а инженер Василий поменял пол и стал Василией). Но обновить кэш корректно мы не можем! У нас в нём нет связи между этими таблицами.

    Предлагай решения.
    Sapienti sat!
    Re[20]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 12.04.09 03:26
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    IT>>Это назвается строить логику на исключениях, практика, за которую нужно не просто отбивать пальцы линейкой, а лучше даже что-нибудь отрезать.


    MC>Нет, это называется использовать исключения там где нужно.


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

    IT>>Вот хороший пример. Можно ещё обсудить вариант с разрешением к доступу к файлу. Твой backup процесс пытается скопировать файл, а он недоступен, по твоей логике есть только один путь — кинуть исключение и прервать процесс. Такой бекапер будет выброшен сразу же после первой проблемы с потерей информации.


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


    Читай выше. Ты строишь логику приложения на исключениях или ты с этим не согласен?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[20]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 12.04.09 03:29
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>Удели пожалуйста 2 минуты, объясни почему за выбрасывание исключения из DAL при отсутствии темы с заданным ID нужно что-нибудь отрезать.


    Потому что DAL отвечает за изоляцию доступа к данным и больше ни за что. Для БД твоя логика надо или не надо кидать исключение — темный лес. DAL в этом смысле не должен быть умнее.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[20]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 12.04.09 03:41
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Вообще-то исключения надо ловить, а не только кидать


    Ловить для того, чтобы построить на них логику приложения?

    Исключения ловить нужно только в одном случае, чтобы показать сообщение об ошибке пользователю.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[22]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 12.04.09 03:44
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    Возврат базой данных пустого рекордсета — это самая что ни на есть штатная ситуация. Исключительной она может стать (а может и не стать) только когда такое решение примет BL. Ты же предлагаешь кидать исключения в совершенно штатной ситуации. Бред.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[22]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 12.04.09 03:47
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>Ну вот допустим идет запрос производителя по ID, и тут оказывается что такого производителя нет (а должен быть). Я кидаю из DAL исключение. И обрабатываю в БД (вывожу сообщение об ошибке пользователю и логирую саму ошибку). Что не так то?


    Выделенное.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[22]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 04:30
    Оценка:
    Здравствуйте, MozgC, Вы писали:

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


    VD>>Все зависит от логики. Если речь идет об исклчении, т.е. ошибке которая возникает в случае непредвиденных (заранее) обстоятельств, то конечно будет исключение и стандартная обработка.


    MC>Ну вот допустим идет запрос производителя по ID, и тут оказывается что такого производителя нет (а должен быть). Я кидаю из DAL исключение. И обрабатываю в БД (вывожу сообщение об ошибке пользователю и логирую саму ошибку). Что не так то?


    То что производитель "должен быть" — деталь БЛ, незачем тащить её в dal.
    Re[16]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 04:40
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Если читать её не целиком, а кусками (не важно по aID будет выборка или по bID) ты в самом лучшем случае замедлишь всё в O(ln(n)) раз.

    G>>А с какой целью её читать вообще?

    A>В моём случае, для подсказок при вводе данных.

    Каких подсказок?
    Re[22]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 04:42
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Как схемы БД, так и кода для работы с БД. Да, вот забыл упомянуть, что делать с row level security? Боюсь, если хранимки не генерировать, будет беда.

    G>>тогда метаинформация нужна по мощности сравнимая с SQL, такое могут еще нескоро придумать. Может быть MSовский Oslo таким будет.

    A>Если не пытаться генерировать совсем всё-всё-всё, метаинформация может получится довольно таки простой.

    Если хочется генерировать хранимки, вьъхи, триггеры, индексы, то метаинформация будет сравнимой с SQL DDL.
    Re[15]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 04:47
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    G>>Не-не-не, дэвид блейн, не-не. Не надо ООП тянуть в организацию логики программы. Для логики подходит модель SOA.

    VD>SOA — это очередной базворд. Раньше это называли RPC, но потом в этом названии нашли фатальный недостаток .
    SOA — принции построения взаимодействия компонент. То что раньше было RPC теперь веб-сервисы.
    Re[30]: Проблемы организации OR-мапинга
    От: dotneter  
    Дата: 12.04.09 06:18
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>А смысл? Основные функции записей — это сравнение и копирование. Как этому помогут интерфейсы?

    class A:IValue
    {
        public int Value {get;set;}
        public IValue Copy(){...}
        public override bool Equals(object obj) { if(obj is IValue) ...}
    
    }


    VD>Да и опять же сгенерировать одинаковые гуиды для одинаковых записей нельзя.

    struct A { int a; }
    struct B { int a; }

    Я верю что для них можно сгенерировать одинаковые гуиды.

    VD>Это нонсенс.

    Из строки любой длинны нельзя выбрать 128 бит?

    VD>Требование одно. Структурная идентичность. Гуиды должны совпадать только у тех типов которые структурно идентичны.

    Мы сейчас говорим о net 4.0 или о чем то абстрактном? И что же произойдет если я зланомеренно поставлю гуид IEnemerabla какому нибудь своему интерфейсу?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
    Talk is cheap. Show me the code.
    Re[27]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 09:44
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

    VD>Ну, дык определись. Может вообще ничего кэшировать/реплицировать не надо. Может надо кэширова/реплицировать только часть БД.

    Влад, мы не реплицируем БД. в данном случае репликация — это костыль для твоей системы неспособной к локальному кешированию.

    A>> А реплицировать гигабайты информации по международным каналам просто дорого.

    VD>Я не знаю, что у вас в Грузии. У нас это трафик не так дорог. Да и если у фирмы гигабайтный трафик в день, то она очень богата. А если это вся БД, то синхронизация в день будет копеечной. Так что не выдумывай.

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

    A>> Твои ответы наводят на мысль что мегапередовая система совершенно не подходит для создания клиент-серверных приложений.

    VD>Это ты пытаешся найти какие-то крайние ситуации. БД и сервер приложений на разных частях мира — это как минимум ненадежно, и уж точно неразумно.

    Я тебе ясно написал что БД и сервер приложений очень даже рядом. Далеко — толстый клиент.

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

    VD>А если что-то делать через задницу, то конечно можно обосновать любое самое кривое решение.

    Пока что через задницу выглядит исключительно твой вариант.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[17]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 09:47
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Ты сам утверждаешь, что один запрос по твоей логике следует считать корректным, а другой некорректным. Откуда базе данных это знать?


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

    IT>И вообще, для многих это покажется крамолой, но с появлением технолоний вроде linq DAL, потеряв свои первоначальное продназначение вообще должен отмереть за ненадобностью.


    А, ну тогда помоги Владу ответить, потому что он что-то не справляется, как нам быть с кешированием на удалённом толстом клиенте. Начинать тут
    http://www.rsdn.ru/forum/message/3358676.1.aspx
    Автор: adontz
    Дата: 12.04.09
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[21]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 09:49
    Оценка:
    Здравствуйте, IT, Вы писали:

    A>>Вообще-то исключения надо ловить, а не только кидать

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

    а если ты не заметил, речь шла о ситуации, которая считается ошибочной.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[23]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 09:50
    Оценка:
    Здравствуйте, IT, Вы писали:

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

    IT>Возврат базой данных пустого рекордсета — это самая что ни на есть штатная ситуация. Исключительной она может стать (а может и не стать) только когда такое решение примет BL. Ты же предлагаешь кидать исключения в совершенно штатной ситуации. Бред.

    Описанная ситуация не может быть штатной, так как нарушена целостность данных Хотя, если для тебя нарушенная целостность данных штатная ситуация...
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[17]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 09:52
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>>>Если читать её не целиком, а кусками (не важно по aID будет выборка или по bID) ты в самом лучшем случае замедлишь всё в O(ln(n)) раз.

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

    Что значит каких? Удобных Какая разница? Данные надо прочесть, вот и всё. Если Linq-образный подход не поддерживает чтение в нужном виде, не надо мне доказывать, что подсказки личшние.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[31]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 10:27
    Оценка:
    Здравствуйте, dotneter, Вы писали:

    VD>>А смысл? Основные функции записей — это сравнение и копирование. Как этому помогут интерфейсы?

    D>
    D>class A:IValue
    D>{
    D>    public int Value {get;set;}
    D>    public IValue Copy(){...}
    D>    public override bool Equals(object obj) { if(obj is IValue) ...}
    D>}
    D>


    Ну, и что — это за фигня? И это вместо примитивнейшей структуры данных. Это никуда не годится.

    D>Из строки любой длинны нельзя выбрать 128 бит?


    Можно но это будет не уникального значение, а хэш-значение. И никто не гарантирует, что это хэш-значение не пересечется, ни с другими хэш-значениями, ни с другими гуидами.

    VD>>Требование одно. Структурная идентичность. Гуиды должны совпадать только у тех типов которые структурно идентичны.

    D>Мы сейчас говорим о net 4.0 или о чем то абстрактном? И что же произойдет если я зланомеренно поставлю гуид IEnemerabla какому нибудь своему интерфейсу?

    Гоюки.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[28]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 11:01
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Влад, мы не реплицируем БД. в данном случае репликация — это костыль для твоей системы неспособной к локальному кешированию.


    Я не хочу с тобой спорить. Считай как хочешь.

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


    Чушь натуральная. Надежнее Интернет ничего быть не может. Если твой сервер стоит в приличном датацентре (да даже если хоть в каком-то) то тебе обеспечен надежный доступ на скорости 10 и более мегабит.

    В прочем решения конечно могут быть разными. Но, на мой взгляд, самое глупое что можно придумать — это разнести сервер приложений и СУБД по разным частям Интерента и заниматься самопальным кэшированием. Решение будет априори не надежное и трудное в поддержке.

    A>Я тебе ясно написал что БД и сервер приложений очень даже рядом. Далеко — толстый клиент.


    Тогда ты вообще не ясно что обсуждаешь. Проблемы взаимодействия клиента и сервера приложений мы тут даже не обсуждаем. Кэширование данных на клиенте — это целиком прикладная задача. При современных скоростях интернета я вообще считаю это дурью. Gmail отлично продемонстрировал как должен работать современный софт. Лично я отказался от почтового клиента и читаю почту через веб-интерфейс Gmail-а.

    A>Пока что через задницу выглядит исключительно твой вариант.


    Я не понял того, что ты говоришь о клиенте. Конечно для клиента бессмысленно создавать реплики БД. Хотя Янус практически это и делает, так что это возможно. Я говорил о распределенной работе серверов.

    Вот Киберакс явно занимается распределением серверов в Интернет. На мой взгляд — это плохая идея, но уж если ее следует реализовать, то репликация БД лучше чем самопальные кэши.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[29]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 11:10
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

    VD>Чушь натуральная. Надежнее Интернет ничего быть не может. Если твой сервер стоит в приличном датацентре (да даже если хоть в каком-то) то тебе обеспечен надежный доступ на скорости 10 и более мегабит.

    Бугага. Региональные клиенты тоже в приличных датацентрах?

    A>>Я тебе ясно написал что БД и сервер приложений очень даже рядом. Далеко — толстый клиент.


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


    Я очень за тебя рад по поводу GMail, но тот факт что Влад читает почту через GMail не отменяет существования толстых клиентов. Если вернуться к сути вопроса, при твоём способе общения сервера приложений и базы данных, сервер приложений не сможет выдать клиенту ничего, что можно было бы закешировать. Скорее всего тебя и вовсе потянет на создание IQueryable over WebService. Соответсвенно прикладная задача кеширования становится неразрешимой. То есть твоя великая мегаидея, при ближайшем рассмотрении более или менее хорошо подходит только для вебсайтов.

    VD>Я не понял того, что ты говоришь о клиенте. Конечно для клиента бессмысленно создавать реплики БД. Хотя Янус практически это и делает, так что это возможно. Я говорил о распределенной работе серверов.

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

    Я не Киберакс и про распределённые сервера не говорил. Это очень интересная задача, но у меня другая — кеширование на клиенте данных полученных от сервера.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[26]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 11:14
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>1) Контроль доступа.


    И что с ним?

    C>2) Время синхронизации — у меня оповещения рассылаются меньше чем за секунду.


    А почему репликация данных не может работать с той же скоростью? Секунда — это довольно много.

    C>3) Простота клиента. У меня это просто приложение, которое пользователь запускает через WebStart. Пользователям не надо думать о файрволах, публичных IP и т.д.


    Причем тут клиент? У тебя ведь сервер данные кэширует? Мы вообще что обсуждаем? Может я вас не верно понял?

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

    C>Представь, что у нас есть две таблицы Person (id, date_created) и PersonalDetails(id, parent_id, name, last_name). Мы делаем запрос "SELECT pers.id, det.name, det.last_name FROM Person pers, PersonalDetails det where pers.id=det.parent_id" и кладём его результаты в кэш.


    А зачем часто изменяемые данные кэшировать. Такие данные я буду запрашивать каждый раз. Реч шла о чем-то что редко изменяется. Например о списке наменклатур. Бывает так, что они обновляются раз в месяц. В таких условиях тянуть описания продуктов из БД смысла нет. Хотя тоже стоит подумать, так как если этот список огромен, а каждый раз нужно вытаскивать всего 1-5 записей, то опять же кэш может оказаться бессмысленными.

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

    C>Теперь на сервере у нас поменялся PersonalDetails (Мария Иванова вышла замуж и стала Марией Петровой, а инженер Василий поменял пол и стал Василией). Но обновить кэш корректно мы не можем! У нас в нём нет связи между этими таблицами.


    То на что ты намекаешь — это болезнь под названием заменить БД кэшем в сервере приложения.

    C>Предлагай решения.


    Перестать дублировать работу сервера БД.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 11:19
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Что значит каких? Удобных Какая разница? Данные надо прочесть, вот и всё. Если Linq-образный подход не поддерживает чтение в нужном виде, не надо мне доказывать, что подсказки личшние.


    Что не поддерживает Linq?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[19]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 11:21
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Что не поддерживает Linq?


    Я описал задачу
    http://www.rsdn.ru/forum/message/3358527.1.aspx
    Автор: adontz
    Дата: 12.04.09

    http://www.rsdn.ru/forum/message/3358587.1.aspx
    Автор: adontz
    Дата: 12.04.09
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[30]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 11:27
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Бугага. Региональные клиенты тоже в приличных датацентрах?


    Причем тут клиенты? Еще раз. Я не гворил о связи с клиентами. Вообще!
    Абзац вниз слабо было прочесть?

    A>Я очень за тебя рад по поводу GMail, но тот факт что Влад читает почту через GMail не отменяет существования толстых клиентов. Если вернуться к сути вопроса, при твоём способе общения сервера приложений и базы данных, сервер приложений не сможет выдать клиенту ничего, что можно было бы закешировать.


    Это зависит от логики приложения. Замечательный пример — Янус. Он построен по описываемой мной технологии, но при этом целенаправленно создает кэш сообщений на клиенте. Только такое кэширование — это технология, а не заплатки для хреновой производительности.

    A> Скорее всего тебя и вовсе потянет на создание IQueryable over WebService.


    Это фиговое решение с точки зрения безопасности. Слишком мощный инструмент, который может быть использован злоумышленниками.

    A> Соответсвенно прикладная задача кеширования становится неразрешимой. То есть твоя великая мегаидея, при ближайшем рассмотрении более или менее хорошо подходит только для вебсайтов.


    Неверные выводы. Я говорил только а серверной стороне.

    A>Я не Киберакс и про распределённые сервера не говорил. Это очень интересная задача, но у меня другая — кеширование на клиенте данных полученных от сервера.


    А я об этом не говорил.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 11:29
    Оценка:
    Здравствуйте, adontz, Вы писали:

    VD>>Что не поддерживает Linq?


    A>Я описал задачу

    A>http://www.rsdn.ru/forum/message/3358527.1.aspx
    Автор: adontz
    Дата: 12.04.09

    A>http://www.rsdn.ru/forum/message/3358587.1.aspx
    Автор: adontz
    Дата: 12.04.09


    Нет там никакого описания задачи. Там есть описание решения на базе чего-то абстрактного.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[31]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 11:29
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

    VD>А я об этом не говорил.

    А что мешает?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[32]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 11:37
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

    VD>>А я об этом не говорил.

    A>А что мешает?


    1. Меня это не интересует.
    2. Говорить об этой задаче абстрактно нет смысл, так как есть много стратегий реализации.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[33]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 11:38
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    A>>А что мешает?

    VD>1. Меня это не интересует.
    VD>2. Говорить об этой задаче абстрактно нет смысл, так как есть много стратегий реализации.

    Ах вот оно как. Ну-ну.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[32]: Проблемы организации OR-мапинга
    От: dotneter  
    Дата: 12.04.09 11:52
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Ну, и что — это за фигня?

    Это называется эмулируем средствами имеющимися в наличии.

    VD>Гоюки.

    Я не думаю что в вопросе идентичности интерфейсов на этот гуид заложита такая уж фатальная логика, так как смысл его необходимости не вполне очевиден.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
    Talk is cheap. Show me the code.
    Re[19]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 15:52
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Так ты опиши в каком виде тебе нужно прочесть данные (какие у тебя уже есть и какие нужно получить) и тебе сразу же покажут как это сделать в разы лучше на Linq, чем на любом супер-мега DAL.


    Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?!
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[20]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 16:04
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?!


    Это тебе уже объясняли. В задницу твои объекты и читай за один раз написав соответствующий запрос.

    Что не понятно в этот ответе?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 16:06
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?!


    Если не понятен мой первый (точнее 30-ый) ответ, то поясню по-другому...
    То что ты описал не задача, а твое (никудышное на наш взгляд) решение какой-то более общей задачи. Вот ее и опиши. Опиши, что ты хочешь сделать с получаемой информацией.

    А если захочется еще раз рассказать о каких-то там объектах отображаемых на какие-то там связи вроде многое ко многим, то сразу забей... не повторяйся.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 16:10
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Так ты опиши в каком виде тебе нужно прочесть данные (какие у тебя уже есть и какие нужно получить) и тебе сразу же покажут как это сделать в разы лучше на Linq, чем на любом супер-мега DAL.


    A>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?!


    Давай в терминах данных, а не в терминах объектов.
    Получается просто надо прочитать содержимое таблицы?
    Думаешь супер-мега DAL будет в данном случае обычного запроса (хоть Linq, хоть SQL)?

    ЗЫ. Linq2SQL такое выполняет сам, в EF такое не нужно, там явно не работать с таблицами связей нельзя, оно отображаются на связи типа "многие-ко-многим" модели данных.
    Re[21]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 16:25
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    A>>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?!

    VD>Это тебе уже объясняли. В задницу твои объекты и читай за один раз написав соответствующий запрос.
    VD>Что не понятно в этот ответе?

    в ответе непонятно твоё хамство
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[21]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 16:27
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?!

    G>Давай в терминах данных, а не в терминах объектов.
    G>Получается просто надо прочитать содержимое таблицы?

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

    G>Думаешь супер-мега DAL будет в данном случае обычного запроса (хоть Linq, хоть SQL)?


    Что? Придложение несогласованное какое-то...
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[22]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 16:31
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Я уже объяснил — надо отношение многие-ко-многим между двумя типами объёктов прочесть за один раз и распихать результат по экземплярам обоих типов. Что, в этой задаче такого сложного, что я уже раз 10 вынужден повторить условие?!

    G>>Давай в терминах данных, а не в терминах объектов.
    G>>Получается просто надо прочитать содержимое таблицы?

    A>Не просто прочитать содержимое, а прочитать и сохранить в объектах. Надолго сохранить, закешировать например.

    Это к запросам отношения не имеет.

    G>>Думаешь супер-мега DAL будет в данном случае обычного запроса (хоть Linq, хоть SQL)?


    A>Что? Придложение несогласованное какое-то...

    Да, че-то слово пропустил.

    Думаешь супер-мега DAL будет в данном случае изящнее обычного запроса (хоть Linq, хоть SQL)?
    Re[23]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 16:43
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Не просто прочитать содержимое, а прочитать и сохранить в объектах. Надолго сохранить, закешировать например.

    G>Это к запросам отношения не имеет.

    Да, беда как раз в том, что имеет отношение, потому что изначально неструктурированные запросы, содержащие только то что надо в месте вызова, для кеширования не подходят.
    Я уже даже объяснил почему, привёл пример проблемы http://www.rsdn.ru/forum/message/3358676.1.aspx
    Автор: adontz
    Дата: 12.04.09


    G>Думаешь супер-мега DAL будет в данном случае изящнее обычного запроса (хоть Linq, хоть SQL)?


    Да чё тут думать, у меня он уже есть
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[24]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 16:56
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Не просто прочитать содержимое, а прочитать и сохранить в объектах. Надолго сохранить, закешировать например.

    G>>Это к запросам отношения не имеет.

    A>Да, беда как раз в том, что имеет отношение,

    Это в твоем случае имеет, такова особенность твоей реализации. В мой реализации способ получения результатов запроса на их обработку не влияет.

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

    Linq запросы неструктурированы? Почему не подходят для кеширования?


    A>Я уже даже объяснил почему, привёл пример проблемы http://www.rsdn.ru/forum/message/3358676.1.aspx
    Автор: adontz
    Дата: 12.04.09

    В многопользовательской среде несогласованность отображаемых данных из БД- нормальное явление. С этим не надо бороться, это надо учитыватьпри проектировании интерфейсов.

    G>>Думаешь супер-мега DAL будет в данном случае изящнее обычного запроса (хоть Linq, хоть SQL)?

    A>Да чё тут думать, у меня он уже есть
    Мои соболезнования.
    Re[25]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 17:01
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Да, беда как раз в том, что имеет отношение,

    G>Это в твоем случае имеет, такова особенность твоей реализации. В мой реализации способ получения результатов запроса на их обработку не влияет.

    Ты так и не понял, дело не в способе получения, а в полноте самих данных.

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

    G>Linq запросы неструктурированы? Почему не подходят для кеширования?

    Потому что согласованность нарушена.

    A>>Я уже даже объяснил почему, привёл пример проблемы http://www.rsdn.ru/forum/message/3358676.1.aspx
    Автор: adontz
    Дата: 12.04.09

    G>В многопользовательской среде несогласованность отображаемых данных из БД- нормальное явление. С этим не надо бороться, это надо учитыватьпри проектировании интерфейсов.

    Боюсь что ты не прав. Можно обеспечить согласованность данных, нельзя обеспечить актуальность.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[26]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 17:07
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Да, беда как раз в том, что имеет отношение,

    G>>Это в твоем случае имеет, такова особенность твоей реализации. В мой реализации способ получения результатов запроса на их обработку не влияет.

    A>Ты так и не понял, дело не в способе получения, а в полноте самих данных.

    Ну давай по-кругу. Что есть и что надо получить?
    Только пожалуйтса не в терминах объектов.

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

    G>>Linq запросы неструктурированы? Почему не подходят для кеширования?
    A>Потому что согласованность нарушена.
    Согласованность чего?

    A>>>Я уже даже объяснил почему, привёл пример проблемы http://www.rsdn.ru/forum/message/3358676.1.aspx
    Автор: adontz
    Дата: 12.04.09

    G>>В многопользовательской среде несогласованность отображаемых данных из БД- нормальное явление. С этим не надо бороться, это надо учитыватьпри проектировании интерфейсов.
    A>Боюсь что ты не прав. Можно обеспечить согласованность данных, нельзя обеспечить актуальность.
    Это словоблудие.
    Согласованность можно обеспечить если запрашиваться все сразу (JOIN), но сценрии работы зачастую не позволяют это сделать. Причем это абсолютно не зависит от технологий доступа к данным.
    Re[27]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 17:09
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Согласованность можно обеспечить если запрашиваться все сразу (JOIN), но сценрии работы зачастую не позволяют это сделать. Причем это абсолютно не зависит от технологий доступа к данным.


    Ты не прав. Согласованность можно обеспечить даже запрашивая по частям, если сохранять ссылочную структуру.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[28]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 17:14
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Согласованность можно обеспечить если запрашиваться все сразу (JOIN), но сценрии работы зачастую не позволяют это сделать. Причем это абсолютно не зависит от технологий доступа к данным.


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

    Какую ссылочную структуру?

    Как обеспечить согласованность когда между отображением поста в списке и попыткой открыть его модератор успевает его удалить?

    Или тот же пример с городами: запросили сначала список городов с количеством кастомеров, потом запрашиваем катомеров из конкретного города. Между запросами другой пользователь поменял одному из кастомеров в город. Какая ссылочная структура поможет отследить изменение количества в двух городах?
    Re[18]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 12.04.09 17:20
    Оценка:
    Здравствуйте, adontz, Вы писали:

    IT>>Ты сам утверждаешь, что один запрос по твоей логике следует считать корректным, а другой некорректным. Откуда базе данных это знать?


    A>Нет. Я лишь сказал, что когда хочу получить информацию об элементе по его идентификатору, потому что в другом месте уже были ссылки на элемент с данным идентификатором, то отсутсвие элемента — проблема целостности данных.


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

    IT>>И вообще, для многих это покажется крамолой, но с появлением технолоний вроде linq DAL, потеряв свои первоначальное продназначение вообще должен отмереть за ненадобностью.


    A>А, ну тогда помоги Владу ответить, потому что он что-то не справляется, как нам быть с кешированием на удалённом толстом клиенте. Начинать тут

    A>http://www.rsdn.ru/forum/message/3358676.1.aspx
    Автор: adontz
    Дата: 12.04.09


    А какие у тебя проблемы с кешированием? Ты его затолкал в DAL только потому что так удобнее и теперь считаешь его неотъемлемой частью DAL?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[16]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 12.04.09 17:23
    Оценка:
    Здравствуйте, adontz, Вы писали:

    IT>>Ну да, я так и думал. Всё-таки каша в голове. Рома, DAL — это слой изолирующий работу с БД в терминах БД от остальной части приложения. Другими словами, в коде мы используем типизированные данные, а с БД вынуждены работать используя строковые константы. DAL был придуман иключительно как средство, позволяющее изолировать работу со строками в одном месте, которое будет легче контролировать. Всё! Другого назначения у DAL нет и никогда не было.


    A>Это не DAL, это ORM.


    Рома, ты прежде чем спорить ознакомился бы сначала с общепринятой терминологией. Начни отсюда.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[24]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 12.04.09 17:26
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Описанная ситуация не может быть штатной, так как нарушена целостность данных Хотя, если для тебя нарушенная целостность данных штатная ситуация...


    Ты неверно понимаешь термин целостность данных.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[11]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 12.04.09 19:09
    Оценка:
    G>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).
    А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[12]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 12.04.09 19:09
    Оценка:
    A>QueryObject нужен для нетипичных запросов, типа запросов для отчётов. Использовать его для всего подряд просто неправильно.
    Тут соглашусь с Ромой
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[33]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 19:09
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Права доступа на уровне DAL — великая вещь.

    G>У тебя фильтрация по уровню доступа в DAL?
    G>Это ужасно.

    Это замечательно, потому что в фильтрации нет бизнес-логики.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[12]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 19:12
    Оценка:
    Здравствуйте, Tom, Вы писали:

    G>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).

    Tom>А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия?
    Могут, только это будет не DAL.
    При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.
    Re[34]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 19:13
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Права доступа на уровне DAL — великая вещь.

    G>>У тебя фильтрация по уровню доступа в DAL?
    G>>Это ужасно.

    A>Это замечательно, потому что в фильтрации нет бизнес-логики.


    Это и есть бизнес-логика.
    Re[13]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 19:16
    Оценка:
    Здравствуйте, Tom, Вы писали:

    A>>QueryObject нужен для нетипичных запросов, типа запросов для отчётов. Использовать его для всего подряд просто неправильно.

    Tom>Тут соглашусь с Ромой
    С чем соглашиься? С голословным утверждением?
    Может тогда ты ответишь почему это "просто неправильно" ?
    Re[35]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 19:20
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>>>Права доступа на уровне DAL — великая вещь.

    G>>>У тебя фильтрация по уровню доступа в DAL?
    G>>>Это ужасно.
    A>>Это замечательно, потому что в фильтрации нет бизнес-логики.
    G>
    G>Это и есть бизнес-логика.

    Какая бизнес-логика в правах доступа NTFS?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[32]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 12.04.09 19:28
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

    G>>Потом идет придумывание LazyLoad, кеширования и прочих гадостей.

    A>Ты просто не умеешь их готовить.


    Рома, не изобретай велосипед, возми лучше сразу NHibernate или EF и не парься. Там все эти какашки парни уже давно за тебя придумали.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[17]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 12.04.09 19:49
    Оценка:
    VD>SOA — это драцкий базворд за которым нет ничего нового. К компонентам (кстати "компонентов", а не "компонента") SOA не имеет никакого отношения. Расшифровывается этот базворд как "архитектура ориентированная на сервисы". Это тоже самое что серверы ориентированные на RPC. Дурацкий базвордов придумать можно миллионы (что и делаеют конторы вроде МС каждый день), но толку от этого не будет, так как ничего принципиально нового от этот не появится.
    VD>SOA родилась в момент когда в МС полностью отчаялись протащить DCOM в область разработки серверов приложений. Тогда они понял, что общаться с серверами намного проще по средствам RPC (без сохранения состояния между вызовами на сервере). Тогда срочно придумали веб-сервисы, а чтобы все это круто звучало и никто не догадался, что это просто откат к более "примитивной" технологии и признание недееспособности ООП в области организации распределенных вычислений назвали все это SOA. Как и любой базворд это звучит красиво, не понятно. Что еще нужно чтобы завуалировать собственную глупость?

    О. Очень правильно и в точку. Надо в ФАК занести.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[36]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 19:56
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>>>Права доступа на уровне DAL — великая вещь.

    G>>>>У тебя фильтрация по уровню доступа в DAL?
    G>>>>Это ужасно.
    A>>>Это замечательно, потому что в фильтрации нет бизнес-логики.
    G>>
    G>>Это и есть бизнес-логика.

    A>Какая бизнес-логика в правах доступа NTFS?

    Её там нет, также как нету бизнес-логики в правах доступа к объектам СУБД.

    Row-level security — уже BL, причем достаточно тяжелая (читай — надо тестировать).
    Re[37]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 19:57
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Какая бизнес-логика в правах доступа NTFS?

    G>Её там нет, также как нету бизнес-логики в правах доступа к объектам СУБД.

    Считай, что строка таблицы — объект СУБД.

    G>Row-level security — уже BL, причем достаточно тяжелая (читай — надо тестировать).


    Нет. Раздача конкретных прав доступа это бизнес-логика. А проверка — нет.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[38]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 20:25
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Какая бизнес-логика в правах доступа NTFS?

    G>>Её там нет, также как нету бизнес-логики в правах доступа к объектам СУБД.

    A>Считай, что строка таблицы — объект СУБД.

    Я могу так считать, а сама СУБД начнат проверять разрешения от этого?
    Проверки все равно ложатся на клиентский код независимо от того как я считаю.

    G>>Row-level security — уже BL, причем достаточно тяжелая (читай — надо тестировать).

    A>Нет. Раздача конкретных прав доступа это бизнес-логика. А проверка — нет.
    Запишу этот перл в коллекцию.
    Re[39]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.04.09 20:27
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Считай, что строка таблицы — объект СУБД.

    G>Я могу так считать, а сама СУБД начнат проверять разрешения от этого?
    G>Проверки все равно ложатся на клиентский код независимо от того как я считаю.

    Ты не прав.

    G>>>Row-level security — уже BL, причем достаточно тяжелая (читай — надо тестировать).

    A>>Нет. Раздача конкретных прав доступа это бизнес-логика. А проверка — нет.
    G>Запишу этот перл в коллекцию.

    Записать дело не хитрое, главное понять.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[40]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 12.04.09 20:43
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Считай, что строка таблицы — объект СУБД.

    G>>Я могу так считать, а сама СУБД начнат проверять разрешения от этого?
    G>>Проверки все равно ложатся на клиентский код независимо от того как я считаю.

    A>Ты не прав.

    В чем?
    У вас проверки RLS не в коде? Это сама субд делает? Покажите мне эту субд.
    Re[20]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 20:44
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Да нет, дело не в том что удобнее, а в том что правильнее.


    Супер. Новое инженерно-научный постулат "правильнее".

    Можно задать критерии правильности в общем случае?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[14]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 12.04.09 20:48
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.

    Tom>От клиента до сервера БД. ТАк же как и в самих запросах. Так что эти разделения на BL/DAL предлагаю сразу забыть.

    Это звучит примерно так: я не понимаю смысла разделения приложения на слои, поэтому предлагаю эти разделения сразу забыть. Да уж, чего только люди не придумают для оправдания собственных ошибок или непонимания сути обсуждаемых вещей.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[15]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 20:51
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Потому что серебрянной пули на практике не бывает.

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

    Смотри программирование ошибочно, так как на любой вопрос автоматизации все предлагают запрограммировать ее.
    СУБД ошибочны так как для хранения данных предлагают использовать их.
    Еще примеры приводить?

    Запросы не панацея — способ обработки данных. Его прекрасно можно использовать для обработки данных вместо дурацкого запаковывания всего и все в объекты и попыток использовать ООП для обработки данных.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[12]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 20:56
    Оценка:
    Здравствуйте, Tom, Вы писали:

    G>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).

    Tom>А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия?

    Могут. Вот только какой смысл cоздавать DAL в котором все методы будут выглядеть так:
    X GetById(int id)
    {
      return (from x in xs where x.id = id select x).Fitst(); 
    }
    ...
    ... GetById(GetId())

    если нам раз в год нужно получать что-то по id и постоянно нужно получать списки и обрабатывать их?

    Ты погляди на на код своих хранимок. Там ведь обработка данных, а не все эти GetById. Почему?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[32]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 12.04.09 22:24
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем?


    Какой смысл в отображении одного мегабайта данных?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[13]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 12.04.09 22:24
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    G>>>Кроме того в нормальном DAL не будет GetById, FindByFirstName, будет ExecuteQuery(QueryObject).

    Tom>>А почему не будет? Или скажем почему GetById не могут из себя вызывать ExecuteQuery(QueryObject)? Религия?

    VD>Могут. Вот только какой смысл cоздавать DAL в котором все методы будут выглядеть так:

    VD>
    VD>X GetById(int id)
    VD>{
    VD>  return (from x in xs where x.id = id select x).Fitst(); 
    VD>}
    VD>...
    VD>... GetById(GetId())
    VD>

    VD>если нам раз в год нужно получать что-то по id и постоянно нужно получать списки и обрабатывать их?

    Как правило получать что-то по id как раз нужно не раз в год, а постоянно и из разных мест.
    Re[14]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 12.04.09 23:35
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>Как правило получать что-то по id как раз нужно не раз в год, а постоянно и из разных мест.


    Дык ты правила придумал. Меняй их.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[41]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 03:05
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Ты не прав.

    G>В чем?
    G>У вас проверки RLS не в коде?

    Да, они в хранимках.

    G>Это сама субд делает? Покажите мне эту субд.


    Это SQL Server. Так как проверки прав доступа в конечном итоге сводятся к фильтрации по индексированному полю, мы получаем многократный прирост в производительности, так как многие данные вообще не читаются с диска.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[29]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 03:07
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    KV>А он там и не нужен. Контроль доступа (если мы говорим об одном и том контроле), должен реализовываться на уровне операций, причем "операций" в терминологии BL, а не DAL. В противном случае, это уверенный шаг к уязвимостях недостаточной авторизации.


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

    C>>Реплики БД — это исключительно кривой хак.

    KV>Хорошо что тебя разработчики Lotus Domino/Notes не слышат. А то они на этом хаке, всю архитектуру своего продукта построили

    И как оно работает?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[15]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 03:11
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    MC>>Как правило получать что-то по id как раз нужно не раз в год, а постоянно и из разных мест.

    VD>Дык ты правила придумал. Меняй их.

    Влад, создание альтернативной реальности это не метод разработки архитектуры ПО.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[21]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 03:19
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    A>>Да нет, дело не в том что удобнее, а в том что правильнее.

    VD>Супер. Новое инженерно-научный постулат "правильнее".
    VD>Можно задать критерии правильности в общем случае?

    Влад, если нечего сказать по существу, то лучше вообще не писать, ведь разговаривать про клиентский кеш ты недавно отказался. Искать "the answer to life, the universe and everything" можешь без меня.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[30]: Проблемы организации OR-мапинга
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 13.04.09 04:15
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    KV>>А он там и не нужен. Контроль доступа (если мы говорим об одном и том контроле), должен реализовываться на уровне операций, причем "операций" в терминологии BL, а не DAL. В противном случае, это уверенный шаг к уязвимостях недостаточной авторизации.


    A>Голословное утверждение. Каким образом чтение и последущий отсев данных улучшает безопасность по сравнению с запретом чтения?


    Зачем читать все, чтобы потом отсеять?

    C>>>Реплики БД — это исключительно кривой хак.

    KV>>Хорошо что тебя разработчики Lotus Domino/Notes не слышат. А то они на этом хаке, всю архитектуру своего продукта построили

    A>И как оно работает?


    Вполне. И мне страшно подумать, как решались бы вопросы масштабирования и плохих каналов (плохой == < 10Мбит), если бы в лотусе не было этой "особенности". С чем собственно мы и столкнулись в 1С, и из-за чего с нее, в итоге, и свалили.

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[31]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 13.04.09 04:18
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    C>>Дело в том, что нужно обеспечивать и контроль данных — чтобы любой пользователь не мог подсмотреть номер кредитки директора.

    KV>Забавно, ты сам же и описал задачу в терминах операций BL
    Ну считай, что в BL есть generic-операция "взять объект".

    KV>Уточню, речь о row-level security, упомянутой gandjustas'ом или о чем-то ином?

    У меня это object-level security. Естественно, это не отменяет security на операции.

    KV>Кстати, а что ты будет делать с атаками man-in-the-middle?

    Так как обычно security каналов связи (HTTPS со строгой проверкой сертов). Или ты что-то другое имеешь в виду?

    C>>Скажи, и нравится тебе как работает Лотус?

    KV>Как пользователю — нет, но это никак не связано с его архитектурой. Как админу, в прошлом поддерживавшему инфраструктуру из 12-13 лотусовых серверов и пары тысяч клиентов — да, нравится. Как безопаснику — мне вообще ничего не нравится, так что не аргумент
    Тем не менее, это подход очень глючный. Для email-серверов он ещё сгодится — нет особых ограничений на время и консистентность синхронизации.
    Sapienti sat!
    Re[32]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 04:30
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


    C>>>Если пародия работает круто — то это не пародия. Обычные РБД оптимизированы на работу с большим количеством данных. В клиентском кэше данных обычно совсем немного, поэтому простой линейный перебор по экстентам почти всегда даёт нужный результат.

    G>>Ты наверное не понял что использование DML позволяет вообще не тянуть на клиент никакие данные, материализовываться выборки будут только с целью отображения.
    C>"Вообще не тянуть на клиент никакие данные" — это смешно.
    Эт овполне возможно.

    C>У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем?

    И что? Про кеширование я уже написал.
    Re[42]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 04:43
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Ты не прав.

    G>>В чем?
    G>>У вас проверки RLS не в коде?
    A>Да, они в хранимках.

    От того что часть логики помещена в хранимки она логикой быть не перестает.

    Зато теперь понятно почему тебе так не нравятся запросы, используя хранимки для CRUD использование запросов становится неудобным и почти ненужным.
    Re[34]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 05:44
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>>>У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем?

    IT>>Какой смысл в отображении одного мегабайта данных?
    C>Это совсем не так много, как кажется. Особенно, если туда входят картинки.

    Ну так в чём тогда проблема? Объективная реальность
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[35]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 13.04.09 05:47
    Оценка:
    Здравствуйте, IT, Вы писали:

    C>>>>У меня вот выборка — это 1 мегабайт данных. Материализовываться для отображения она будет секунд 10 на весьма неплохом канале. Что делать будем?

    IT>>>Какой смысл в отображении одного мегабайта данных?
    C>>Это совсем не так много, как кажется. Особенно, если туда входят картинки.
    IT>Ну так в чём тогда проблема? Объективная реальность
    Хочется чтоб всё быстро работало
    Sapienti sat!
    Re[42]: Проблемы организации OR-мапинга
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 13.04.09 07:31
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Ты не прав.

    G>>В чем?
    G>>У вас проверки RLS не в коде?

    A>Да, они в хранимках.


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

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[4]: Проблемы организации OR-мапинга
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 13.04.09 07:42
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>ИМХО всё не так. Для GetById надо откуда-то взять этот самый Id. Отсутствие объекта это исключительная ситуация и никаким null тут и не пахнет.


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

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[32]: Проблемы организации OR-мапинга
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 13.04.09 07:45
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    KV>>Уточню, речь о row-level security, упомянутой gandjustas'ом или о чем-то ином?

    C>У меня это object-level security. Естественно, это не отменяет security на операции.

    Т.е. ты строишь в реляционной среде разграничение доступа на уровне объектов и утверждаешь, что это лучше, чем использовать для этого ОО-среду? Или у тебя ООБД?

    KV>>Кстати, а что ты будет делать с атаками man-in-the-middle?

    C>Так как обычно security каналов связи (HTTPS со строгой проверкой сертов).

    Нифига себе у тебя "есстественный путь", которым SQL-сервер смотрит наружу , хотя это по нашему

    C>Или ты что-то другое имеешь в виду?


    Да нет, именно это

    C>>>Скажи, и нравится тебе как работает Лотус?

    KV>>Как пользователю — нет, но это никак не связано с его архитектурой. Как админу, в прошлом поддерживавшему инфраструктуру из 12-13 лотусовых серверов и пары тысяч клиентов — да, нравится. Как безопаснику — мне вообще ничего не нравится, так что не аргумент
    C>Тем не менее, это подход очень глючный. Для email-серверов он ещё сгодится — нет особых ограничений на время и консистентность синхронизации.

    Лотус — это не почтовый сервер. Более того, сама IBM уже не раз признавала, что именно как почтовик, оно получилось не очень.

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[16]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 08:17
    Оценка:
    VD>Запросы не панацея — способ обработки данных. Его прекрасно можно использовать для обработки данных вместо дурацкого запаковывания всего и все в объекты и попыток использовать ООП для обработки данных.
    Я чего то не понимаю где я писал что буду использовать ООП?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[16]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 08:17
    Оценка:
    G>Да, у меня на все есть один ответ — DML. Разве его недостаточно для выполнения любой задачи по работе с данными?
    Это уже кое что На сегодняшний день я знаю единственный язык полностью реализующий DML

    G>К сожалению современные средства позволяют описывать только выборки, поэтому приходится немного постараться чтобы работа с данными была DML-подобной.

    Интересно мне посмотреть такие попытки. Я себе их слабо представляю
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[15]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 08:17
    Оценка:
    IT>Это звучит примерно так: я не понимаю смысла разделения приложения на слои, поэтому предлагаю эти разделения сразу забыть. Да уж, чего только люди не придумают для оправдания собственных ошибок или непонимания сути обсуждаемых вещей.
    Опять розовый слоник в вакууме
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[15]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 08:17
    Оценка:
    G>>>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.
    Tom>>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.
    G>
    G>Открою тебе секрет, ни в одном моем проекте, которя я создавал от начала до конца такого не было.
    Это фикция. Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос:
    update order set delayed = true where OrderDate < '...'
    По твоему подобный запрос не реализует часть бизнес логики?
    Если нет, тогда покажи мне пример на C# реализующий бизнес правило: Заказы не выполненые по любой причине в течении дня перевести в статус задержанные.

    G>ЗЫ. Есдинственное что допускал из размазывания — перенесение некоторой части логики в функции\хранимки БД. Только с целью оптимизации.

    Я это уже читал. Это фикция. С вовременных приложениях, когда одна из основных задач — работа с данными, бизнес логика в любом случае будет реализовываться через запросы к БД.
    Конечно можно использовать ORM WAY но хрен редьки не слаще, а только геморней.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[16]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 09:47
    Оценка:
    Здравствуйте, Tom, Вы писали:

    G>>>>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.

    Tom>>>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.
    G>>
    G>>Открою тебе секрет, ни в одном моем проекте, которя я создавал от начала до конца такого не было.
    Tom>Это фикция. Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос:
    Tom>update order set delayed = true where OrderDate < '...'
    Tom>По твоему подобный запрос не реализует часть бизнес логики?
    Tom>Если нет, тогда покажи мне пример на C# реализующий бизнес правило: Заказы не выполненые по любой причине в течении дня перевести в статус задержанные.
    Сайчас это или foreach с объектами или SQL-запрос.
    Если будет Linq или EF провайдер с поддержкой DML, то буду использовать только его.

    G>>ЗЫ. Есдинственное что допускал из размазывания — перенесение некоторой части логики в функции\хранимки БД. Только с целью оптимизации.

    Tom>Я это уже читал. Это фикция. С вовременных приложениях, когда одна из основных задач — работа с данными, бизнес логика в любом случае будет реализовываться через запросы к БД.
    Вопрос в том как формировать такие запросы.
    Linq сейчас позволяет это очень удобно делать в коде приложения, а не в хранимках или текстовых запросах в DAL, но только для выборок.
    Re[18]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 13.04.09 10:04
    Оценка:
    Здравствуйте, gandjustas, Вы писали:


    V>>От ООБД можно взять "типизированность" кортежей. Да и вообще, побольше бы типизированности всего. Просто есть что-то не то в том, что по union можно в один столбец явно, или по ошибке склеить числовые и строковые данные, и никто не тебе ругнётся на это.

    G>Да ну? Вообще-то компилятор запроса ругается при таком раскладе.

    Какой компилятор?
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[14]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 10:13
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>Как ни прискорбно это сознавать, но большинство разработчиков работает в сфере т.н. enterprise-приложений, а уж в них получение чего-то по id, изменение этого и запись обратно в базу — гораздо более частая операция, чем массовые изменения в базе.


    Какие руки (точнее головы), такие и решения. От области деятельности это зависит мало.
    Если человек не может не смотреть на данные как на объект, то и появляются все эти GetById().
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[15]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 10:14
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>А кто мехает для операции "получение чего-то по id, изменение этого и запись обратно в базу" использовать один Update, а не SELECT+Update+ оптимистичная блокировка+identity map+навороченный кеш?


    Менталитет.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 10:19
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>Например то, что в этой цепочке присутствует пользователь и ему надо-таки что-то показать. Для этого и нужен GetById.


    Это пользователь что ли вас по Id что-то просит получить?
    Во как?!

    Пользователь будет искать по чему угодно, только не по вашему id. Он скорее по дате поищит, или номеру договора. Получит список. В этом списке он ткнет мышкой. Тут конечно можно и GetById() вызвать, но зачем? Ведь часть данных уже выбраны. Можно выбрать только требуемые в данный момент. И select тут будет намного более удобнее. Зачем нам объект? Нам нужно содержимое договора (например).
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 10:28
    Оценка:
    Здравствуйте, Tom, Вы писали:

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


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


    G>>>>>>При таком походе getById — это будет метод, который возвращает QueryObject c нужной выборкой. Это будет вспомогательный метод для BL.

    Tom>>>>>Открою тебе секрет. Разделения на BL/DAL/*** существуют только в голове у програмистов. Реально логика всегда размазана. Причём во всех единицах деплоймента.
    G>>>>
    G>>>>Открою тебе секрет, ни в одном моем проекте, которя я создавал от начала до конца такого не было.
    Tom>>>Это фикция. Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос:
    Tom>>>update order set delayed = true where OrderDate < '...'
    Tom>>>По твоему подобный запрос не реализует часть бизнес логики?
    Tom>>>Если нет, тогда покажи мне пример на C# реализующий бизнес правило: Заказы не выполненые по любой причине в течении дня перевести в статус задержанные.
    G>>Сайчас это или foreach с объектами или SQL-запрос.
    Tom>Я написал пример. Можешь так же написать пример?
    Я слегка прогнал.

    Код будет такой:
    var delayedOrders = from o in _orderRepository.Items
                        where o.OrderDate < xxx
                        select o;

    Даже апдейты не нужны.

    G>>Если будет Linq или EF провайдер с поддержкой DML, то буду использовать только его.

    Tom>Пример можно? И где вообще ты нашёл про поддержку DML в EF 2?
    Меня в EF интересует не eSQL и Object Services, а модель провайдеров и edm.
    Сейчас в EF есть AST для представления запросов, в том числе числе insert\update\delete.
    Но нету способов сформировать ast для DML, они формируются внутри при вызове SaveChanges в контексте.
    Я сначала хотел написать методы-расширения для DML, но уперся в убогость самого средства описания модели данных — edm.
    Ко второй версии EF обещают edm поправить, и если у них не будет провайдера с DML, то напишу свой.

    G>>>>ЗЫ. Есдинственное что допускал из размазывания — перенесение некоторой части логики в функции\хранимки БД. Только с целью оптимизации.

    Tom>>>Я это уже читал. Это фикция. С вовременных приложениях, когда одна из основных задач — работа с данными, бизнес логика в любом случае будет реализовываться через запросы к БД.
    G>>Вопрос в том как формировать такие запросы.
    G>>Linq сейчас позволяет это очень удобно делать в коде приложения, а не в хранимках или текстовых запросах в DAL, но только для выборок.
    Tom>Гед пример?
    Выше.
    Re[18]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 10:29
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>То о чем ты пишешь скорее относится не SOAP, но уж совсем не к SOA.


    Нет.

    L>Первое (SOAP) — описание формата сообщений и не более того.


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

    L>Второе (SOA) — архитектурный подход к "разрезанию" логики приложений.


    Этой архитектуре 100 лет в обед. Всю жизнь она называлась клиент-сервер. Весь остальной булшит из SOA — эо банальные принципы структурного программирования.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[37]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 10:32
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Сделай чтоб работало быстро


    А он без объектов не может.

    Анекдот в тему:
    — Пошли ко мне. Телевизор посмотрим. Чайку попьем...
    — А у тебя без чая не стоит?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 10:46
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>Запросы не панацея — способ обработки данных. Его прекрасно можно использовать для обработки данных вместо дурацкого запаковывания всего и все в объекты и попыток использовать ООП для обработки данных.

    Tom>Я чего то не понимаю где я писал что буду использовать ООП?

    Как только тема переехала в Философию, сразу же подключились маньяки ОРМ-щики. Мы тут получаемся между двух огней. С одной твой лагерь который предлагает все на транзакте делать, с другой ОРМ-щики. Иногда путаешь кому что отвечать.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 10:50
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Конечно можно использовать ORM WAY но хрен редьки не слаще, а только геморней.


    А это ты Адонцу и Кибераксу объясни. Точнее они тебе сейчас объяснят .
    Они просто увлеклись покусыванием нас и не поняли, что ты с нами дискутируешь не с их позиций.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[19]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 10:50
    Оценка:
    G>Даже апдейты не нужны.
    Не понял, в задаче чётко сказано Заказы не выполненые по любой причине в течении дня перевестись в статус задержанные.
    У тебя вижу только селект.

    G>>>Если будет Linq или EF провайдер с поддержкой DML, то буду использовать только его.

    Tom>>Пример можно? И где вообще ты нашёл про поддержку DML в EF 2?
    G>Меня в EF интересует не eSQL и Object Services, а модель провайдеров и edm.
    G>Сейчас в EF есть AST для представления запросов, в том числе числе insert\update\delete.
    Какой нафик AST и причём он к EF? И где ты взял что они будут сильно менять edm?
    Максимум — переделают работу с relation-ами.

    G>Но нету способов сформировать ast для DML, они формируются внутри при вызове SaveChanges в контексте.

    G>Я сначала хотел написать методы-расширения для DML, но уперся в убогость самого средства описания модели данных — edm.
    G>Ко второй версии EF обещают edm поправить, и если у них не будет провайдера с DML, то напишу свой.
    DML — я нет и не будет, и здаётся мне что задача написать такой провайдер сама по себе не простая.
    Ибо даже на сегодняшний день ни у одного комерчвеского linq решения она не реализована.

    G>Выше.

    Выше вижу селект. задача была обновить state.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[17]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 10:53
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос:

    Tom>update order set delayed = true where OrderDate < '...'
    Tom>По твоему подобный запрос не реализует часть бизнес логики?

    Это именно запрос реализующий часть бизнес-логики.
    И что?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[19]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 10:55
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Именно, нестрогая, да еще и динамическая типизация. И не только у MS SQL, практически у всех популярных СУБД.


    Осталось доказать это утверждение.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 10:57
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    Tom>>Конечно можно использовать ORM WAY но хрен редьки не слаще, а только геморней.


    VD>А это ты Адонцу и Кибераксу объясни. Точнее они тебе сейчас объяснят .

    VD>Они просто увлеклись покусыванием нас и не поняли, что ты с нами дискутируешь не с их позиций.
    ну моя позиция чёткая — ORM зло. Максимум — это мапинг. остальное средствами БД. Тоесть коллекции и работа в коде с relation-ами идут в лес.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[18]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 10:57
    Оценка:
    VD>Как только тема переехала в Философию, сразу же подключились маньяки ОРМ-щики. Мы тут получаемся между двух огней. С одной твой лагерь который предлагает все на транзакте делать, с другой ОРМ-щики. Иногда путаешь кому что отвечать.

    Мне Ромина позиция вообще не понятна если честно. Он же со всеми не согласен (c)
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[19]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 10:57
    Оценка:
    Это... не оверквоть так сильно...
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[18]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 10:59
    Оценка:
    VD>Это именно запрос реализующий часть бизнес-логики.
    VD>И что?

    То, что часть логики всегда будет реализована с использованием запросов БД.
    И это не вселенское зло а нормальная ситуация.
    И в этом случае бизнес логика размазывается не только по слоям но и по компонентам деплоймента.
    И это тоже не зло а нормальная ситуация.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[19]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 11:03
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Сейчас в EF есть AST для представления запросов, в том числе числе insert\update\delete.


    Как понимать выделенное?

    G>Я сначала хотел написать методы-расширения для DML, но уперся в убогость самого средства описания модели данных — edm.

    G>Ко второй версии EF обещают edm поправить, и если у них не будет провайдера с DML, то напишу свой.

    edm тут ровным счетом не причем. Проблема в том, что DML должен поддерживать массовые операции (типа "insert int x select ..."). Так вот проблема в том, что в linq-запросах на выборку теряется часть метаинформации нежной для связи запроса на выборку с запросом на вставку или обновление. Если будет собственный провайдер, то проблема будет решена. В прочем, возможно с небольшими хаками можно реализовать все и для существующих провадеров.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 11:19
    Оценка:
    Здравствуйте, Tom, Вы писали:

    G>>Даже апдейты не нужны.

    Tom>Не понял, в задаче чётко сказано Заказы не выполненые по любой причине в течении дня перевестись в статус задержанные.
    Tom>У тебя вижу только селект.

    Я бы тоже не делал полей для таких вещей, а вычислял бы все динамически или сделал бы индексированное представление для такого правила.

    Но это уже обсуждение бизрес-логики.

    Если наплевать на правильность постановки задачи, то даже сегодня можно было бы написать что-то типа:
    var delayedOrders = from o in orders
                        where o.OrderDate < xxx
                        select o;
    delayedOrders.Update(o => o.delayed, true);
    // delayedOrders.Update(o => Set(o.delayed, true));

    Все это будет преобразовано во время выполнения в update который привел ты.
    Хорошим решением было бы сделать так:
    var delayedOrders = from o in orders
                        where o.OrderDate < xxx
                        select o;
    delayedOrders.Update(o => o.delayed = true);

    Но деревья выражений не поддерживают присвоений.

    Кстати, в Nemerle это можно было бы эмулировать. Более того в Nemerle можно и синтаксис прикрутить. Тогда можно будет писать так:
    from   o in orders
    where  o.OrderDate < xxx
    update o.delayed   = true
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 11:26
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    G>>Сейчас в EF есть AST для представления запросов, в том числе числе insert\update\delete.


    VD>Как понимать выделенное?

    См System.Data.Common.CommandTrees в сборке System.Data.Entity в частности DbUpdateCommandTree, DbInsertCommandTree, DbDeleteCommandTree.
    Для всех написано что представляет из себя single-row operation, но это уже на совести генератора SQLя в провайдере к конкретной БД.


    G>>Я сначала хотел написать методы-расширения для DML, но уперся в убогость самого средства описания модели данных — edm.

    G>>Ко второй версии EF обещают edm поправить, и если у них не будет провайдера с DML, то напишу свой.

    VD>edm тут ровным счетом не причем.

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

    VD>Проблема в том, что DML должен поддерживать массовые операции (типа "insert int x select ..."). Так вот проблема в том, что в linq-запросах на выборку теряется часть метаинформации нежной для связи запроса на выборку с запросом на вставку или обновление. Если будет собственный провайдер, то проблема будет решена. В прочем, возможно с небольшими хаками можно реализовать все и для существующих провадеров.

    Запросы вида insert ... select .. дейсвтительно не поддерживаются никак, короче дождусь второй версии EF, там буду думать.
    Re[19]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 11:28
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Мне Ромина позиция вообще не понятна если честно. Он же со всеми не согласен (c)


    Киберак с Рома — это классические ОРМ-щики. Они в основном разговаривают о распределенных когерентных кэшах и ООП.

    Их головы просто не настраиваются на разговор вне контекста объектов. Они так видят (с)
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 11:30
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Хорошим решением было бы сделать так:

    VD>
    VD>var delayedOrders = from o in orders
    VD>                    where o.OrderDate < xxx
    VD>                    select o;
    VD>delayedOrders.Update(o => o.delayed = true);
    VD>

    VD>Но деревья выражений не поддерживают присвоений.

    Вместо присвоений можно использовать NewExpression или сделать fluent-интерфейс с последовательным вызовом методов set(p => p.field == value)
    Re[19]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 11:33
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    L>>Второе (SOA) — архитектурный подход к "разрезанию" логики приложений.

    VD>Этой архитектуре 100 лет в обед. Всю жизнь она называлась клиент-сервер. Весь остальной булшит из SOA — эо банальные принципы структурного программирования.
    мы о сильно разных SOA разговариваем.
    Re[21]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 11:33
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Запросы вида insert ... select .. дейсвтительно не поддерживаются никак, короче дождусь второй версии EF, там буду думать.


    Мне кажется проще EF в топку и создать свой провайдер. IT этим как раз занимается.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 11:37
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>мы о сильно разных SOA разговариваем.


    Я говорю о SOA.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[21]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 11:42
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    G>>мы о сильно разных SOA разговариваем.


    VD>Я говорю о SOA.

    Угу, попытался найти ссылки про принципы SOA, которые еще называют Soa triangle, но половина у меня не открылась, а вторая половина показала маркетологический булшит.
    Re[19]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 11:54
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>Это именно запрос реализующий часть бизнес-логики.

    VD>>И что?

    Tom>То, что часть логики всегда будет реализована с использованием запросов БД.

    Tom>И это не вселенское зло а нормальная ситуация.
    Это очень даже правильно.

    Tom>И в этом случае бизнес логика размазывается не только по слоям но и по компонентам деплоймента.

    Tom>И это тоже не зло а нормальная ситуация.
    А это совсем неправльно. Не надо БЛ прибивать гвоздями к базе. Пусть база занимается выполнением запросов, поддержанием целостности БД, конкурентным доступом и собственно хранением данных.
    Запросы должны формироваться более высокими уровнями.
    Re[31]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 12:22
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    A>>Голословное утверждение. Каким образом чтение и последущий отсев данных улучшает безопасность по сравнению с запретом чтения?

    KV>Зачем читать все, чтобы потом отсеять?

    Ну как же, у тебя отсев ведь в BL, то есть после работы DAL

    A>>И как оно работает?

    KV>Вполне. И мне страшно подумать, как решались бы вопросы масштабирования и плохих каналов (плохой == < 10Мбит), если бы в лотусе не было этой "особенности". С чем собственно мы и столкнулись в 1С, и из-за чего с нее, в итоге, и свалили.

    Владимир, несчастье 1С постигло и меня. При некоторой сноровке его вполне можно реплицировать. На самом деле репликация SQL Server (впрочем как и доставка журналов) достаточно толерантна к приложениям.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[43]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 12:24
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>>>У вас проверки RLS не в коде?

    A>>Да, они в хранимках.
    G>От того что часть логики помещена в хранимки она логикой быть не перестает.
    G>Зато теперь понятно почему тебе так не нравятся запросы, используя хранимки для CRUD использование запросов становится неудобным и почти ненужным.

    Ещё раз. проверка доступа это не логика, это инфрастурктурный сервис. Логика приложения может выражаться в раздаче прав доступа, проверка — операция универсальная, никак не связанная со структурой строки таблицы.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[43]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 12:25
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    A>>Да, они в хранимках.

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

    Ты уточни о каких именно событиях говоришь, я тебе отвечу.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[5]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 12:26
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    KV>Если этот Id получен от пользователя (как в случае с примером о теме форума, удаленной модератором, например), то отсутствие в БД того, чей Id якобы передал в запросе пользователь должно быть ожидаемой ситуацией, а не исключительной. Потому как в Id в этом случае, может быть вообще все что угодно , а пользователи — они разные бывают


    Я уже ответил, что конкретно в случае форума, сообщения надо не удалять, а помечать как удалённые. Удалённые сообщения на этом форуме не видны там, откуда их удалили, но видны при доступе по ID и в форуме Мусорка. Задача вообще какая-то искуственная.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[23]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 12:30
    Оценка:
    Здравствуйте, VladD2, Вы писали:


    A>>Влад, если нечего сказать по существу, то лучше вообще не писать,

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

    Клиентский кеш имеет к делу то простое отношение, что ты не смог со своим мегаметодом решить простейшую практическую задачу и тупо слил, прикрываясь оффтопиком.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[44]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 12:35
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>>>У вас проверки RLS не в коде?

    A>>>Да, они в хранимках.
    G>>От того что часть логики помещена в хранимки она логикой быть не перестает.
    G>>Зато теперь понятно почему тебе так не нравятся запросы, используя хранимки для CRUD использование запросов становится неудобным и почти ненужным.

    A>Ещё раз. проверка доступа это не логика, это инфрастурктурный сервис. Логика приложения может выражаться в раздаче прав доступа, проверка — операция универсальная, никак не связанная со структурой строки таблицы.


    Инфраструктурный сервис логикой не является?
    Ведь его приходится самому писать, этот сервис БД не дает забесплатно.
    Re[6]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 12:40
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    KV>>Если этот Id получен от пользователя (как в случае с примером о теме форума, удаленной модератором, например), то отсутствие в БД того, чей Id якобы передал в запросе пользователь должно быть ожидаемой ситуацией, а не исключительной. Потому как в Id в этом случае, может быть вообще все что угодно , а пользователи — они разные бывают


    A>Я уже ответил, что конкретно в случае форума, сообщения надо не удалять, а помечать как удалённые. Удалённые сообщения на этом форуме не видны там, откуда их удалили, но видны при доступе по ID и в форуме Мусорка. Задача вообще какая-то искуственная.


    Задача очень даже естественная, если кто-то зайдет и запостит педофильское порно, то такой пост сразу вытрут без всяки "мусорок".
    Мусорка в данном случае — искуственный костыль непонятно для чего.

    Далеко не всегда возможно забороть несогласованность данных, попытки делать это приводит к распухнию решения (в такой задаче уже появилась "мусорка" и флаг удаления).
    Re[45]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 12:54
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Инфраструктурный сервис логикой не является?

    G>Ведь его приходится самому писать, этот сервис БД не дает забесплатно.

    Понимаешь, в протоколе HTTP тоже есть какая-то логика, но мы ведь не называем веб-сервис бизнес-логикой. Да, самому писать не приходится, я же БД генерирую, ты забыл
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[7]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 12:56
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Задача очень даже естественная, если кто-то зайдет и запостит педофильское порно, то такой пост сразу вытрут без всяки "мусорок".


    Зачем? Можно сделать спец-форум в который ни у кого не будет доступа.

    G>Мусорка в данном случае — искуственный костыль непонятно для чего.


    Мусорка это очень правильное решение. Из БД нельзя данные стирать.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[22]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 12:58
    Оценка:
    G>Угу, попытался найти ссылки про принципы SOA, которые еще называют Soa triangle, но половина у меня не открылась, а вторая половина показала маркетологический булшит.
    А что там за принципы могут быть кроме явной границы сервисов?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[38]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 13:00
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    IT>>Сделай чтоб работало быстро

    C>Дык уже. С помощью идеологически неправильного антисоветского ORM

    Молодец. А могло бы получится даже лучше.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[23]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 13:04
    Оценка:
    Здравствуйте, Tom, Вы писали:

    G>>Угу, попытался найти ссылки про принципы SOA, которые еще называют Soa triangle, но половина у меня не открылась, а вторая половина показала маркетологический булшит.

    Tom>А что там за принципы могут быть кроме явной границы сервисов?

    Там много булшита. Люди же за это дело премии получали.

    В принципе, конечно не плохо, что даже самые простые принципы оформлены формально. Плохо, что из этого пытаются создать религию.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: Проблемы организации OR-мапинга
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 13.04.09 13:09
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    KV>>Если этот Id получен от пользователя (как в случае с примером о теме форума, удаленной модератором, например), то отсутствие в БД того, чей Id якобы передал в запросе пользователь должно быть ожидаемой ситуацией, а не исключительной. Потому как в Id в этом случае, может быть вообще все что угодно , а пользователи — они разные бывают


    A>Я уже ответил, что конкретно в случае форума, сообщения надо не удалять, а помечать как удалённые. Удалённые сообщения на этом форуме не видны там, откуда их удалили, но видны при доступе по ID и в форуме Мусорка. Задача вообще какая-то искуственная.


    Да фиг с ними, с темами форума. Что произойдет (на каждом из слоев приложения), если пользователь в качестве ID пришлет что-нибудь типа

    ?ID='||'6


    ?

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[17]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 13:10
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Можем перейти к примерам (оставим розового слоника в покое ).


    Что это тебя вдруг от слоника или розового цвета начало колбасить?

    Tom>Вот допустим выполняешь ты запрос:

    Tom>update order set delayed = true where OrderDate < '...'
    Tom>По твоему подобный запрос не реализует часть бизнес логики?

    Логика, даже бизнес, и что давай теперь сюда ещё и императив притащим, раз пошла такая пьянка? Ты пойми простую вещь, DAL, BL и прочие слои придумали не просто так. Они реально помогают жить, но только при одном условии — если это вполне осознаваемые сущности со строго очерченными функциями, а не только названия классов и умный вид перед начальством и коллегами, а в голове всё равно каша (как у Ромы).
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[20]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 13.04.09 13:12
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    Tom>>Мне Ромина позиция вообще не понятна если честно. Он же со всеми не согласен (c)

    VD>Киберак с Рома — это классические ОРМ-щики. Они в основном разговаривают о распределенных когерентных кэшах и ООП.
    Ага.

    VD>Их головы просто не настраиваются на разговор вне контекста объектов. Они так видят (с)

    Мне ещё в последнее время интересны документно-ориентированные базы типа CouchDB. Что-то в них есть...
    Sapienti sat!
    Re[34]: Проблемы организации OR-мапинга
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 13.04.09 13:17
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>У меня ORM. Т.е. объектная модель, построена на основе РБД.

    C>У меня не SQL-сервер, а моя система смотрит наружу.

    А у меня — смутное ощущение, что ты надо мной издеваешься


    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[7]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 13:18
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    KV>Да фиг с ними, с темами форума. Что произойдет (на каждом из слоев приложения), если пользователь в качестве ID пришлет что-нибудь типа

    KV>
    KV>?ID='||'6
    KV>

    KV>?

    Ещё в Presentation будет облом, во время попытки сконвертировать '||'6 в число.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[32]: Проблемы организации OR-мапинга
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 13.04.09 13:19
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Голословное утверждение. Каким образом чтение и последущий отсев данных улучшает безопасность по сравнению с запретом чтения?

    KV>>Зачем читать все, чтобы потом отсеять?

    A>Ну как же, у тебя отсев ведь в BL, то есть после работы DAL


    Нет. У меня ничего не мешает BL'у запросить у DAL'а изначально тот набор данных, на которые у текущего пользователя есть права, скажем просмотра

    A>>>И как оно работает?

    KV>>Вполне. И мне страшно подумать, как решались бы вопросы масштабирования и плохих каналов (плохой == < 10Мбит), если бы в лотусе не было этой "особенности". С чем собственно мы и столкнулись в 1С, и из-за чего с нее, в итоге, и свалили.

    A>Владимир, несчастье 1С постигло и меня. При некоторой сноровке его вполне можно реплицировать. На самом деле репликация SQL Server (впрочем как и доставка журналов) достаточно толерантна к приложениям.


    Вот если бы еще и приложения были толерантны к репликации, им бы цены не было

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[8]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 13:19
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Задача очень даже естественная, если кто-то зайдет и запостит педофильское порно, то такой пост сразу вытрут без всяки "мусорок".

    A>Зачем? Можно сделать спец-форум в который ни у кого не будет доступа.

    Стереть проще будет.

    G>>Мусорка в данном случае — искуственный костыль непонятно для чего.

    A>Мусорка это очень правильное решение. Из БД нельзя данные стирать.
    Кто сказал?
    Re[44]: Проблемы организации OR-мапинга
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 13.04.09 13:21
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Да, они в хранимках.

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

    A>Ты уточни о каких именно событиях говоришь, я тебе отвечу.


    Попытки доступа пользователя к данным, на которые у него нет прав, например.

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[8]: Проблемы организации OR-мапинга
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 13.04.09 13:22
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Ещё в Presentation будет облом, во время попытки сконвертировать '||'6 в число.


    Т.е. валидация входящих данных у тебя в презентационном слое?

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[46]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 13:23
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Инфраструктурный сервис логикой не является?

    G>>Ведь его приходится самому писать, этот сервис БД не дает забесплатно.

    A>Понимаешь, в протоколе HTTP тоже есть какая-то логика, но мы ведь не называем веб-сервис бизнес-логикой. Да, самому писать не приходится, я же БД генерирую, ты забыл


    Да называть вообще можно что угодно, как угодно, суть от этого не меняется.

    Бизнес-логика, сгенерировання автоматичиски не перестает быть таковой.
    Re[21]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 13:25
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>При том что основная сложность — построение where выражений с подзапросами уже реализована.


    Основная сложность там не в where, а в select, как это не парадоксально звучит
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[33]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 13:28
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    A>>Ну как же, у тебя отсев ведь в BL, то есть после работы DAL

    KV>Нет. У меня ничего не мешает BL'у запросить у DAL'а изначально тот набор данных, на которые у текущего пользователя есть права, скажем просмотра

    Пример можно? А то слишком безпредметный разговор выходит.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[9]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 13:30
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Зачем? Можно сделать спец-форум в который ни у кого не будет доступа.

    G>Стереть проще будет.

    A>>Мусорка это очень правильное решение. Из БД нельзя данные стирать.

    G>Кто сказал?

    Из БД лучше ничего не стирать, потому что бизнес логика меняется и плохо если для новой логики нет старых данных. А ещё, хорошо, когда у тебя хранятся все версии данных, а не только последняя.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[10]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 13:35
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Зачем? Можно сделать спец-форум в который ни у кого не будет доступа.

    G>>Стереть проще будет.

    A>>>Мусорка это очень правильное решение. Из БД нельзя данные стирать.

    G>>Кто сказал?

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

    Почему плохо когда для новой логики нест старых данных?
    Прямо так все версии хранить надо?

    Вообще говоря YAGNI и KISS работает и в базах данных
    Re[45]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 13:37
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    A>>Ты уточни о каких именно событиях говоришь, я тебе отвечу.

    KV>Попытки доступа пользователя к данным, на которые у него нет прав, например.

    Такая проблема на практике не стоит, потому что если у оператора вообще нет доступа, даже на чтение, к клиенту А, то у него нет доступа к заказам клиента А, долгам клиента А и т.д. Как следствие "попытки доступа пользователя к данным, на которые у него нет прав" исполняются с вероятностью "Пользователь угадал GUID". Вот попыти выполнения запрещённых действий могут журналироваться, но это ловится выше DAL.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[47]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 13:38
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Да называть вообще можно что угодно, как угодно, суть от этого не меняется.

    G>Бизнес-логика, сгенерировання автоматичиски не перестает быть таковой.

    Это внешний по отношению к приложению сервис никак не связанный с осмыслением содержимого БД. Не понимаю, почему ты считаешь это бизнес-логикой приложения.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[22]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 13:38
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Вместо присвоений можно использовать NewExpression или сделать fluent-интерфейс с последовательным вызовом методов set(p => p.field == value)


    Мне new тоже больше импонирует.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[48]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 13:43
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Да называть вообще можно что угодно, как угодно, суть от этого не меняется.

    G>>Бизнес-логика, сгенерировання автоматичиски не перестает быть таковой.

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


    Любой код, который выполняет usecase приложения является бизнес логикой.
    Re[11]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 13:43
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Почему плохо когда для новой логики нет старых данных?


    Она тогда не работает

    G>Прямо так все версии хранить надо?


    Ну... желательно. Если есть возможность, конечно.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[12]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 13:45
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Почему плохо когда для новой логики нет старых данных?

    A>Она тогда не работает
    У меня все работает, я наверное что-то не так делаю
    Re[49]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 13:50
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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

    G>Любой код, который выполняет usecase приложения является бизнес логикой.

    Является ли логика работы прав доступа NTFS частью бизнес-логики приложения работающего с файлами?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[50]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 13:53
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

    G>>Любой код, который выполняет usecase приложения является бизнес логикой.

    A>Является ли логика работы прав доступа NTFS частью бизнес-логики приложения работающего с файлами?


    Ты доступа к этому не имеешь, поэтому разницы нету как называть.
    Re[46]: Проблемы организации OR-мапинга
    От: kochetkov.vladimir Россия https://kochetkov.github.io
    Дата: 13.04.09 14:00
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Ты уточни о каких именно событиях говоришь, я тебе отвечу.

    KV>>Попытки доступа пользователя к данным, на которые у него нет прав, например.

    A>Такая проблема на практике не стоит,


    Угу

    Области, которые
    необходимо рассмотреть, включают:

    <bla-bla-bla>


    Это выдержка из международного стандарта ISO/IEC FDIS 17799 "Информационные технологии — Методики безопасности — Практические правила управления информационной безопасностью" , раздел "Регистрация событий".

    Плюс в ряде методик оценки рисков (OCTAVE например) и требований к финансовой отчетности (SOX) есть примерно такие контроли:

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


    Хотя допускаю, что при ничтожности рисков возникновения в ИС инцидентов по ИБ, на эти контроли ориентироваться не стоит, но тем не менее...

    A>Как следствие "попытки доступа пользователя к данным, на которые у него нет прав" исполняются с вероятностью "Пользователь угадал GUID".


    Я писал о событиях отказа в доступе к этим данным.

    A>Вот попыти выполнения запрещённых действий могут журналироваться, но это ловится выше DAL.


    Что есть "запрещенные действия"?

    [Интервью] .NET Security — это просто
    Автор: kochetkov.vladimir
    Дата: 07.11.17
    Re[47]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 14:15
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    A>>Как следствие "попытки доступа пользователя к данным, на которые у него нет прав" исполняются с вероятностью "Пользователь угадал GUID".

    KV>Я писал о событиях отказа в доступе к этим данным.

    Если запрашивается список объектов, то отказ доступа это отсутствие элемента в списке. Отследить что отфильтровалось не представляется возможным, да и не надо на самом деле.
    Если запрашивается конкретный объект, от отследить факт невозврата объекта нет никакой проблемы.

    A>>Вот попыти выполнения запрещённых действий могут журналироваться, но это ловится выше DAL.

    KV>Что есть "запрещенные действия"?

    Изменение, создание, удаление данных. Что касается чтения, данные, к которым нет доступа, просто не видны.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[23]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 14:28
    Оценка:
    Здравствуйте, IT, Вы писали:

    G>>Вместо присвоений можно использовать NewExpression или сделать fluent-интерфейс с последовательным вызовом методов set(p => p.field == value)


    IT>Мне new тоже больше импонирует.


    Чем?

    На мой взгляд у такого подхода много проблем. Точнее только они и есть.
    В общем, хотелось бы услышать обоснование и примеры использования поглядеть.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 14:36
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>На мой взгляд у такого подхода много проблем. Точнее только они и есть.


    Кроме семантического несоответствия больше никаких проблем.

    VD>В общем, хотелось бы услышать обоснование и примеры использования поглядеть.


    Для твоего примера как-то так:

    (from o in orders where o.OrderDate < xxx select o).Update(new order { delayed = true });
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[25]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 15:42
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Кроме семантического несоответствия больше никаких проблем.


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

    IT>Для твоего примера как-то так:


    IT>
    IT>(from o in orders where o.OrderDate < xxx select o).Update(new order { delayed = true });
    IT>


    Ужас.

    Потом, что такое "Update(new order { delayed = true })"? Из этого даже дерево выражений не получишь, так как оно строится только для лямбды. Тебе придется писать что-то вроде:

    (from o in orders where o.OrderDate < xxx select o).Update(() => new order { delayed = true });

    Что выглядит еще более странно.

    Если учесть, что иногда нужно использовать информацию из полей изменяемого объекта, то придется передавать его через параметр:

    (from o in orders where o.OrderDate < xxx select o).Update(o => new order { delayed = !o.delayed });


    У пользователей будет ощущение, что информация о других значений из той же таблицы теряется.
    Нехорошо, как-то.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[20]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 15:54
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Киберак с Рома — это классические ОРМ-щики. Они в основном разговаривают о распределенных когерентных кэшах и ООП.

    VD>Их головы просто не настраиваются на разговор вне контекста объектов. Они так видят (с)

    Влад, если бы ты не только писал, но и читал, ты бы понял, что мне не нравятся ORM. Но, видимо, не судьба.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[20]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 13.04.09 15:57
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    V>>Именно, нестрогая, да еще и динамическая типизация. И не только у MS SQL, практически у всех популярных СУБД.


    VD>Осталось доказать это утверждение.


    Доказать что? Что даже сохранённые запросы (или спроки) компиллируются динамически, и ты не узнаешь про проблемы до запуска запроса?
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[9]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.04.09 15:59
    Оценка:
    Здравствуйте, kochetkov.vladimir, Вы писали:

    A>>Ещё в Presentation будет облом, во время попытки сконвертировать '||'6 в число.

    KV>Т.е. валидация входящих данных у тебя в презентационном слое?

    Простейшая валидация формата данных (строка может быть сконвертирована в число), да.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[18]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 16:04
    Оценка:
    IT>Логика, даже бизнес, и что давай теперь сюда ещё и императив притащим, раз пошла такая пьянка? Ты пойми простую вещь, DAL, BL и прочие слои придумали не просто так.
    Игорь, обьясни мне идиоту, гед в моём примере DAL и где BL. Я что то в даннорм случае не могу уловить границу.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[17]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 13.04.09 16:23
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Пользователь будет искать по чему угодно, только не по вашему id. Он скорее по дате поищит, или номеру договора. Получит список. В этом списке он ткнет мышкой. Тут конечно можно и GetById() вызвать, но зачем? Ведь часть данных уже выбраны. Можно выбрать только требуемые в данный момент.


    Это зависит от того, что у вас за клиент. В случае веба click по договору приведет к открытию страницы договора, а на новой странице эта инфорация уже не будет доступна и запрашивать все рано придется.

    VD>И select тут будет намного более удобнее. Зачем нам объект? Нам нужно содержимое договора (например).


    Если схема данных один-в-один соответствует entity, то будет гораздо удобнее.
    Если же DAL занимается каким-нибудь преобразованием из резалтсета в entity, то будет уже не так удобно.

    Например, некоторые параметры не хранятся один-в-один в полях таблицы, а сериализуются в xml-ную колонку. Наличие DAL-а позволяет этот механизм хранения скрыть от бизнеса, что, имхо, очень удобно и позволяет очень просто дополнять поля сущности.
    Re[26]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 16:51
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    IT>>Кроме семантического несоответствия больше никаких проблем.


    VD>На такую непосредственность и возразить-то сложно.

    VD>По-моему, семантическое несоответствие — это самое плохое, что можно было бы придумать. Приговор, я бы сказал.

    Дык у остальных решений ни соотвествия, ни вменяемой реализации.

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


    Ты молодец, сам до всего догадался

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

    VD>Нехорошо, как-то.

    Я пока других вариантов не вижу вовсе
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[19]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 16:53
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Логика, даже бизнес, и что давай теперь сюда ещё и императив притащим, раз пошла такая пьянка? Ты пойми простую вещь, DAL, BL и прочие слои придумали не просто так.

    Tom>Игорь, обьясни мне идиоту, гед в моём примере DAL и где BL. Я что то в даннорм случае не могу уловить границу.

    В твоём примере с процедурой? Так там у тебя нет ни DAL, ни BL. Только каша из TSQL.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[27]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 17:28
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Дык у остальных решений ни соотвествия, ни вменяемой реализации.


    Решение с функцией Set() мне больше нравится:
    .Update(o => Set(o.Field, o.Field + 1))


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

    VD>>Нехорошо, как-то.

    IT>Я пока других вариантов не вижу вовсе


    Согласен, что в рамках шарпа с решениями не ахти. Надо переходить на Немерле. В нем проблем не будет .
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 13.04.09 18:04
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

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


    О, как. Он не согласен.
    Re[28]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 18:37
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Решение с функцией Set() мне больше нравится:

    VD>
    VD>.Update(o => Set(o.Field, o.Field + 1))
    VD>


    А что ты тут будешь сетать? Как соотносится перечеслиние через запятую с полями, которые мы меняем?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[25]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 18:46
    Оценка:
    VD>>На мой взгляд у такого подхода много проблем. Точнее только они и есть.
    IT>Кроме семантического несоответствия больше никаких проблем.
    Игорь, заведи тетрадочку

    Как напишешь — будет интересно гемор-ноутсы почитать
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[20]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 18:46
    Оценка:
    IT>В твоём примере с процедурой? Так там у тебя нет ни DAL, ни BL. Только каша из TSQL.
    Хорошо, приведи пример где не будет каши и где всё будет сделано правильно.
    И если можно покажи там разделение на слои.

    PS:
    Не понял где там каша, вроде был один TSQL запрос
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[26]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 19:00
    Оценка:
    Здравствуйте, Tom, Вы писали:

    VD>>>На мой взгляд у такого подхода много проблем. Точнее только они и есть.

    IT>>Кроме семантического несоответствия больше никаких проблем.
    Tom>Игорь, заведи тетрадочку

    Я могу сделать хоть так, хоть сяк, хоть наперекосяк. Как скажешь, так и сделаю. А ты так можешь?

    Tom>Как напишешь — будет интересно гемор-ноутсы почитать


    Форум рядом, иди читай
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[27]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 13.04.09 19:03
    Оценка:
    IT>Я могу сделать хоть так, хоть сяк, хоть наперекосяк. Как скажешь, так и сделаю. А ты так можешь?
    (( Я же серьёзно. Хочу понять как с твоей точки зрения будет правильно.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[21]: Проблемы организации OR-мапинга
    От: SleepyDrago Украина  
    Дата: 13.04.09 19:04
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    VD>>Киберак с Рома — это классические ОРМ-щики. Они в основном разговаривают о распределенных когерентных кэшах и ООП.

    VD>>Их головы просто не настраиваются на разговор вне контекста объектов. Они так видят (с)

    A>Влад, если бы ты не только писал, но и читал, ты бы понял, что мне не нравятся ORM. Но, видимо, не судьба.


    Дело не в том что у него "одноразовые объекты для бедных" и он не понимает мощи ооп.

    Проблема в том, что ооп не понимает почти никто, кроме программистов.

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

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

    Та же проблема с безопасностью. Какая степень дублирования нужна чтобы при отзыве прав с объекта бд транзитивно обновились все кеши объектов?

    то есть мне не понятно как вы для себя решили проблему отображения объекты логики <-> сущности бд.
    Re[29]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 19:40
    Оценка:
    Здравствуйте, IT, Вы писали:

    VD>>Решение с функцией Set() мне больше нравится:

    VD>>
    VD>>.Update(o => Set(o.Field, o.Field + 1))
    VD>>


    IT>А что ты тут будешь сетать? Как соотносится перечеслиние через запятую с полями, которые мы меняем?


    Первый параметр задает "что устанавливать". Второй "новое значение". Мне кажется это очевидно.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[23]: Проблемы организации OR-мапинга
    От: SleepyDrago Украина  
    Дата: 13.04.09 19:43
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Не без ограничений обошлось, конечно. ..

    Спасибо. Теперь я примерно представляю ограничения и границы применимости этого подхода.
    Подход IT погуманнее будет к легаси БД, но там много "полунаписанных" инструментов, еше не прошедших серьезного испытания временем
    Узнал для себя немало нового , так что спасибо Tom, что затеял это пожарище.
    Re[28]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 19:48
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>Я могу сделать хоть так, хоть сяк, хоть наперекосяк. Как скажешь, так и сделаю. А ты так можешь?

    Tom>(( Я же серьёзно. Хочу понять как с твоей точки зрения будет правильно.

    Сложно сказать как будет правильно. Вот так
    Автор: IT
    Дата: 06.09.06
    в теории. Так
    Автор: IT
    Дата: 17.01.03
    начинались первые попытки воплотить это на практике 6 лет назад. Сегодня это выглядело бы как-то так:

    public class CustomerInfo
    {
        public string FirstName;
        public string LastName;
    }
    
    public class CustomerManager
    {
        public CustomerInfo GetCusomerInfo(int @id)
        {
            return CustomerAccessor.CreateInstance().GetCusomerInfo(id);
        }
    }
    
    public abstract class CustomerAccessor : DataAccessor
    {
        [SqlQuery(@"
            SELECT FirstName, LastName
            FROM Customer
            WHERE ID_Customer=@id")]
        public abstract CustomerInfo GetCusomerInfo(int id);
    }


    А завтра я хочу от всего этого избавиться и писать так:

    public class Form1
    {
        private TextBox cusomerId;
        private TextBox firstName;
        private TextBox lastName;
    
        public void MyButton_OnClick(object sender, EventArgs e)
        {
            try 
            {
                int id = Convert.ToInt32(cusomerId.Text);
    
                    
                using (var db = new DbManager())
                {
                    var q = (from c in db.Customer where c.ID = id select c).First();
    
                    firstName.Text = q.FirstName;
                    lastName. Text = q.LastName;
                }
            }
            catch (Exception ex)
            {
                MessageBox.Show(ex.Message);
            }
        }
    }


    Одним словом, назад в будущее
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[30]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 19:50
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Первый параметр задает "что устанавливать". Второй "новое значение". Мне кажется это очевидно.


    А для двух полей как будет?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[30]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 19:52
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    Кстати, Здесь один мужик тоже пытается эту проблему как-то решить.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[21]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 13.04.09 21:00
    Оценка:
    Здравствуйте, Tom, Вы писали:

    IT>>В твоём примере с процедурой? Так там у тебя нет ни DAL, ни BL. Только каша из TSQL.

    Tom>Хорошо, приведи пример где не будет каши и где всё будет сделано правильно.
    Tom>И если можно покажи там разделение на слои.
    Есть большая проблема в примерах архитектуреных решений. Маленькие примеры непоказательны, а в больших трудно разобраться, да и многие преимущества и недостатки неочевидны.

    Tom>PS:

    Tom>Не понял где там каша, вроде был один TSQL запрос
    Попробуй просто описать что метод делает. Не общее описание, а вкратце алгоритм, за что отвечают параметеры, что возвращается.
    Re[29]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 13.04.09 21:10
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>public abstract class CustomerAccessor : DataAccessor

    IT>{
    IT> [SqlQuery(@"
    IT> SELECT FirstName, LastName
    IT> FROM Customer
    IT> WHERE ID_Customer=@id")]
    IT> public abstract CustomerInfo GetCusomerInfo(int id);
    IT>}
    IT>[/c#]

    А давно стало возможным так вопросы задавать? А то я как-то читал статью по BLT (2006 год) там такого не было.

    Скажи, а как ты относишься к ХП (а то у тебя запрос в коде) и почему именно так.

    IT>А завтра я хочу от всего этого избавиться и писать так:


    IT> public void MyButton_OnClick(object sender, EventArgs e)

    IT> {
    IT> try
    IT> {
    IT> int id = Convert.ToInt32(cusomerId.Text);
    IT> using (var db = new DbManager())
    IT> {
    IT> var q = (from c in db.Customer where c.ID = id select c).First();

    IT> firstName.Text = q.FirstName;

    IT> lastName. Text = q.LastName;
    IT> }
    IT> }

    Я думаю что одно из назначений DAL еще и в повышении повторного использовании кода. Один dal-метод может использоваться из разных мест в бизнес-логике. Не думаешь что такой вот подход с отказом от DAL будет провоцировать дублирование кода?
    Re[30]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 13.04.09 21:14
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>А давно стало возможным так вопросы задавать? А то я как-то читал статью по BLT (2006 год) там такого не было.


    запросы ***

    PS. Может все-таки обсудим редактирование сообщений? Раз вы так опасаетесь разведения флейма, отказа от своих слов и т.д. (это точно не параноя и преждевременные опасения?), то ведь возможны варианты: к примеру возможность редактирование в течение небольшого времени после отправки сообщения или давать возможность редактирования старым участникам форума или людям с определенным рейтингом?
    Re[22]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 13.04.09 22:10
    Оценка:
    Сохраненные запросы aka спроки — это конечно мощно
    Re[22]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 13.04.09 23:11
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Какая прелесть "сохранённые запросы"?! Сам придумал, сам обсуждает.


    Не обязательно блистать невежеством, в один базах это называется "view", в других "сохранённый запрос".

    VD>По-твоему зачем в таблицах описываются типы данных колонок?


    Покажи мне типы тут:
    select a+1 a1, b from c

    Тип a1 какой?
    Число, строка, дата?

    Как насчёт того, что в джоинах по некоей паре полей мы можем (по ошибке или намеренно) связываться даже в случае несовместимых типов этих полей (например, строки и числа)?

    VD>Статическая типизация — это когда типы выражений известны до выполнения. И для SQL-я это всегда так.


    И что есть "выполнение" для СУБД? Выполнение конкретного запроса? А как насчёт статической проверки всего вообще до запуска любых запросов, т.е. до поднятия базы? Как ни крути, а нарваться на несоответствие типов при некоем касте мы можем зачастую только в "run-time", в случае везения — на юнит тестах.
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[23]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 13.04.09 23:16
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>Сохраненные запросы aka спроки — это конечно мощно


    Для расширения кругозора — в некоторых базах их называют "сохранённые запросы с параметрами". Мне тоже смешно.
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[30]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 13.04.09 23:31
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>А давно стало возможным так вопросы задавать? А то я как-то читал статью по BLT (2006 год) там такого не было.


    Года два как минимум. Абстрактные аксессоры сейчас доведены до состояния, когда фантазии чтобы ещё сделать уже не хватает.

    MC>Скажи, а как ты относишься к ХП (а то у тебя запрос в коде) и почему именно так.


    ХП тоже поддерживаются в лучшем виде. Для вызова ХП достаточно НЕ указать атрибут с SQL. Тогда будет сгенерирован вызов ХП соответствующий сигнатуре метода.

    Также можно положить код SQL во внешний файл и подбирать его оттуда в зависимости от провайдера, если хочется.

    MC>Я думаю что одно из назначений DAL еще и в повышении повторного использовании кода. Один dal-метод может использоваться из разных мест в бизнес-логике. Не думаешь что такой вот подход с отказом от DAL будет провоцировать дублирование кода?


    Не знаю у кого как, а в моей практике эта повторность получается мизирной. А если всё-таки она нужна, то никто ничего не запрещает повторно использовать. На здоровье. А вот избавиться от мусора в виде path-through слоёв было бы очень заманчиво. Я пока интенсивно этот подход не использовал, так что сам не знаю что из этого выйдет, но пока никаких проблем не вижу.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[31]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 13.04.09 23:36
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Не знаю у кого как, а в моей практике эта повторность получается мизирной. А если всё-таки она нужна, то никто ничего не запрещает повторно использовать. На здоровье. А вот избавиться от мусора в виде path-through слоёв было бы очень заманчиво. Я пока интенсивно этот подход не использовал, так что сам не знаю что из этого выйдет, но пока никаких проблем не вижу.


    Скажи, а какой бы подход в работе с БД ты бы выбрал в случае не-MSSQL? Я так понимаю что как раз твой BLT?
    Re[24]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 13.04.09 23:44
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Для расширения кругозора — в некоторых базах их называют "сохранённые запросы с параметрами". Мне тоже смешно.


    Что за чудо природы (приветствуются ссылки)? Это случаем не прекомпилированные запросы?

    Кстати, для расширения кругозора... Параметризация и прекомпиляция (равно как и сохранение запросов где угодно) — это особенности конкретного API конкретного сервера. В SQL все это не входит. Ну, и параметризация или компиляция не оказывает никакого влияния на типизированность SQL.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[23]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.09 00:06
    Оценка:
    Здравствуйте, vdimas, Вы писали:

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


    VD>>Какая прелесть "сохранённые запросы"?! Сам придумал, сам обсуждает.


    V>Не обязательно блистать невежеством, в один базах это называется "view", в других "сохранённый запрос".


    О как? И ссылки приведешь?
    А view — название стандартизированное.
    Ну, да ладно. Считай вывернулся.

    Какое отношение представления имеют к нетипизированности SQL?

    VD>>По-твоему зачем в таблицах описываются типы данных колонок?


    V>Покажи мне типы тут:

    V>
    V>select a+1 a1, b from c
    V>

    V>Тип a1 какой?
    V>Число, строка, дата?

    Залезь в описание таблицы "c" и посмотри тип колонки "a1". select — это банальная проекция.
    C# ты ведь знаешь? Вот тебе аналогичный пример на C#:
    var x = c.a1;

    какой тут тип у "x"?
    Чтобы ответить на этот вопрос нужно знать тип поля a1. Это называется примитивным выводом типа.
    Любой SQL-сервер умеет это делать на раз.

    V>Как насчёт того, что в джоинах по некоей паре полей мы можем (по ошибке или намеренно) связываться даже в случае несовместимых типов этих полей (например, строки и числа)?


    Это называется вольное обращение с автоматическим приведением типов. Встречается сплошь и рядом в весьма типизированных языках. Например, в Васике. Да что там Васик? Шарп и тот этим не брезгует, хотя и более аккуратно.
    SQL-ем это не прудсматривается — это поведение конкретного сервера.

    Собственно к делу это тоже не относится. Ведь кто-то утверждал (серьезно так), что SQL, дескать, динамически типизирован. Причем (хотя причем тут это вообще не ясно) не только не только MS SQL, практически у всех популярных СУБД.

    Вот я и хочу увидеть обоснование этой гипотезы. Если оно будет, в чем я сильно сомневаюсь, то можно будет обсудить остальные выводы.

    VD>>Статическая типизация — это когда типы выражений известны до выполнения. И для SQL-я это всегда так.


    V>И что есть "выполнение" для СУБД?


    Тебе и такие вещи нужно разжёвывать?
    ОК. Выполнение — это когда серверу делают запрос и он возвращает в ответ результирующее множество.

    V> Выполнение конкретного запроса? А как насчёт статической проверки всего вообще до запуска любых запросов, т.е. до поднятия базы?


    А, никак. Нет никакого "всего". То как работает конкретный сервер отдается на его усмотрение.

    V>Как ни крути, а нарваться на несоответствие типов при некоем касте мы можем зачастую только в "run-time", в случае везения — на юнит тестах.


    Ну, вам магам виднее.
    Если серьезно, то приведение типов — это операция которая и в статически-типизированных языках может привести к ошибкам времени выполнения.
    Вот простой пример:
    object x = 1;
    string y = (string)x;

    В природе есть языки которые не допускают опасных приведений типов, но пользоваться ими крайне не просто.

    Опять же к делу это отношения не имеет.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[24]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 14.04.09 00:57
    Оценка:
    Здравствуйте, VladD2, Вы писали:


    VD>О как? И ссылки приведешь?


    На MS Access, например?

    VD>Залезь в описание таблицы "c" и посмотри тип колонки "a1". select — это банальная проекция.

    VD>C# ты ведь знаешь? Вот тебе аналогичный пример на C#:
    VD>
    VD>var x = c.a1;
    VD>

    VD>какой тут тип у "x"?
    VD>Чтобы ответить на этот вопрос нужно знать тип поля a1. Это называется примитивным выводом типа.
    VD>Любой SQL-сервер умеет это делать на раз.

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

    V>>Как насчёт того, что в джоинах по некоей паре полей мы можем (по ошибке или намеренно) связываться даже в случае несовместимых типов этих полей (например, строки и числа)?


    VD>Это называется вольное обращение с автоматическим приведением типов. Встречается сплошь и рядом в весьма типизированных языках. Например, в Васике.


    Это называется динамическая типизация, вообще-то. VB это умеет без явной аннотации.


    VD>Собственно к делу это тоже не относится. Ведь кто-то утверждал (серьезно так), что SQL, дескать, динамически типизирован. Причем (хотя причем тут это вообще не ясно) не только не только MS SQL, практически у всех популярных СУБД.


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

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


    Привёл пример из уровня "0" использования БД, там обосновывать нечего.

    V>> Выполнение конкретного запроса? А как насчёт статической проверки всего вообще до запуска любых запросов, т.е. до поднятия базы?


    VD>А, никак. Нет никакого "всего". То как работает конкретный сервер отдается на его усмотрение.


    Вот, и я всего лишь предложил перенять практику некоторых ООБД-серваков, которые проверяют целостность по типам перед запуском. Теперь понятно, что имелось ввиду?

    V>>Как ни крути, а нарваться на несоответствие типов при некоем касте мы можем зачастую только в "run-time", в случае везения — на юнит тестах.


    VD>Ну, вам магам виднее.

    VD>Если серьезно, то приведение типов — это операция которая и в статически-типизированных языках может привести к ошибкам времени выполнения.
    VD>Вот простой пример:
    VD>
    VD>object x = 1;
    VD>string y = (string)x;
    VD>

    Тут тоже классика динамической типизации.

    Но вот такой код даже не скомпилится:
    int x=1;
    string y=(string)x;


    Я предлагаю выдавать ошибку и для SQL-серверов перед запуском базы.

    ---------------
    На самом деле мое предложение нелепо по другим причинам: в любой базе можно изменять структуру, создавать/удалять объекты базы прямо по ходу пьесы. Отсюда — динамический характер работы и принципиальная невозможность той самой "статической типизации всего".

    Тем не менее, появились возможности задавать табличные ф-ии и прочее в этом направлении, что позволяет уже сегодня обходится в алгоритмах без временных таблиц вообще. А создавать/удалять/изменять структуру объектов, кроме временных, как был моветон во все времена, так и будет. Всвязи с этим и высказался, что неплохо бы пересмотреть самый общий сценарий работы с БД в направлении повышения "статичности по типам", раз мы можем отказаться от временных объектов.

    VD>В природе есть языки которые не допускают опасных приведений типов, но пользоваться ими крайне не просто.


    Да, хаскелисты тоже так считают. Хотя, полиморфизм по алгебраическим типам — это опять же и снова классика динамической типизации.
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[31]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.09 00:59
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>А для двух полей как будет?


    Update(o => { Set(o.Field1, o.Field1 + 1); Set(o.Field2, o.Field2 + 1) })
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[32]: Проблемы организации OR-мапинга
    От: Sinix  
    Дата: 14.04.09 01:05
    Оценка:
    Здравствуйте, VladD2.

    IT>>А для двух полей как будет?


    VD>
    VD>Update(o => { Set(o.Field1, o.Field1 + 1); Set(o.Field2, o.Field2 + 1) })
    VD>


    Сорри что вмешиваюсь, но в варианте Влада лямбды не выходит. Лучше по старинке:

    Update(o => Set(o.Field1, o.Field1 + 1)).Update(o => Set(o.Field2, o.Field2 + 1));
    Re[18]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.09 01:14
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>Это зависит от того, что у вас за клиент. В случае веба click по договору приведет к открытию страницы договора, а на новой странице эта инфорация уже не будет доступна и запрашивать все рано придется.


    Ага. Но зачем мне получать объект по id? Я лучше получу всю нужную информацию отображаемую на странице. При этом я не хочу вынимать лишнюю информацию. Запрос же объекта по идентификатору — это неэффективное вынимание данных — запрос данных наобум.

    VD>>И select тут будет намного более удобнее. Зачем нам объект? Нам нужно содержимое договора (например).


    L>Если схема данных один-в-один соответствует entity, то будет гораздо удобнее.

    L>Если же DAL занимается каким-нибудь преобразованием из резалтсета в entity, то будет уже не так удобно.

    Если нужны преобразования, то не трудно написать функцию. Но зато в 99% случаев ты просто напишешь запрос который вынет те данные которые реально нужны. При этом не прийдется думать о ленивой загрузке, операжающей загрузке, кэшировании и т.п. Ты просто вынешь нужные тебе сейчас данные.

    ЗЫ

    Более сложный вопрос — это автоматизация записи изменений. Но и тут все решаемо.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[25]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 14.04.09 01:34
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>На MS Access, например?


    Не очень, так как это не SQL-сервер. Но хотя бы на него. А то я почему-то никогда не слышал такой терминалогии. Там запросы назывались просто query.

    V>О нет, мы можем изменить тип колонки в "с" и запустить запрос заново.


    Измени... запусти. Увидишь, что тип результата изменился.

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


    Дык есть она там. Типы задаются явно при описании таблиц и выводятся в запросах.
    Вот здесь описан макрос Nemerle который во время компиляции выполняет запрос, получает информацию о типах возвращаемых значений и на ее основании генерирует типизированные переменные приемники. Затем он генерирует код связывания.
    Заметь. Сам запрос при этом даже не выполняется. Производится только компиляция плана.
    Все это было бы не возможно, если бы SQL был не типизированным.

    V>>>Как насчёт того, что в джоинах по некоей паре полей мы можем (по ошибке или намеренно) связываться даже в случае несовместимых типов этих полей (например, строки и числа)?


    VD>>Это называется вольное обращение с автоматическим приведением типов. Встречается сплошь и рядом в весьма типизированных языках. Например, в Васике.


    V>Это называется динамическая типизация, вообще-то. VB это умеет без явной аннотации.


    ОК. Убедил — C# динамический язык... ведь приведение типов в нем поддерживается.

    V>Да, и привел пример union, где можно свалить в одну колонку разнотипные данные из разных таблиц, причем итоговый тип может зависеть от того, какая таблица идёт первая. Что не так сказал?


    Ты себя то слушаешь? Заметь! Тип определяется таблицей которая идет первой. А что же так? А в друг в первой таблице не будет записей? А тип все равно ею определяется.

    У вас неувазочка!

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


    V>Привёл пример из уровня "0" использования БД, там обосновывать нечего.


    Ясно. Обоснования не будет. Я так и думал. На сем разреши откланяться.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[32]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 14.04.09 02:24
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    IT>>А для двух полей как будет?


    VD>
    VD>Update(o => { Set(o.Field1, o.Field1 + 1); Set(o.Field2, o.Field2 + 1) })
    VD>


    Для такой конструкции экспрешин не сгенерируется.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[26]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 14.04.09 04:53
    Оценка:
    Здравствуйте, VladD2, Вы писали:


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


    VD>Дык есть она там. Типы задаются явно при описании таблиц и выводятся в запросах.

    VD>Вот здесь описан макрос Nemerle который во время компиляции ...

    VD>Все это было бы не возможно, если бы SQL был не типизированным.


    Эй, сосредоточься!
    Ты же сам несколько лет назад объяснял людям, чем отличается статическая типизация, от динамической.

    V>>Да, и привел пример union, где можно свалить в одну колонку разнотипные данные из разных таблиц, причем итоговый тип может зависеть от того, какая таблица идёт первая. Что не так сказал?


    VD>Ты себя то слушаешь? Заметь! Тип определяется таблицей которая идет первой. А что же так? А в друг в первой таблице не будет записей? А тип все равно ею определяется.


    VD>У вас неувазочка!


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


    VD>Ясно. Обоснования не будет. Я так и думал. На сем разреши откланяться.


    Я так и не понял, что требуется обосновать. Обоснование динамической типизации — это наличие самой возможности динамического приведения типов данных. Она есть в большинстве СУБД, и кроме этой динамической типизации другой-то при выборе данных и нет, что при явном, что при неявном касте.

    В общем, создай таблицу B, в которой будет один столбец A строкового типа, и напиши запрос:
    select A+1 from B

    затем внеси различные строковые данные в А (например, которые можно распарсить в целые числа, затем — в дробные, затем — просто набор символов), поиграйся в общем.

    Так же поиграй с заменой +1 на +1. , +1.0, +1.00, ...

    Результат может зависеть от БД.

    Согласно определению разновидностей типизации мы имеем дело с нестрогой + динамической типизацией.

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

    Т.е. приведённый выше пример должен выдавать ошибку перед запуском, и требовать явного конвертирования типов. Сейчас же никаких ошибок может и не быть, только на юнит тесты и надежда, как и в любой скриптово-динамической среде.
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[33]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 14.04.09 05:33
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    MC>>Скажи, а какой бы подход в работе с БД ты бы выбрал в случае не-MSSQL? Я так понимаю что как раз твой BLT?


    IT>На работе я работаю работу на Sybase. Использую понятное дело Булкит. DAL у меня сейчас самый простой слой, требующий минимум поддержки. Но всё же не хватает типизации для полного счастья, поэтому работаю над поддержкой linq в Булките. Там будет и Sybase и MS SQL и ещё минимум штук пять серверов.


    Понятно, спасибо.
    Re[24]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 14.04.09 05:35
    Оценка:
    Здравствуйте, SleepyDrago, Вы писали:

    A>>Не без ограничений обошлось, конечно. ..

    SD>Спасибо. Теперь я примерно представляю ограничения и границы применимости этого подхода.

    Угумс. Только надо понимать, что это не ограничения подхода вообще, а только моей реализации. Усложняя генератор можно ограничения снимать.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[25]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 14.04.09 06:34
    Оценка:
    Здравствуйте, VladD2, Вы писали:
    VD>В принципе можно было бы попытаться эмулировать record через tuple, но это довольно сложно. Ведь для этого пришлось бы везде протаскивать расширенную информацию о типах. Придется вводить в компилятор дополнительный тип и кодировать его черт знает каким образом в сборках. В общем, геморрой. И это при том, что tuple (кортежи) решают проблему не намного хуже.
    Ну вот примерно это сейчас муссируется в C# Insiders Maillist.

    Моя точка зрения примерно такова:
    1. Есть анонимные типы. В них удобно то, что компоненты — именованные. Это крайне здорово, т.к. позволяет делать меньше ошибок.
    2. В них неудобно то, что их нельзя возвращать.
    3. Причем понятно, почему нельзя — они же строго локальны.
    4. И даже если бы они были нелокальны, ценности бы это не добавило. Ведь {string Name, int Age} был бы несовместим со {string name, int age}.
    5. А интуитивно понятно, что такая совместимость была бы крайне полезна
    6. И она как раз есть у туплов — благодаря безымянности полей
    7. каждый тупл полностью определяется типами своих аргументов.
    8. Поэтому самый руль был бы совместить достоинства и убрать недостатки
    9. К примеру, сделать анонимные типы взаимозаменяемыми с туплами
    10. Точнее, туплы бы могли быть "официальным лицом" анонимных типов
    11. То есть вернуть из метода анонимный тип или его производные было бы по-прежнему нельзя
    12. Зато можно было бы вернуть совместимый тупл
    13. А имена полей были бы всего лишь локальными алиасами для .Value1, .Value2, etc.
    14. Но это плохо для reflection-based сценариев, где имена компонентов важны
    15. Поэтому мой мозг пасует перед сложностью задачи.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[26]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 14.04.09 06:51
    Оценка:
    Здравствуйте, VladD2, Вы писали:
    VD>То и значит. Нет полей. Нет "структуры".
    Поля не нужны. Достаточно readonly-пропертей.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[31]: Проблемы организации OR-мапинга
    От: Tom Россия http://www.RSDN.ru
    Дата: 14.04.09 07:13
    Оценка:
    IT>Также можно положить код SQL во внешний файл и подбирать его оттуда в зависимости от провайдера, если хочется.
    О!
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1139>>
    Народная мудрось
    всем все никому ничего(с).
    Re[19]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 14.04.09 07:20
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    L>>Это зависит от того, что у вас за клиент. В случае веба click по договору приведет к открытию страницы договора, а на новой странице эта инфорация уже не будет доступна и запрашивать все рано придется.


    VD>Ага. Но зачем мне получать объект по id? Я лучше получу всю нужную информацию отображаемую на странице.


    А как предполагается вытаскивать эту нформацию? Например, в случае того же web-а. Если исползуем вывод типов для запросов типа from c in customer select new { c.id, c.name }, то сразу теряем возможность использовать подобный запрос в более чем одном методе. Если же для каждого такого запроса создаем свой класс-обертку, содержащий id и name, то скоре колиество этих классов разрастется до неимоверных размеров. Как предполагается с этим бороться?

    VD>При этом я не хочу вынимать лишнюю информацию. Запрос же объекта по идентификатору — это неэффективное вынимание данных — запрос данных наобум.


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

    VD>>>И select тут будет намного более удобнее. Зачем нам объект? Нам нужно содержимое договора (например).


    L>>Если схема данных один-в-один соответствует entity, то будет гораздо удобнее.

    L>>Если же DAL занимается каким-нибудь преобразованием из резалтсета в entity, то будет уже не так удобно.

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


    В случае функции бизнес-код будет содержать информацию о том, как данные хранятся, а такому коду, имхо, не место в бизнесе.
    Re[23]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 14.04.09 07:23
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Я думаю идеальным было бы маааленькое приложение как пример.

    Tom>С разбором, можно так, можно так. Тут такие плюсы минусы. тут такие...

    Согласен на 1000%. Маленькое приложение как пример было бы супер.
    Re[23]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 14.04.09 07:23
    Оценка:
    Здравствуйте, Tom, Вы писали:

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

    Tom>А розового слоника в вакууме трогать нельзя, а то забанят. без примеров подобные топики сваливаются после третьего сообщения в маразм.
    Tom>Я думаю идеальным было бы маааленькое приложение как пример.
    Tom>С разбором, можно так, можно так. Тут такие плюсы минусы. тут такие...
    Я писал такое "маленькое" приложение для целей презентации, когда дошло до 1000 строк забил. Решил просто основные фрагменты на слайдах показать с надеждой что мне на слово поверят.
    Re[24]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 14.04.09 07:34
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    Tom>>Я думаю идеальным было бы маааленькое приложение как пример.

    Tom>>С разбором, можно так, можно так. Тут такие плюсы минусы. тут такие...
    G>Я писал такое "маленькое" приложение для целей презентации, когда дошло до 1000 строк забил.
    Очень жаль
    Re[26]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 15.04.09 17:15
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Моя точка зрения примерно такова:

    S>1. Есть анонимные типы. В них удобно то, что компоненты — именованные. Это крайне здорово, т.к. позволяет делать меньше ошибок.
    S>2. В них неудобно то, что их нельзя возвращать.
    S>3. Причем понятно, почему нельзя — они же строго локальны.
    S>4. И даже если бы они были нелокальны, ценности бы это не добавило. Ведь {string Name, int Age} был бы несовместим со {string name, int age}.
    S>5. А интуитивно понятно, что такая совместимость была бы крайне полезна
    S>6. И она как раз есть у туплов — благодаря безымянности полей
    S>7. каждый тупл полностью определяется типами своих аргументов.
    S>8. Поэтому самый руль был бы совместить достоинства и убрать недостатки
    S>9. К примеру, сделать анонимные типы взаимозаменяемыми с туплами
    S>10. Точнее, туплы бы могли быть "официальным лицом" анонимных типов
    S>11. То есть вернуть из метода анонимный тип или его производные было бы по-прежнему нельзя
    S>12. Зато можно было бы вернуть совместимый тупл
    S>13. А имена полей были бы всего лишь локальными алиасами для .Value1, .Value2, etc.
    S>14. Но это плохо для reflection-based сценариев, где имена компонентов важны
    S>15. Поэтому мой мозг пасует перед сложностью задачи.

    А почему бы для reflection-based сценариев не расширить этот самый reflection: добавить к
    public bool IsAbstract { get; }
    public bool IsAnsiClass { get; }
    public bool IsArray { get; }
    public bool IsAutoClass { get; }
    ещё и
    public bool IsTuple { get; }
    ?
    И дать возможность узнать количество компонентов кортежа и их типы — большего от них вроде и не надо.
    Ещё было бы удобно иметь возможность присваивать значение типа кортеж значению анонимного типа, если они структурно эквивалентны.
    now playing: Dubfire — I Feel Speed (Audion Remix)
    Re[25]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 15.04.09 17:15
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Да, хаскелисты тоже так считают. Хотя, полиморфизм по алгебраическим типам — это опять же и снова классика динамической типизации.

    Это в каком месте полиморфизм по алгебраическим типам динамически типизирован?
    now playing: Gregor Tresher — Unfold
    Re[21]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 15.04.09 20:42
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    L>>А как предполагается вытаскивать эту нформацию? Например, в случае того же web-а. Если исползуем вывод типов для запросов типа from c in customer select new { c.id, c.name }, то сразу теряем возможность использовать подобный запрос в более чем одном методе. Если же для каждого такого запроса создаем свой класс-обертку, содержащий id и name, то скоре колиество этих классов разрастется до неимоверных размеров. Как предполагается с этим бороться?

    G>Очень просто. Проекция накладывается в том месте где становится известно какие конкретно данные нужны. В вебе — при формировании presentation entity (она же View Model).

    Я правильно понимаю, что в этом случае под кадую страницу, под каждое использование entity будет обертка, содержащая только нужные поля?

    G>Подход с использованием паттерна Query Object позволяет отложить само выполнение запроса до тех пор пока не станут известны все параметры необходимой выборки. Это дает огромный прирост быстродействия в некоторых случаях.


    В рамках данной ветки этот параметр один — id

    VD>>>При этом я не хочу вынимать лишнюю информацию. Запрос же объекта по идентификатору — это неэффективное вынимание данных — запрос данных наобум.

    L>>А в чем серьезный недстаток вынимания всего объекта? Насколько я понимаю, сервер все равно читает с диска постранично, т.е. все данные, относящиеся к записи все равно будут подняты в память.
    G>Это если запись маленькая. Если в записи фигурируют image, varbinary, ntext и подобное, то читать эту запись полностью становится достаточно дорого.

    Ну это скорее исключение, в основном все ограничивается числами и строками.

    G>Кроме того одной записи для отображения чаще всего недостаточно, обычно тянется некоторый набор связанных записей и на них наклдаывается проекция или группировка. При подходе с GetById накладывать проекции и группировки нельзя, иначе получится протаскивание деталей presentation в DAL (та самая каша, о которой говорит Tom).


    Ок. Что взамен? По каждый view (не бд, а ui) — пачка presentation классов?

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

    L>>В случае функции бизнес-код будет содержать информацию о том, как данные хранятся, а такому коду, имхо, не место в бизнесе.
    G>EF имеет мощный маппинг, но при этом вполне нормально работает с запросами, без материалиализации данных.
    G>Кроме того можно сделать абстракции от способа хранения на view в БД, а из клиентского кода работать как с таблицами

    xml в описанном сценарии вводился исключительно для того, чтобы избежать частого изменения схемы базы. Если мы под каждое изменение в сущностях будем править вьюхи, то смысл наличия xml теряется.
    Re[21]: Проблемы организации OR-мапинга
    От: MozgC США http://nightcoder.livejournal.com
    Дата: 15.04.09 23:48
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Это назвается строить логику на исключениях, практика, за которую нужно не просто отбивать пальцы линейкой, а лучше даже что-нибудь отрезать.


    Скажи, а как ты объяснишь это:
    http://rsdn.ru/forum/message/1072811.aspx
    Автор: IT
    Дата: 15.03.05
    (смотреть на выброс исключений в методе Validate())
    Re[22]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 16.04.09 05:27
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

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


    L>>>А как предполагается вытаскивать эту нформацию? Например, в случае того же web-а. Если исползуем вывод типов для запросов типа from c in customer select new { c.id, c.name }, то сразу теряем возможность использовать подобный запрос в более чем одном методе. Если же для каждого такого запроса создаем свой класс-обертку, содержащий id и name, то скоре колиество этих классов разрастется до неимоверных размеров. Как предполагается с этим бороться?

    G>>Очень просто. Проекция накладывается в том месте где становится известно какие конкретно данные нужны. В вебе — при формировании presentation entity (она же View Model).

    L>Я правильно понимаю, что в этом случае под кадую страницу, под каждое использование entity будет обертка, содержащая только нужные поля?

    Чаще всего — да. Это вообще правильный способ в MVC.

    G>>Подход с использованием паттерна Query Object позволяет отложить само выполнение запроса до тех пор пока не станут известны все параметры необходимой выборки. Это дает огромный прирост быстродействия в некоторых случаях.

    L>В рамках данной ветки этот параметр один — id
    Неверно. Какие поля нужны в проекции — очень важный параметр.

    VD>>>>При этом я не хочу вынимать лишнюю информацию. Запрос же объекта по идентификатору — это неэффективное вынимание данных — запрос данных наобум.

    L>>>А в чем серьезный недстаток вынимания всего объекта? Насколько я понимаю, сервер все равно читает с диска постранично, т.е. все данные, относящиеся к записи все равно будут подняты в память.
    G>>Это если запись маленькая. Если в записи фигурируют image, varbinary, ntext и подобное, то читать эту запись полностью становится достаточно дорого.
    L>Ну это скорее исключение, в основном все ограничивается числами и строками.
    Именно такие исключения создают тормоза в программах. В варианте GetById где будет определяться проекция?

    G>>Кроме того одной записи для отображения чаще всего недостаточно, обычно тянется некоторый набор связанных записей и на них наклдаывается проекция или группировка. При подходе с GetById накладывать проекции и группировки нельзя, иначе получится протаскивание деталей presentation в DAL (та самая каша, о которой говорит Tom).

    L>Ок. Что взамен? По каждый view (не бд, а ui) — пачка presentation классов?
    Не пачка, а один. Это сильно способствует упрощению кода view.
    Если view делается на динамическом языке, то плодить классы необязательно.

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

    L>>>В случае функции бизнес-код будет содержать информацию о том, как данные хранятся, а такому коду, имхо, не место в бизнесе.
    G>>EF имеет мощный маппинг, но при этом вполне нормально работает с запросами, без материалиализации данных.
    G>>Кроме того можно сделать абстракции от способа хранения на view в БД, а из клиентского кода работать как с таблицами
    L>xml в описанном сценарии вводился исключительно для того, чтобы избежать частого изменения схемы базы. Если мы под каждое изменение в сущностях будем править вьюхи, то смысл наличия xml теряется.
    Не понял причем тут xml и изменения схемы.
    Re[22]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 16.04.09 05:39
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    IT>>Это назвается строить логику на исключениях, практика, за которую нужно не просто отбивать пальцы линейкой, а лучше даже что-нибудь отрезать.


    MC>Скажи, а как ты объяснишь это:

    MC>http://rsdn.ru/forum/message/1072811.aspx
    Автор: IT
    Дата: 15.03.05
    (смотреть на выброс исключений в методе Validate())


    Нормально смотрю. Если происходит операция сохранения объекта где-то в глубинах бизнес логики и валидация говорит, что объект невалиден, то программа не может далее продолжить своё выполнение. Исключительная ситуация. К тому же в том же булките есть возможность спросить (без исключения) валиден ли объект и даже не весь объект, а одно из его полей. Я так, например, красные рамки вокруг полей ввода рисую. Но если уже вызвана процедура сохранения объекта, то тут уже делать нечего, программу нужно прерывать.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[23]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 16.04.09 15:56
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    L>>Я правильно понимаю, что в этом случае под кадую страницу, под каждое использование entity будет обертка, содержащая только нужные поля?

    G>Чаще всего — да. Это вообще правильный способ в MVC.

    Мы сами подобное используем, я имею в виду создание отдельных PE для отдельных страниц. И меня совершенно не радует созерцать кучу одноразовых классов. Так что так уж однозначно называть этот способ правильным я бы не стал.

    G>>>Подход с использованием паттерна Query Object позволяет отложить само выполнение запроса до тех пор пока не станут известны все параметры необходимой выборки. Это дает огромный прирост быстродействия в некоторых случаях.

    L>>В рамках данной ветки этот параметр один — id
    G>Неверно. Какие поля нужны в проекции — очень важный параметр.

    Но это не является параметром выборки

    G>>>Это если запись маленькая. Если в записи фигурируют image, varbinary, ntext и подобное, то читать эту запись полностью становится достаточно дорого.

    L>>Ну это скорее исключение, в основном все ограничивается числами и строками.
    G>Именно такие исключения создают тормоза в программах. В варианте GetById где будет определяться проекция?

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

    G>>>Кроме того одной записи для отображения чаще всего недостаточно, обычно тянется некоторый набор связанных записей и на них наклдаывается проекция или группировка. При подходе с GetById накладывать проекции и группировки нельзя, иначе получится протаскивание деталей presentation в DAL (та самая каша, о которой говорит Tom).

    L>>Ок. Что взамен? По каждый view (не бд, а ui) — пачка presentation классов?
    G>Не пачка, а один. Это сильно способствует упрощению кода view.

    Не один, а пачка: если у кастомера в адресе нужно выбрать город, то здравствуй новая PE с двумя полями ID и Name.

    G>Если view делается на динамическом языке, то плодить классы необязательно.


    В динамических языках будут свои прелести.

    G>>>Кроме того можно сделать абстракции от способа хранения на view в БД, а из клиентского кода работать как с таблицами

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

    Посмотри выше по ветке. Там вроде все достаточно прозрачно.
    Re[24]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 17.04.09 04:50
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

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


    L>>>Я правильно понимаю, что в этом случае под кадую страницу, под каждое использование entity будет обертка, содержащая только нужные поля?

    G>>Чаще всего — да. Это вообще правильный способ в MVC.

    L>Мы сами подобное используем, я имею в виду создание отдельных PE для отдельных страниц. И меня совершенно не радует созерцать кучу одноразовых классов. Так что так уж однозначно называть этот способ правильным я бы не стал.

    Если классы очень похожи, то вполне можно убрать дублирование наследованием.

    G>>>>Подход с использованием паттерна Query Object позволяет отложить само выполнение запроса до тех пор пока не станут известны все параметры необходимой выборки. Это дает огромный прирост быстродействия в некоторых случаях.

    L>>>В рамках данной ветки этот параметр один — id
    G>>Неверно. Какие поля нужны в проекции — очень важный параметр.
    L>Но это не является параметром выборки
    Является, но вы можете продолжать в это не верить

    G>>>>Это если запись маленькая. Если в записи фигурируют image, varbinary, ntext и подобное, то читать эту запись полностью становится достаточно дорого.

    L>>>Ну это скорее исключение, в основном все ограничивается числами и строками.
    G>>Именно такие исключения создают тормоза в программах. В варианте GetById где будет определяться проекция?
    L>Исключения, в силу своей исключительнсти, создают тормоза в исключительных случаях, т.е. редко.
    Учитывая связанные сущности — часто.
    Вам практически никогда не удастся сохранить чистоту DAL, не протягивая туда детали business-logic и presentation и при этом получить нормальное быстродействие.

    G>>>>Кроме того одной записи для отображения чаще всего недостаточно, обычно тянется некоторый набор связанных записей и на них наклдаывается проекция или группировка. При подходе с GetById накладывать проекции и группировки нельзя, иначе получится протаскивание деталей presentation в DAL (та самая каша, о которой говорит Tom).

    L>>>Ок. Что взамен? По каждый view (не бд, а ui) — пачка presentation классов?
    G>>Не пачка, а один. Это сильно способствует упрощению кода view.
    L>Не один, а пачка: если у кастомера в адресе нужно выбрать город, то здравствуй новая PE с двумя полями ID и Name.
    Для пар "ключ-значение" уже есть классы.
    Вообще не надо выдумывать, я уже давно таким подходом пользуюсь, пачек классов нету вообще.
    Re[25]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 17.04.09 07:55
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    L>>Мы сами подобное используем, я имею в виду создание отдельных PE для отдельных страниц. И меня совершенно не радует созерцать кучу одноразовых классов. Так что так уж однозначно называть этот способ правильным я бы не стал.

    G>Если классы очень похожи, то вполне можно убрать дублирование наследованием.

    Еще и наследование сюда тащить? Нее, ф топку.

    G>>>>>Подход с использованием паттерна Query Object позволяет отложить само выполнение запроса до тех пор пока не станут известны все параметры необходимой выборки. Это дает огромный прирост быстродействия в некоторых случаях.

    L>>>>В рамках данной ветки этот параметр один — id
    G>>>Неверно. Какие поля нужны в проекции — очень важный параметр.
    L>>Но это не является параметром выборки
    G>Является, но вы можете продолжать в это не верить

    Ты неудачное слово подобрал, чтобы выразить свою мысль. Обычно под параметром понимают именно параметр выборки, а не список полей оной.

    G>>>>>Это если запись маленькая. Если в записи фигурируют image, varbinary, ntext и подобное, то читать эту запись полностью становится достаточно дорого.

    L>>>>Ну это скорее исключение, в основном все ограничивается числами и строками.
    G>>>Именно такие исключения создают тормоза в программах. В варианте GetById где будет определяться проекция?
    L>>Исключения, в силу своей исключительнсти, создают тормоза в исключительных случаях, т.е. редко.
    G>Учитывая связанные сущности — часто.
    G>Вам практически никогда не удастся сохранить чистоту DAL, не протягивая туда детали business-logic и presentation и при этом получить нормальное быстродействие.

    См. выше на реплику, на которую я отвечал. В ней ничего про связанные энтити не было

    G>>>>>Кроме того одной записи для отображения чаще всего недостаточно, обычно тянется некоторый набор связанных записей и на них наклдаывается проекция или группировка. При подходе с GetById накладывать проекции и группировки нельзя, иначе получится протаскивание деталей presentation в DAL (та самая каша, о которой говорит Tom).

    L>>>>Ок. Что взамен? По каждый view (не бд, а ui) — пачка presentation классов?
    G>>>Не пачка, а один. Это сильно способствует упрощению кода view.
    L>>Не один, а пачка: если у кастомера в адресе нужно выбрать город, то здравствуй новая PE с двумя полями ID и Name.
    G>Для пар "ключ-значение" уже есть классы.

    Есть, но я не о них. Часто нужно более двух полей, тут то начинают появляться нелепые классы типа CustomerInfo, ContactInfo, etc

    G>Вообще не надо выдумывать, я уже давно таким подходом пользуюсь, пачек классов нету вообще.


    Если бы такого не было, я бы не спрашивал, наверное.
    Re[27]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 18.04.09 14:31
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    VD>>То и значит. Нет полей. Нет "структуры".
    S>Поля не нужны. Достаточно readonly-пропертей.

    Для записей важны такие характеристики как идетничность по содержимому и возможность копирования в структурно-совместимые записи и кортежи.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[26]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 18.04.09 14:50
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Моя точка зрения примерно такова:

    S>1. Есть анонимные типы. В них удобно то, что компоненты — именованные. Это крайне здорово, т.к. позволяет делать меньше ошибок.
    S>2. В них неудобно то, что их нельзя возвращать.
    S>3. Причем понятно, почему нельзя — они же строго локальны.

    Это догмы введенные дизайнирами дотнета. Структурная идентичность — это примитивная возможность, реализовать которую в дотнете было бы элементарно. Нужно только желание. Ввели бы некий атрибут говорящий, что для типа помеченного им работает структурная идентичность.

    S>4. И даже если бы они были нелокальны, ценности бы это не добавило. Ведь {string Name, int Age} был бы несовместим со {string name, int age}.


    Это как раз очено даже правильно, коль в язык регистро-зависимый.

    S>5. А интуитивно понятно, что такая совместимость была бы крайне полезна


    Ничего тут интуитивно не понятно. В прочем правило игнорирования регистра тоже можно было бы ввести для совместимости с разными VB.

    S>6. И она как раз есть у туплов — благодаря безымянности полей


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

    S>7. каждый тупл полностью определяется типами своих аргументов.


    Именно и его можно рассматривать как запись с заранее оговоренными именами полей (скажем Field1, Field2, ..., FieldX).

    S>8. Поэтому самый руль был бы совместить достоинства и убрать недостатки

    S>9. К примеру, сделать анонимные типы взаимозаменяемыми с туплами

    Скажем так. Реализовать копирование между записями и кортежами.

    S>10. Точнее, туплы бы могли быть "официальным лицом" анонимных типов


    А вот это плохое решение. Лучше ввести атрибут структурной совместимости и пометить ими анонимные типы.

    S>14. Но это плохо для reflection-based сценариев, где имена компонентов важны


    А если бы была структурная совместимость, то проблем бы не возникло. Так что вердикт ясен как божий день. Еще один косяк в системе типов донета который Майкрософт упорно не хочет исправлять.

    S>15. Поэтому мой мозг пасует перед сложностью задачи.


    Потому что ты исходишь из неверных предпосылок. Нужно не заплаты придумывать, а ошибки исправлять.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[27]: Проблемы организации OR-мапинга
    От: drol  
    Дата: 18.04.09 15:57
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    S>>1. Есть анонимные типы. В них удобно то, что компоненты — именованные. Это крайне здорово, т.к. позволяет делать меньше ошибок.

    S>>2. В них неудобно то, что их нельзя возвращать.
    S>>3. Причем понятно, почему нельзя — они же строго локальны.

    VD>Это догмы введенные дизайнирами дотнета.


    Насколько я помню рассказ Хейльсберга (?) о rationale текущей реализации, для поддержки возвращения анонимных типов требуются некоторые достаточно существенные изменения/добавления в IL. Чего в 3.5, по понятным причинам, делать не хотелось. В дальнейшем же нет никаких особых проблем расширить функциональность в этом направлении.
    Re[28]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 18.04.09 16:34
    Оценка:
    Здравствуйте, drol, Вы писали:

    D>Насколько я помню рассказ Хейльсберга (?) о rationale текущей реализации, для поддержки возвращения анонимных типов требуются некоторые достаточно существенные изменения/добавления в IL. Чего в 3.5, по понятным причинам, делать не хотелось. В дальнейшем же нет никаких особых проблем расширить функциональность в этом направлении.


    IL менять не надо. Менять надо рантайм. Ту его часть, что отвечает за сравнение типов.
    Проблем "расширить функциональность в этом направлении" действительно нет. Но и расширения похоже не будет.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[29]: Проблемы организации OR-мапинга
    От: drol  
    Дата: 18.04.09 17:11
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Менять надо рантайм. Ту его часть, что отвечает за сравнение типов.


    Именно. И это и есть изменение семантики IL. Там ведь вполне конкретные правила на эту тему, насколько я понимаю.
    Re[21]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 18.04.09 17:12
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    L>>А как предполагается вытаскивать эту нформацию? Например, в случае того же web-а. Если исползуем вывод типов для запросов типа from c in customer select new { c.id, c.name }, то сразу теряем возможность использовать подобный запрос в более чем одном методе. Если же для каждого такого запроса создаем свой класс-обертку, содержащий id и name, то скоре колиество этих классов разрастется до неимоверных размеров. Как предполагается с этим бороться?


    VD>На этот вопрос есть сразу два ответа.

    VD>1. В Nemerle есть кортежи (tuple) которые могут служить в качестве возвращаемых типов. Их же можно использовать и в C#, но будет намного кривее, так как будет некоторый синтаксический оверхэд (с) Губанов.

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

    VD>2. Linq использует отложенное выполнение позволяя конструировать запрос по частям. Это позволяет экспортировать из методов запросы возвращающие объекты ассоциируемые с таблицами (те на которые linq осуществляет отображение таблиц). А уже по месту из них можно формировать запросы возвращающие конкретные значения.


    Удобно, сам ползуюсь. Но не для фильтрации списка полей, а для "горизонтальной" фильтрации. А как филтровать поля мне не совсем поятно. Если не сложно, можешь описать как будет выгляеть код вот в таком сценарии: вывести на страницу список имен и фамилий сотрудников указанного кастомера?

    L>>А в чем серьезный недстаток вынимания всего объекта?


    VD>Если бы это не было проблемой, то классический ORM-мы были бы вполне эффективны и потребность в LINQ никогда не возникла бы.


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


    Значит ли это, что если у нас нет необходимости получать объекты по ссылкам, то вытаскивание всего объекта целиком — не проблема?

    L>>В случае функции бизнес-код будет содержать информацию о том, как данные хранятся, а такому коду, имхо, не место в бизнесе.


    VD>Что значит как? Они хранятся в таблицах БД. И в знании этой "сокровенной тайны" нет ничего страшного.


    Зачем бизнес-коду знать, что данное значение хранится не непосредственно в колонке таблицы, а в xml-колонке, совместно с другими полями?
    Re[30]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 18.04.09 17:48
    Оценка:
    Здравствуйте, drol, Вы писали:

    D>Именно. И это и есть изменение семантики IL. Там ведь вполне конкретные правила на эту тему, насколько я понимаю.


    Семантика тут тоже не причем. Нужные операции есть и сейчас. Просто то что раньше было запрещено будет разрешено.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[22]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 18.04.09 18:13
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>Кортежи тоже не панацея.


    Панацея тут не причем. Кортежи — это тип данных удобный во многих (но не во всех) случаях. На работу с БД кортежи ложатся отлично.

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


    Ошибаешься. Точнее в Немерле можно пользоваться и индексным доступом (при условии что в качестве индекса используется константа). Но реально в Немерле обычно используются паттерн-матчинг для декомпозиции кортежа. Физически же у кортежа есть предопределенные поля (речь идет о реализации под дотнетом).

    L>Удобно, сам ползуюсь. Но не для фильтрации списка полей, а для "горизонтальной" фильтрации. А как филтровать поля мне не совсем поятно. Если не сложно, можешь описать как будет выгляеть код вот в таком сценарии: вывести на страницу список имен и фамилий сотрудников указанного кастомера?


    Что за сотрудники покупателя? К тому же нужно понимать о какой БД идет речь.

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


    L>Значит ли это, что если у нас нет необходимости получать объекты по ссылкам, то вытаскивание всего объекта целиком — не проблема?


    Я вообще не понял что ты сказал.

    L>Зачем бизнес-коду знать, что данное значение хранится не непосредственно в колонке таблицы, а в xml-колонке, совместно с другими полями?


    От конкретного источника конечно можно абстрагироваться. Но от структуры хранения никуда не деться.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[32]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 18.04.09 18:19
    Оценка:
    Здравствуйте, drol, Вы писали:

    D>Продолжаю не понимать. Операция раньше делала что-то по одним правилам, а теперь стала по другим. Что это если не изменение семантики ??? Тут ведь всё надо будет переделывать/передоказывать. Начиная с верификатора, и далее со всеми остановками...


    Операция раньше копировала, и теперь копирует. Просто раньше она была применима только для объектов одного типа, а теперь и для разных.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Проблемы организации OR-мапинга
    От: mrTwister Россия  
    Дата: 18.04.09 18:58
    Оценка:
    Здравствуйте, Tom, Вы писали:


    Tom>У нас сейчас планируется первая часть рефакторинга — полное переползание на .NET (да да да, только сейчас... ((( )

    Tom>будут и другие, связанные с базой. Через годик. Может тогда на рынке будут достойные решения работы с БД.

    Советую обратить внимание на LightSpeed
    лэт ми спик фром май харт
    Re[24]: Nemerle & Real Life
    От: mrTwister Россия  
    Дата: 18.04.09 19:06
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Что же касается бизнес логики на TSQL, которую ты здесь привёл, то это одно из двух: либо пережиток старого, либо дурь. Надеюсь первое. Разумного оправдания такой практике сегодня нет.


    Есть. Называется производительность.
    лэт ми спик фром май харт
    Re[28]: Nemerle & Real Life
    От: mrTwister Россия  
    Дата: 18.04.09 19:30
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

    VD>

    Логика тут нормальная. Пользователей васиного из Майкрософт кода будет на несколько порядков больше, чем у какой-то левой библиотеки. Как следствие, больше вероятность того, что кто-то другой до тебя найдет workaround твоих проблем и опубликует его в интернете.
    лэт ми спик фром май харт
    Re[18]: Проблемы организации OR-мапинга
    От: mrTwister Россия  
    Дата: 18.04.09 20:11
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.


    Это называется "реализация логики на исключениях"

    MC>Вообще так можно про все сказать "что тут исключительного". К примеру пытаемся прочитать файл, а такого файла нет (его уже пользователь удалил), ну а что тут исключительного, давайте признак возвращать.

    Как минимум, разница в том, что для файла существует метод "bool Exists(FileName)".
    лэт ми спик фром май харт
    Re[20]: Проблемы организации OR-мапинга
    От: mrTwister Россия  
    Дата: 18.04.09 20:24
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>Нет, это называется использовать исключения там где нужно.


    Использовать исключения там где нужно — это когда на этапе написания программы ты не можешь предвидеть условия возникновения исключительной ситуации, но можешь эту ситуацию обнаруживать. Например, если при написании программы ты можешь предвидеть отсутствие файла, то надо явно проверять существование этого файла, а не обрабатывать FileNotFoundException.
    лэт ми спик фром май харт
    Re[22]: Проблемы организации OR-мапинга
    От: mrTwister Россия  
    Дата: 18.04.09 20:44
    Оценка:
    Здравствуйте, MozgC, Вы писали:

    MC>Ну вот допустим идет запрос производителя по ID, и тут оказывается что такого производителя нет (а должен быть). Я кидаю из DAL исключение. И обрабатываю в БД (вывожу сообщение об ошибке пользователю и логирую саму ошибку). Что не так то?


    Если производителя нет, а он обязательно должен быть, то есть у нас налицо баг в данных, либо в коде, — то всё нормально. Если же производителя может и не быть (например, если он был удален стандартным способом) и данная ситуация не говорит о наличии бага, то не надо было доводить ситуацию до критической. Вместо этого надо было сначала убедиться в том, что производитель существует. Но у этого подхода есть две проблемы: лишний запрос к БД и параллелизм. Для решения этих проблем делают метод GetByID, возвращающий признак отсутствия данных. В отличии от исключений этот признак явный.
    лэт ми спик фром май харт
    Re[23]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 18.04.09 21:05
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    L>>Кортежи тоже не панацея.


    VD>Панацея тут не причем. Кортежи — это тип данных удобный во многих (но не во всех) случаях. На работу с БД кортежи ложатся отлично.


    Разве отлично? В базах данных кортеж — это набор именованых значений. В языках программирования — упорядоченный набор значений. По-моему отличия достаточно значительные.

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


    VD>Ошибаешься. Точнее в Немерле можно пользоваться и индексным доступом (при условии что в качестве индекса используется константа). Но реально в Немерле обычно используются паттерн-матчинг для декомпозиции кортежа.


    Разве это суть важно, что доступ не по индексу, а через паттерн матчинг, но все равно по тому же индексу.

    VD>Физически же у кортежа есть предопределенные поля (речь идет о реализации под дотнетом).


    First, Second, Third? Ты об этом говоришь?

    L>>Удобно, сам ползуюсь. Но не для фильтрации списка полей, а для "горизонтальной" фильтрации. А как филтровать поля мне не совсем поятно. Если не сложно, можешь описать как будет выгляеть код вот в таком сценарии: вывести на страницу список имен и фамилий сотрудников указанного кастомера?


    VD>Что за сотрудники покупателя? К тому же нужно понимать о какой БД идет речь.


    Под кастомером я в данном случае имел в виду заказчика. Заказчиком является фирма, на ней работают сотрудники.
    Схема самая простая: сотрудник (Employee) полем CustomerID ссылается на ID в таблице Customer

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


    L>>Значит ли это, что если у нас нет необходимости получать объекты по ссылкам, то вытаскивание всего объекта целиком — не проблема?


    VD>Я вообще не понял что ты сказал.


    Если у нас есть таблица заказчиков и нам в приложении не нужно получать информацию из других таблиц, то можно ли в этом случае грузить сущность целиком?

    L>>Зачем бизнес-коду знать, что данное значение хранится не непосредственно в колонке таблицы, а в xml-колонке, совместно с другими полями?


    VD>От конкретного источника конечно можно абстрагироваться. Но от структуры хранения никуда не деться.


    Целиком и полностью нельзя, но от каких-то деталей бизнес-логику все-таки можно изолировать.
    Re[25]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 18.04.09 21:17
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    C>>У меня не SQL-сервер смотрит наружу, естественно, а мой специальный сервис магической синхронизации кэшей


    VD>Чем изобретать велосипеды проще иметь реплики БД.


    То есть у вас сиквел в Интернет?
    Надеюсь, хот через ВПН?

    Re[7]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 19.04.09 08:00
    Оценка:
    Здравствуйте, mrTwister, Вы писали:

    A>>Вовсе нет. Если я хочу получить конкретный элемент по идентификатору, этот элемент в базе должен быть. В противном случае, имеет место логическая ошибка: неправильное получение идентификатора элемента или состояние гонки. Отсутствие конкретного элемента и пустой список элементов очень разные ситуации.


    T>Это зависит от того, откуда мы получаем идентификатор. Если идентификатор приходит откуда-то из-вне, то этому "далёку" будет положить на наше исключение. Например, какой смысл кидать пользователю исключение, если он ввел неправильный логин?


    С каких это пор логин стал Primary Key?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[18]: Проблемы организации OR-мапинга
    От: andrex Украина  
    Дата: 19.04.09 11:25
    Оценка:
    Здравствуйте, mrTwister, Вы писали:

    T>Советую обратить внимание на LightSpeed


    Посмотрел вот снова второй раз в жизни. Ребята продвинулись за пару лет. Дизайнеров студийных добавили, Linq прикрутили, умных слов в раздел поддерживаемых паттернов добавили. В общем развиваются

    А так ничего сверхоригинального. Обычная библиотечка куда напихали всего побольше с не очень удобной как по мне работой с данными. Вся их скорость основана на динамической генерации кода при помощи LCG, ну дык все тоже же самое с помощью Emit уже кучу лет есть в прекрасной библиотеке BLToolkit. А всякие репозитории и юнит-оф-ворки можно и самому накрутить в приложении если это нужно для приложения. А еще я очень не люблю когда меня заставляют наследоваться от чего то чтобы работать с СУБД...
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
    Я бы изменил мир — но Бог не даёт исходников...
    Re[24]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 19.04.09 12:02
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>Разве отлично? В базах данных кортеж — это набор именованых значений. В языках программирования — упорядоченный набор значений. По-моему отличия достаточно значительные.


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

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

    L>Разве это суть важно, что доступ не по индексу, а через паттерн матчинг, но все равно по тому же индексу.


    Нет там никаких индексов. Индекс в данном случае — это просто порядковый номер. Его даже перебрать в цикле нельзя.
    Собственно, что тут обсуждать. Можешь поглядеть как кортежи используются в немерле для доступа к данным в MS SQL Server:
    http://nemerle.org/svn/nemerle/trunk/Linq/Testes/Linq2SqlTests.n

    VD>>Физически же у кортежа есть предопределенные поля (речь идет о реализации под дотнетом).


    L>First, Second, Third? Ты об этом говоришь?


    Field1, Field2, ..., Fieldn

    L>>>Удобно, сам ползуюсь. Но не для фильтрации списка полей, а для "горизонтальной" фильтрации. А как филтровать поля мне не совсем поятно. Если не сложно, можешь описать как будет выгляеть код вот в таком сценарии: вывести на страницу список имен и фамилий сотрудников указанного кастомера?


    VD>>Что за сотрудники покупателя? К тому же нужно понимать о какой БД идет речь.


    L>Под кастомером я в данном случае имел в виду заказчика. Заказчиком является фирма, на ней работают сотрудники.

    L>Схема самая простая: сотрудник (Employee) полем CustomerID ссылается на ID в таблице Customer

    Бредовая какая-то база (или ситуация). Какой смысл учитывать чужих сотрудников?
    Запрос в данном случае будет совершенно примитивным:
    def custs = linq <# from c in customers from e in c.Employees select (e.FirstName, e.SurName) #>;
    def toLi(fName, sName) { $"<li>fName, sName</li>" }
    def html = $<#<ul> ..$(custs; "\n"; toLi) </ul>#>;

    или
    def custs = linq <# from c in customers
                        join e on in employees on c.ID == e.CustomerID
                        select (e.FirstName, e.SurName) #>;
    def html = $<#<ul> ..$(custs; "\n"; (fName, sName) => $"<li>fName, sName</li>") </ul>#>;


    L>Если у нас есть таблица заказчиков и нам в приложении не нужно получать информацию из других таблиц, то можно ли в этом случае грузить сущность целиком?


    Что запросишь, то получишь. Все равно не понимаю смысла.


    L>>>Зачем бизнес-коду знать, что данное значение хранится не непосредственно в колонке таблицы, а в xml-колонке, совместно с другими полями?


    VD>>От конкретного источника конечно можно абстрагироваться. Но от структуры хранения никуда не деться.


    L>Целиком и полностью нельзя, но от каких-то деталей бизнес-логику все-таки можно изолировать.


    Зачем бизнес-логику оберегать от знания того что она обрабатывает? Вот от конкретного сервера можно спрятать. А то что у нас есть те самые кастомеры и емплоеры — это базовые понятия для бизнес-логики. И не стоит скрывать эту информацию. Обернув все в никчемные функции вроде GetCuatomerByFitstName(...) ты нисколко не скроишь эту информацию. Ты только заставишь программиста напрягать мозг еще больше.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[29]: Nemerle & Real Life
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 19.04.09 12:04
    Оценка:
    Здравствуйте, mrTwister, Вы писали:

    T>Логика тут нормальная. Пользователей васиного из Майкрософт кода будет на несколько порядков больше, чем у какой-то левой библиотеки. Как следствие, больше вероятность того, что кто-то другой до тебя найдет workaround твоих проблем и опубликует его в интернете.


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

    Да и предпосылка ложная. Скажем пользователей Гибернэйта на сегодня сильно больше чем линка.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[26]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 19.04.09 12:26
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

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


    L>>>Мы сами подобное используем, я имею в виду создание отдельных PE для отдельных страниц. И меня совершенно не радует созерцать кучу одноразовых классов. Так что так уж однозначно называть этот способ правильным я бы не стал.

    G>>Если классы очень похожи, то вполне можно убрать дублирование наследованием.

    L>Еще и наследование сюда тащить? Нее, ф топку.

    А чем наследование плохо?
    Общность данных очень удобно выражаать через наследование или реализацию интерфейсов.

    G>>>>>>Это если запись маленькая. Если в записи фигурируют image, varbinary, ntext и подобное, то читать эту запись полностью становится достаточно дорого.

    L>>>>>Ну это скорее исключение, в основном все ограничивается числами и строками.
    G>>>>Именно такие исключения создают тормоза в программах. В варианте GetById где будет определяться проекция?
    L>>>Исключения, в силу своей исключительнсти, создают тормоза в исключительных случаях, т.е. редко.
    G>>Учитывая связанные сущности — часто.
    G>>Вам практически никогда не удастся сохранить чистоту DAL, не протягивая туда детали business-logic и presentation и при этом получить нормальное быстродействие.
    L>См. выше на реплику, на которую я отвечал. В ней ничего про связанные энтити не было
    Надо проблему целиком рассматривать.
    Проблема не в GetById, а в тому что такой подход вынужнает работать с целыми объектами, соотвествующими сущностям предметной области.
    В DDD даже придумали костыль — aggregation roots назвали.

    G>>>>>>Кроме того одной записи для отображения чаще всего недостаточно, обычно тянется некоторый набор связанных записей и на них наклдаывается проекция или группировка. При подходе с GetById накладывать проекции и группировки нельзя, иначе получится протаскивание деталей presentation в DAL (та самая каша, о которой говорит Tom).

    L>>>>>Ок. Что взамен? По каждый view (не бд, а ui) — пачка presentation классов?
    G>>>>Не пачка, а один. Это сильно способствует упрощению кода view.
    L>>>Не один, а пачка: если у кастомера в адресе нужно выбрать город, то здравствуй новая PE с двумя полями ID и Name.
    G>>Для пар "ключ-значение" уже есть классы.
    L>Есть, но я не о них. Часто нужно более двух полей, тут то начинают появляться нелепые классы типа CustomerInfo, ContactInfo, etc
    Посмотрел свои проекты. По сравнению с случаем выборки пар ключ-значение выборка трех полей из БД осуществляется гораздо реже.
    Re[25]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 19.04.09 12:57
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    L>>Разве отлично? В базах данных кортеж — это набор именованых значений. В языках программирования — упорядоченный набор значений. По-моему отличия достаточно значительные.


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


    По-моему, это очень существенная разница.

    VD>Самое важное, что структура записи и кортежа может совпадать. Это позволяет выбирать и хранить значения жертвуя именами полей. На практике оказывается, что это не такая уж серьезная жертва.


    На практике? Не напомнишь хотя бы одну библиотеку доступа к данным, где не было бы доступа к зачению поля по имени?

    L>>Разве это суть важно, что доступ не по индексу, а через паттерн матчинг, но все равно по тому же индексу.


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

    VD>Собственно, что тут обсуждать. Можешь поглядеть как кортежи используются в немерле для доступа к данным в MS SQL Server:
    VD>http://nemerle.org/svn/nemerle/trunk/Linq/Testes/Linq2SqlTests.n

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

    VD>>>Физически же у кортежа есть предопределенные поля (речь идет о реализации под дотнетом).


    L>>First, Second, Third? Ты об этом говоришь?


    VD>Field1, Field2, ..., Fieldn


    Ты действительно считаешь, что допустимо иметь такие имена для полей?

    L>>>>Удобно, сам ползуюсь. Но не для фильтрации списка полей, а для "горизонтальной" фильтрации. А как филтровать поля мне не совсем поятно. Если не сложно, можешь описать как будет выгляеть код вот в таком сценарии: вывести на страницу список имен и фамилий сотрудников указанного кастомера?


    VD>>>Что за сотрудники покупателя? К тому же нужно понимать о какой БД идет речь.


    L>>Под кастомером я в данном случае имел в виду заказчика. Заказчиком является фирма, на ней работают сотрудники.

    L>>Схема самая простая: сотрудник (Employee) полем CustomerID ссылается на ID в таблице Customer

    VD>Бредовая какая-то база (или ситуация). Какой смысл учитывать чужих сотрудников?


    Компания, для которой я пишу сейчас проект, занимается предоставлением IT-услуг компаниям. Для них информация о персонале важнп. Так что схема взята из жизни, а потому не бредова.

    VD>Запрос в данном случае будет совершенно примитивным:

    VD>
    VD>def custs = linq <# from c in customers from e in c.Employees select (e.FirstName, e.SurName) #>;
    VD>def toLi(fName, sName) { $"<li>fName, sName</li>" }
    VD>def html = $<#<ul> ..$(custs; "\n"; toLi) </ul>#>;
    VD>

    VD>или
    VD>
    VD>def custs = linq <# from c in customers
    VD>                    join e on in employees on c.ID == e.CustomerID
    VD>                    select (e.FirstName, e.SurName) #>;
    VD>def html = $<#<ul> ..$(custs; "\n"; (fName, sName) => $"<li>fName, sName</li>") </ul>#>;
    VD>


    Не, так писать не модно еще со времен коассического ASP. Нынче рулит разделение на model-view-controller.

    L>>Если у нас есть таблица заказчиков и нам в приложении не нужно получать информацию из других таблиц, то можно ли в этом случае грузить сущность целиком?


    VD>Что запросишь, то получишь. Все равно не понимаю смысла.


    Ладно, проехали.

    L>>>>Зачем бизнес-коду знать, что данное значение хранится не непосредственно в колонке таблицы, а в xml-колонке, совместно с другими полями?


    VD>>>От конкретного источника конечно можно абстрагироваться. Но от структуры хранения никуда не деться.


    L>>Целиком и полностью нельзя, но от каких-то деталей бизнес-логику все-таки можно изолировать.


    VD>Зачем бизнес-логику оберегать от знания того что она обрабатывает? Вот от конкретного сервера можно спрятать. А то что у нас есть те самые кастомеры и емплоеры — это базовые понятия для бизнес-логики. И не стоит скрывать эту информацию. Обернув все в никчемные функции вроде GetCuatomerByFitstName(...) ты нисколко не скроишь эту информацию. Ты только заставишь программиста напрягать мозг еще больше.


    Прятание запросов типа GetCuatomerByFitstName не обсуждается. Речь идет о сокрытии деталей маппинга полей сущностей на поля таблиц базы данных.
    Re[27]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 19.04.09 13:08
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>>>Если классы очень похожи, то вполне можно убрать дублирование наследованием.


    L>>Еще и наследование сюда тащить? Нее, ф топку.

    G>А чем наследование плохо?
    G>Общность данных очень удобно выражаать через наследование или реализацию интерфейсов.

    Прежде всего негибкостью — нет множественного наследования. Во-вторых, нунужным усложнением.

    L>>>>Не один, а пачка: если у кастомера в адресе нужно выбрать город, то здравствуй новая PE с двумя полями ID и Name.

    G>>>Для пар "ключ-значение" уже есть классы.
    L>>Есть, но я не о них. Часто нужно более двух полей, тут то начинают появляться нелепые классы типа CustomerInfo, ContactInfo, etc
    G>Посмотрел свои проекты. По сравнению с случаем выборки пар ключ-значение выборка трех полей из БД осуществляется гораздо реже.

    У меня другая статистика. У нас оч. тяжелые страницы и много аякса и и потому для каждой сущности, отображаемой на странице, приходится делать ее (сущности) урезаный вариант, а это и приводит в появлению этих ненавистных CustomerInfo, ContactInfo, etc
    Re[28]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 19.04.09 13:19
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

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


    G>>>>Если классы очень похожи, то вполне можно убрать дублирование наследованием.


    L>>>Еще и наследование сюда тащить? Нее, ф топку.

    G>>А чем наследование плохо?
    G>>Общность данных очень удобно выражаать через наследование или реализацию интерфейсов.
    L>Прежде всего негибкостью — нет множественного наследования. Во-вторых, нунужным усложнением.
    Да и нафиг оно не нужно.
    Вполне можно создавать классы, которые содержать чуть больше полей, чем нужно на одной сранице, и использоватть его на многих страницах.

    L>>>>>Не один, а пачка: если у кастомера в адресе нужно выбрать город, то здравствуй новая PE с двумя полями ID и Name.

    G>>>>Для пар "ключ-значение" уже есть классы.
    L>>>Есть, но я не о них. Часто нужно более двух полей, тут то начинают появляться нелепые классы типа CustomerInfo, ContactInfo, etc
    G>>Посмотрел свои проекты. По сравнению с случаем выборки пар ключ-значение выборка трех полей из БД осуществляется гораздо реже.

    L>У меня другая статистика. У нас оч. тяжелые страницы и много аякса и и потому для каждой сущности, отображаемой на странице, приходится делать ее (сущности) урезаный вариант, а это и приводит в появлению этих ненавистных CustomerInfo, ContactInfo, etc


    Может пробема в том, что у вас сами сущности переутяжелены? Хотя CustomerInfo, ContactInfo — тоже неплохой вариант во многих случаях.

    Как раз в случаях с Ajax много класов делать не надо. Если передавать на клиента сериализованный в JSON объект, даже класс писать не нужно.
    Re[29]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 19.04.09 13:46
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>>>Общность данных очень удобно выражаать через наследование или реализацию интерфейсов.

    L>>Прежде всего негибкостью — нет множественного наследования. Во-вторых, нунужным усложнением.
    G>Да и нафиг оно не нужно.
    G>Вполне можно создавать классы, которые содержать чуть больше полей, чем нужно на одной сранице, и использоватть его на многих страницах.

    Ну это уже вопрос предпочтений. Я считаю, что если куда-то передали объект, то принимающая сторона на должна знать деталей о том, как этот объект был получен, заполнен ли и он и т.д.

    L>>У меня другая статистика. У нас оч. тяжелые страницы и много аякса и и потому для каждой сущности, отображаемой на странице, приходится делать ее (сущности) урезаный вариант, а это и приводит в появлению этих ненавистных CustomerInfo, ContactInfo, etc


    G>Может пробема в том, что у вас сами сущности переутяжелены? Хотя CustomerInfo, ContactInfo — тоже неплохой вариант во многих случаях.


    Увы, в многих случаях это единственный вариант.

    G>Как раз в случаях с Ajax много класов делать не надо. Если передавать на клиента сериализованный в JSON объект, даже класс писать не нужно.


    Не, нетипизированные методы идут в топку.
    Re[31]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 19.04.09 14:36
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>>>Как раз в случаях с Ajax много класов делать не надо. Если передавать на клиента сериализованный в JSON объект, даже класс писать не нужно.

    L>>Не, нетипизированные методы идут в топку.
    G>На сервере все типизировано, а на клиенте полюбому javascript.

    И какой же тип будет у PageMethod-а? А юниттест на это дело как писать?
    Re[8]: Проблемы организации OR-мапинга
    От: mrTwister Россия  
    Дата: 19.04.09 15:02
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>С каких это пор логин стал Primary Key?


    Как сделаешь, так и будет.
    лэт ми спик фром май харт
    Re[26]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 19.04.09 19:34
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>На практике? Не напомнишь хотя бы одну библиотеку доступа к данным, где не было бы доступа к зачению поля по имени?


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

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


    Ниже же был пример.

    VD>>Field1, Field2, ..., Fieldn


    L>Ты действительно считаешь, что допустимо иметь такие имена для полей?


    В Немерле ты их не увидишь. А в C# других средств нет. Так что это детали реализации которые прийдется знать только тем кто пользуется языками не поддерживающими кортежи.

    VD>>
    VD>>def custs = linq <# from c in customers
    VD>>                    join e on in employees on c.ID == e.CustomerID
    VD>>                    select (e.FirstName, e.SurName) #>;
    VD>>def html = $<#<ul> ..$(custs; "\n"; (fName, sName) => $"<li>fName, sName</li>") </ul>#>;
    VD>>


    L>Не, так писать не модно еще со времен коассического ASP. Нынче рулит разделение на model-view-controller.


    Ну и? Коллекции customers и employees — это часть модели. Приведенный код — это реализация одного из представлений. Вместо последней строчки можешь подставить любую реализацию.

    L>Прятание запросов типа GetCuatomerByFitstName не обсуждается. Речь идет о сокрытии деталей маппинга полей сущностей на поля таблиц базы данных.


    А где ты видишь тут дтали отображения? В коде используются некие абстракные коллекции customers и employees. Они скрыват те самые детали отображения. Может они — это ХМЛ.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[28]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 19.04.09 22:07
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>Но в тестах его не было.


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

    L>Этот код хорошо выглядит только тогда, когда он занимает соседние строчки.

    L>На практике же будет совершенно иначе: запросам не место в представлении, он будут в контроллере.

    Это полнейшая чушь! Именно в представлениях им и место. Запросы — это средство доступа к модели. Задача контроллера — преобразовать ввод пользователя в изменение модели. Ни модель, ни представление не должны знать о контроллере. Так что ты просто не верно понимаешь принципы паттерна MVC. Но это уже вопрос другой дискуссии.

    На мой взгляд DML-интерфейс встроенный в язык мог бы сделать реализацию контроллера (и за одно бизнес-логики) совершенно прозрачным и относительно простым. Вся требуемая логика могла бы быть реализована на событиях DML-интерфейса. При этом пришлось бы запретить модификацию БД напрямую (в обход DML-интерфейса), но это разумная плата, на мой взгляд.

    L>Когда ты его вынесешь в контроллер, то окажется, что метод контроллера GetEmployees возвращает значения типа IEnumerable<(string * string)>.


    Не надо делать глупостей и тогда не придется обдумывать как выходить из глупых ситуаций.

    L>А это уже приводит к сл. проблемам:

    L>1. Тот кто будет пользоваться таким классом должен будет знать, что метод возвращает FirstName, LastName.
    L>2. Тот, кто будет править GetEmployees должен будет проверить все места, де потенциально используется код и исправить его.
    L>Прямо-таки классический пример сильной свзяности.

    Опять двадцать пять! Ты русские слва то понимаешь? Тебе уже сказали, что если требуется вернуть что-то, то достаточно вернуть запрос содержащий нужный список. А в нужном месте выбрать нужные поля. Так что метод у тебя будет возвращать не IEnumerable[string * string], а IQueryble[Employees] или IQueryble[Employees * SomeThinkAlse], а где-то в нужном месте представления запрос возвращенный методом будет уточнен списком требуемых колонок. При этом можно и критерии выборки уточнить. Так как до выполнения запроса он является ни чем иным как собственным описанием в виде AST, то мы вольны изменять его как хотим.

    Понятно? Потому что если нет, то я умываю руки. Моих талантов не хватает чтобы донести до тебя казалось бы очевидные вещи.

    L>>>Прятание запросов типа GetCuatomerByFitstName не обсуждается. Речь идет о сокрытии деталей маппинга полей сущностей на поля таблиц базы данных.


    VD>>А где ты видишь тут дтали отображения? В коде используются некие абстракные коллекции customers и employees. Они скрыват те самые детали отображения. Может они — это ХМЛ.


    L>Раз ты удалил отквоченый текст, то напомню, о чем идет речь:

    L>

    L>Например, некоторые параметры не хранятся один-в-один в полях таблицы, а сериализуются в xml-ную колонку. Наличие DAL-а позволяет этот механизм хранения скрыть от бизнеса, что, имхо, очень удобно и позволяет очень просто дополнять поля сущности.


    Ну, и скрывай эти детали. Что тебе мешает, то?

    У тебя забавная логика. То ты вспоминаешь о MVC, то вдруг начинаешь скрывать что-то в бинзес-слое. Если у тебя есть модель, то все сокрытие должно делаться в ней. У меодели должен быть интерфейс с короым работают представления и контролер. Интерфейсом модели в нашем случае являются объекты отображения (мапинга), т.е. те самые Employees, Customers и т.п. Если хочешь что-то скрывать, то отображи свой XML на какие-то объекты и опиши как свойство в одном из объектов отображения. Тогда и к этим данным можно убдет обращаться с помощью запросов (прямо в рамках одного запроса к вышележащим данным).
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[29]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 19.04.09 22:27
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    L>>Этот код хорошо выглядит только тогда, когда он занимает соседние строчки.

    L>>На практике же будет совершенно иначе: запросам не место в представлении, он будут в контроллере.

    VD>Это полнейшая чушь! Именно в представлениях им и место. Запросы — это средство доступа к модели. Задача контроллера — преобразовать ввод пользователя в изменение модели. Ни модель, ни представление не должны знать о контроллере. Так что ты просто не верно понимаешь принципы паттерна MVC. Но это уже вопрос другой дискуссии.


    MVC is often seen in web applications, where the view is the actual HTML or XHTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML or XHTML.

    Ты все еще уверен, что я неправильно понимаю MVC?

    L>>А это уже приводит к сл. проблемам:

    L>>1. Тот кто будет пользоваться таким классом должен будет знать, что метод возвращает FirstName, LastName.
    L>>2. Тот, кто будет править GetEmployees должен будет проверить все места, де потенциально используется код и исправить его.
    L>>Прямо-таки классический пример сильной свзяности.

    VD>Опять двадцать пять! Ты русские слва то понимаешь? Тебе уже сказали, что если требуется вернуть что-то, то достаточно вернуть запрос содержащий нужный список. А в нужном месте выбрать нужные поля. Так что метод у тебя будет возвращать не IEnumerable[string * string], а IQueryble[Employees] или IQueryble[Employees * SomeThinkAlse], а где-то в нужном месте представления запрос возвращенный методом будет уточнен списком требуемых колонок. При этом можно и критерии выборки уточнить. Так как до выполнения запроса он является ни чем иным как собственным описанием в виде AST, то мы вольны изменять его как хотим.


    Да все это понятно. Поинт лишь в том, что пихать это в presentation — последнее дело.
    UI должен быть туп как пробка и не должен содежать ни методов для формирования чего-либо, ни оперировать запросами.
    И мне оч. странно слышать, что кто-то считает иначе.

    VD>Понятно? Потому что если нет, то я умываю руки. Моих талантов не хватает чтобы донести до тебя казалось бы очевидные вещи.


    Эти очевидные вещи провоцируют на написание плохого кода.

    L>>>>Прятание запросов типа GetCuatomerByFitstName не обсуждается. Речь идет о сокрытии деталей маппинга полей сущностей на поля таблиц базы данных.


    VD>>>А где ты видишь тут дтали отображения? В коде используются некие абстракные коллекции customers и employees. Они скрыват те самые детали отображения. Может они — это ХМЛ.


    L>>Раз ты удалил отквоченый текст, то напомню, о чем идет речь:

    L>>

    L>>Например, некоторые параметры не хранятся один-в-один в полях таблицы, а сериализуются в xml-ную колонку. Наличие DAL-а позволяет этот механизм хранения скрыть от бизнеса, что, имхо, очень удобно и позволяет очень просто дополнять поля сущности.


    VD>Ну, и скрывай эти детали. Что тебе мешает, то?


    Отсутствие DAL-а, вестимо. Entity-то отличается от схемы данных.

    VD>У тебя забавная логика. То ты вспоминаешь о MVC, то вдруг начинаешь скрывать что-то в бинзес-слое. Если у тебя есть модель, то все сокрытие должно делаться в ней. У меодели должен быть интерфейс с короым работают представления и контролер. Интерфейсом модели в нашем случае являются объекты отображения (мапинга), т.е. те самые Employees, Customers и т.п. Если хочешь что-то скрывать, то отображи свой XML на какие-то объекты и опиши как свойство в одном из объектов отображения. Тогда и к этим данным можно убдет обращаться с помощью запросов (прямо в рамках одного запроса к вышележащим данным).


    Подожди. Давай уточним предмет обсуждения.
    Обсуждается как это могло бы быть в идеальном случае или все-таки real-world сценарии?
    Re[25]: Nemerle & Real Life
    От: IT Россия linq2db.com
    Дата: 19.04.09 22:32
    Оценка:
    Здравствуйте, mrTwister, Вы писали:

    IT>>Что же касается бизнес логики на TSQL, которую ты здесь привёл, то это одно из двух: либо пережиток старого, либо дурь. Надеюсь первое. Разумного оправдания такой практике сегодня нет.


    T>Есть. Называется производительность.


    Какая может быть производительность на курсорах? Это во-первых. Во-вторых, если я не ошибаюсь, Том привёл типичный для его проекта код. Как раз то, работу с чем он хотел бы упростить по максимуму. Так что я сомневаюсь, что речь шла об оптимизациях.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[30]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 19.04.09 23:08
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>

    L>MVC is often seen in web applications, where the view is the actual HTML or XHTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML or XHTML.

    L>Ты все еще уверен, что я неправильно понимаю MVC?

    MVC — это общий архитектурный паттерн и допускает очень вольную трактовку. Но основная суть его — это отделение логики данных от презентационной логики и от логики управления.

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

    Короче понимание MVC — это отдельный вопрос. К сожалению его не понимают очень многие. Не уверен в проценте, но не удивлюсь, если это 70%.

    L>Да все это понятно. Поинт лишь в том, что пихать это в presentation — последнее дело.


    Что это? Доступ к модели? А куда же его пихать, то?

    L>UI должен быть туп как пробка и не должен содежать ни методов для формирования чего-либо, ни оперировать запросами.


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

    L>И мне оч. странно слышать, что кто-то считает иначе.


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

    VD>>Понятно? Потому что если нет, то я умываю руки. Моих талантов не хватает чтобы донести до тебя казалось бы очевидные вещи.


    L>Эти очевидные вещи провоцируют на написание плохого кода.


    Ага. Осталось только доказать правоту своей гипотезы. Успехов тебе на этом поприще.

    VD>>Ну, и скрывай эти детали. Что тебе мешает, то?


    L>Отсутствие DAL-а, вестимо. Entity-то отличается от схемы данных.


    В задницу твой DAL. DAL — это костыль для объектно-тексто-скриптовых технологий которым самое время умереть.

    L>Подожди. Давай уточним предмет обсуждения.

    L>Обсуждается как это могло бы быть в идеальном случае или все-таки real-world сценарии?

    Я не отделяю эти понятия. Мне не нравится делать что-то раком и при этом мечтать об идеальном случае.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[31]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 20.04.09 01:51
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    L>>

    L>>MVC is often seen in web applications, where the view is the actual HTML or XHTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML or XHTML.

    L>>Ты все еще уверен, что я неправильно понимаю MVC?

    VD>MVC — это общий архитектурный паттерн и допускает очень вольную трактовку. Но основная суть его — это отделение логики данных от презентационной логики и от логики управления.


    Странно, а пару часов назад было

    Ни модель, ни представление не должны знать о контроллере.



    VD>Так что чем квотить мелкий кусочик из википедии (не являющейся точным источником данных, кстати) ты прочел бы хотя бы весь раздел. А еще лучше прочитай первоисточник.


    Unlike the model, which may be loosely connected to multiple MVC triads, Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling.



    VD>Короче понимание MVC — это отдельный вопрос. К сожалению его не понимают очень многие. Не уверен в проценте, но не удивлюсь, если это 70%.


    Твои догадки подтверждаются.

    L>>Да все это понятно. Поинт лишь в том, что пихать это в presentation — последнее дело.


    VD>Что это? Доступ к модели? А куда же его пихать, то?


    В контроллер, другого не остается.

    L>>UI должен быть туп как пробка и не должен содежать ни методов для формирования чего-либо, ни оперировать запросами.


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


    Если подходить формально, то ты прав. А на практеке от кода еще стребуется как минимум тестируемость. Если мы зашиваем часть логики запросов в представление, мы эту возможность теряем.

    L>>И мне оч. странно слышать, что кто-то считает иначе.


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


    Лучше от мыслительного процесса переходить к практике.

    VD>>>Понятно? Потому что если нет, то я умываю руки. Моих талантов не хватает чтобы донести до тебя казалось бы очевидные вещи.


    VD>>>Ну, и скрывай эти детали. Что тебе мешает, то?


    L>>Отсутствие DAL-а, вестимо. Entity-то отличается от схемы данных.


    VD>В задницу твой DAL. DAL — это костыль для объектно-тексто-скриптовых технологий которым самое время умереть.


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

    L>>Подожди. Давай уточним предмет обсуждения.

    L>>Обсуждается как это могло бы быть в идеальном случае или все-таки real-world сценарии?

    VD>Я не отделяю эти понятия. Мне не нравится делать что-то раком


    Ну хоть в этом отношении у тебя все нормально.

    VD>и при этом мечтать об идеальном случае.


    Да чего о нем мечтать, когда идеал уже достугнут. N****** — имя ему
    Re[27]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 03:28
    Оценка:
    Здравствуйте, vdimas, Вы писали:
    V>Согласно определению разновидностей типизации мы имеем дело с нестрогой + динамической типизацией.
    Нестрогость есть, динамики никакой нету. Ты просто не вполне понимаешь, что такое динамика vs статика. Динамикой была бы возможность во время выполнения запроса поменять тип выражения. Увы, в сиквеле всё early bound.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[27]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 03:28
    Оценка:
    Здравствуйте, IT, Вы писали:
    IT>Я пока других вариантов не вижу вовсе
    А может, всё-таки в конце принимать Expr<Func<Order, Order>> которая должна отображать старый в новый?
    У нас же типа всё иммутабл (в лучших традициях жанра), поэтому изменить ничего нельзя.

    Это бы работало замечательно, если бы был (автоматически реализованный) Fluent.
    То есть как-то так:
    (from o in orders where o.OrderDate < xxx select o).Update(o => o.SetDelayed(true));
    В предположении, что SetDelayed имеет семантику

    public Order SetDelayed(bool delayed)
    {
      if (delayed == Delayed)
          return this;
    
      Order clone = Clone();
        clone._delayed = delayed;
        return clone;
    }
    public bool Delayed { get { return _delayed; } }

    Естественно, при прогоне через SqlProvider этот код никогда не исполняется.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[22]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 03:28
    Оценка:
    Здравствуйте, Lloyd, Вы писали:
    L>Я правильно понимаю, что в этом случае под кадую страницу, под каждое использование entity будет обертка, содержащая только нужные поля?
    Конечно. Именно за это мы и боролись — чтобы эти обёртки были достаточно дешевы в производстве.

    L>В рамках данной ветки этот параметр один — id



    L>Ну это скорее исключение, в основном все ограничивается числами и строками.

    Да ладно.

    L>Ок. Что взамен? По каждый view (не бд, а ui) — пачка presentation классов?

    Конечно. Это гораздо лучше, чем one class fits all.

    L>xml в описанном сценарии вводился исключительно для того, чтобы избежать частого изменения схемы базы. Если мы под каждое изменение в сущностях будем править вьюхи, то смысл наличия xml теряется.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[20]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 03:28
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Как схемы БД, так и кода для работы с БД. Да, вот забыл упомянуть, что делать с row level security? Боюсь, если хранимки не генерировать, будет беда.
    Делать где? Если в потенциально правильной реализации, то RLS должна реализовываться на функциях высшего порядка.
    То есть непосредственно перед материализацией произвольного IQueryable<T> он протаскивается через функцию SecurityCheck().
    Ну, а она работает примерно так:
    IQueryable<T> SecurityCheck<T>(IQueryable<T> source)
    {
      return 
          from s in source where SecurityOk(s) select s;
    }

    То есть мы, естественно, подразумеваем какие-то более специфичные реализации, типа
    IQueryable<T> SecurityCheck<T>(IQueryable<T> source)
      where T: IDACLSecured
    {
      return 
          from s in source where s.ID in (from d in Context.DACL where d.UserID == session.CurrentUser.Id select TargetID) select s;
    }


    Смысл этого — в том, чтобы вовремя накладывать предикаты, а не размазывать эту логику по всем миллионам хранимок копи-пейстом.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[28]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 03:28
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Влад, мы не реплицируем БД. в данном случае репликация — это костыль для твоей системы неспособной к локальному кешированию.
    Это как раз ОRM-системы неспособны к локальному кэшированию. Там кэш может быть исключительно глобальный, иначе ты мгновенно напорешься на рассогласование.

    А в linq-подходе, о котором говорит Влад, запросто можно (если нужно) кэшировать конкретный результат конкретного запроса.

    На практике, к примеру, работа с почтой через OWA жрет в разы меньше трафика, чем честная синхронизация Outlook. А это — именно то, о чем ты говоришь. Синхронизация притаскивает на клиента полную реплику базы, и она обязана постоянно бегать и рефрешить все изменившиеся объекты — а то вдруг война (пользователь ткнул в объект), а я без каски (он устарел).
    OWA кэширует на клиенте очень-очень мало, но это ей не страшно — всё равно показывается только то, что запросил клиент.

    Причем по этому пути можно заходить достаточно далеко — если сделать протокол взаимодействия клиента и сервера более умным, чем плоский SQL/TDS. К примеру, для некоторых (только тех, которые нужны) видов запросов сервер может обучиться вычислять LastModifiedDate и сравнивать ее с датой, переданной клиентом в запросе. Ну, а дальше — традиционное 304 либо 200, смотря что нашлось. Это я не говорю про RFC3229, который позволяет обмениваться только "дельтами".
    И при должном развитии Linq в широком смысле слова (как интеграции запросов в язык) это всё можно делать в достаточно обобщенном виде. Как только мы включаем реляционную алгебру, мы опять получаем возможность прицепить "delta-predicate" к любому запросу, который содержит LastModifiedDate. Это не будет затенять основную бизнес-логику, потому что будет описано в совершенно ортогональном ей месте.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[26]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 03:28
    Оценка:
    Здравствуйте, Cyberax, Вы писали:


    C>Представь, что у нас есть две таблицы Person (id, date_created) и PersonalDetails(id, parent_id, name, last_name). Мы делаем запрос "SELECT pers.id, det.name, det.last_name FROM Person pers, PersonalDetails det where pers.id=det.parent_id" и кладём его результаты в кэш.


    C>Теперь на сервере у нас поменялся PersonalDetails (Мария Иванова вышла замуж и стала Марией Петровой, а инженер Василий поменял пол и стал Василией). Но обновить кэш корректно мы не можем! У нас в нём нет связи между этими таблицами.

    Почему не можем? Нам же всё известно. В зависимости от степени нашего усердия, мы получим
    а) нулевое кэширование: все результаты считаются устаревшими сразу по возврату
    б) простое пессимистичное кэширование: для каждого исходного набора данных (person, personDetails, и так далее) хранится таймстамп модификации. При его изменении результат считается устаревшим целиком
    в) простое точное кэширование: для каждой строки исходного набора данных хранится таймстамп модификации. При запросе вычисляется most recent change time; если он новее результата — весь результат считается устаревшим
    г) детальное точное кэширование: клиент хранит MRCT для каждой строки результата; при обновлениях обновляются только те строки, которые были фактически изменены.
    ORM-ам до этого как до китая пешком.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[24]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 03:28
    Оценка:
    Здравствуйте, Lloyd, Вы писали:
    L>Мы сами подобное используем, я имею в виду создание отдельных PE для отдельных страниц. И меня совершенно не радует созерцать кучу одноразовых классов. Так что так уж однозначно называть этот способ правильным я бы не стал.
    А что именно в одноразовых классах тебя смущает? Меня вот гораздо больше смущает насильственное использование плохо приспособленных классов.
    Просто мы очень привыкли к тому, что класс — это дорогостоящая штука, которую надо обязательно руками описать заранее, и очень многословно. И потом нужно его поддерживать, внося изменения.
    Однако внедрение более эффективных методик порождения типов позволяет сделать эти одноразовые классы достаточно дешевыми. Те же анонимные типы использовать почти так же приятно, как и именованные, при этом нет нужды описывать их заранее в отдельном месте.

    L>Но это не является параметром выборки

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

    L>Не один, а пачка: если у кастомера в адресе нужно выбрать город, то здравствуй новая PE с двумя полями ID и Name.

    Ну и что? Какие проблемы? Я не очень понимаю, что ты имеешь в виду под PE. Будет просто свойство ViewModel, в котором лежит коллекция пар ID и Name. Всё очень здорово и удобно.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[27]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 03:46
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    C>>Теперь на сервере у нас поменялся PersonalDetails (Мария Иванова вышла замуж и стала Марией Петровой, а инженер Василий поменял пол и стал Василией). Но обновить кэш корректно мы не можем! У нас в нём нет связи между этими таблицами.

    S>Почему не можем? Нам же всё известно. В зависимости от степени нашего усердия, мы получим
    Не можем. Обновления будут приходить в виде карты PK -> data, а в нашем запросе мы потеряли PK для PersonDetails.

    S>а) нулевое кэширование: все результаты считаются устаревшими сразу по возврату

    Ага.

    S>б) простое пессимистичное кэширование: для каждого исходного набора данных (person, personDetails, и так далее) хранится таймстамп модификации. При его изменении результат считается устаревшим целиком

    Не пойдёт. Обновления будут приходить в виде карты PK -> data, а в нашем запросе мы потеряли PK для PersonDetails.

    S>в) простое точное кэширование: для каждой строки исходного набора данных хранится таймстамп модификации. При запросе вычисляется most recent change time; если он новее результата — весь результат считается устаревшим

    Не пойдёт. Обновления будут приходить в виде карты PK -> data, а в нашем запросе мы потеряли PK для PersonDetails.

    S>г) детальное точное кэширование: клиент хранит MRCT для каждой строки результата; при обновлениях обновляются только те строки, которые были

    фактически изменены.
    Не пойдёт. Обновления будут приходить в виде карты PK -> data, а в нашем запросе мы потеряли PK для PersonDetails.

    S>ORM-ам до этого как до китая пешком.

    У меня это _уже_ работает с ORM. С сервера приходят дельты вида (ClassName, ID) -> changed_property, которые накладываются на локальный кэш. С полной поддержкой обновления коллекций.
    Sapienti sat!
    Re[27]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 03:46
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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

    А, вот наверное и есть то решение, которое всему поможет.
    Но вот насчёт примитивности я не уверен.
    Как только ты сделал два типа совместимыми, начинаются разнообразные смешные сценарии использования — например, употребить тип в параметре делегата.
    Или отнаследоваться от такого "типа со структурной идентичностью". В итоге получается большое количество corner cases, которые должны работать осмысленным образом. Это существенно увеличивает объем QA.
    Ну вот к примеру — будут ли два массива таких типов совместимы по присваиванию, как это работает для string[]->object[]?

    VD>Это как раз очено даже правильно, коль в язык регистро-зависимый.

    VD>Ничего тут интуитивно не понятно. В прочем правило игнорирования регистра тоже можно было бы ввести для совместимости с разными VB.
    Регистр тут ни при чём. {string Name, int Age} должен быть совместимым с любым {string, int}. См. SQL — там это используется сплошь и рядом.

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

    В чем отличие? Зачем иметь два типа, выполняющих сходную функцию? Имхо, вполне достаточно одного, но полноценного.

    VD>Скажем так. Реализовать копирование между записями и кортежами.

    С копированием есть еще несколько тонких вопросов — это же операция, нарушающая идентичность. Хотя, если считать, что ее у структурных типов быть вовсе не должно... Тем не менее, копирование не спасает для приведения друг к другу IEnumerable<T> и T[]. А без него смысла во взаимозаменяемости особого нету.

    VD>А вот это плохое решение. Лучше ввести атрибут структурной совместимости и пометить ими анонимные типы.

    Почему плохое?

    VD>А если бы была структурная совместимость, то проблем бы не возникло. Так что вердикт ясен как божий день. Еще один косяк в системе типов донета который Майкрософт упорно не хочет исправлять.

    Ну, не факт, что не хочет, и не факт, что упорно. Я вот, с учетом малого опыта работы с ФП-языками, пока что плохо представляю даже постановку задачи.

    VD>Потому что ты исходишь из неверных предпосылок. Нужно не заплаты придумывать, а ошибки исправлять.

    Ну, если есть детальное представление о том, как именно нужно исправить ошибку — то велкам.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[29]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 03:47
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>Влад, мы не реплицируем БД. в данном случае репликация — это костыль для твоей системы неспособной к локальному кешированию.

    S>Это как раз ОRM-системы неспособны к локальному кэшированию. Там кэш может быть исключительно глобальный, иначе ты мгновенно напорешься на рассогласование.
    S>А в linq-подходе, о котором говорит Влад, запросто можно (если нужно) кэшировать конкретный результат конкретного запроса.
    S>На практике, к примеру, работа с почтой через OWA жрет в разы меньше трафика, чем честная синхронизация Outlook.
    А ты ещё латентность сравни. С локальной базе в Outlook'е операции проходят _мгновенно_.
    Sapienti sat!
    Re[28]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 04:03
    Оценка:
    Здравствуйте, Cyberax, Вы писали:
    C>Не можем. Обновления будут приходить в виде карты PK -> data, а в нашем запросе мы потеряли PK для PersonDetails.
    Гм. Если обновления кэша приходят в таком виде — это чистой воды ошибка архитектора. Зачем он спроектировал обновлялку таким неприменимым образом? Подсказка: кэш в HTTP работает безо всяких PK.

    S>>ORM-ам до этого как до китая пешком.

    C>У меня это _уже_ работает с ORM. С сервера приходят дельты вида (ClassName, ID) -> changed_property, которые накладываются на локальный кэш. С полной поддержкой обновления коллекций.
    У нас это работало в 1998 году. Поэтому я знаю, о чем говорю — эта технология сосёт.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[30]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 04:20
    Оценка:
    Здравствуйте, Cyberax, Вы писали:
    S>>На практике, к примеру, работа с почтой через OWA жрет в разы меньше трафика, чем честная синхронизация Outlook.
    C>А ты ещё латентность сравни. С локальной базе в Outlook'е операции проходят _мгновенно_.
    Ну, с локальной базой в 5.4 GB особенной мгновенности я не замечаю. Что будет при 10GB?
    Да, когда я сижу из Кемеровской области по GPRS, OWA работает неторопливо.
    А вот по локальному каналу всё летает достаточно шустро. И это я еще не смотрел на OWA от Exchange 14, а они вроде как ее подкрутили.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[30]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 04:47
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>>>Раз ты удалил отквоченый текст, то напомню, о чем идет речь:

    L>>>

    L>>>Например, некоторые параметры не хранятся один-в-один в полях таблицы, а сериализуются в xml-ную колонку. Наличие DAL-а позволяет этот механизм хранения скрыть от бизнеса, что, имхо, очень удобно и позволяет очень просто дополнять поля сущности.


    VD>>Ну, и скрывай эти детали. Что тебе мешает, то?


    L>Отсутствие DAL-а, вестимо. Entity-то отличается от схемы данных.


    От повторения одного и того же оно правдой не становится. В EF маппинг, даже нетривиальный, делается без DAL.
    Re[29]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 05:12
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    C>>Не можем. Обновления будут приходить в виде карты PK -> data, а в нашем запросе мы потеряли PK для PersonDetails.
    S>Гм. Если обновления кэша приходят в таком виде — это чистой воды ошибка архитектора. Зачем он спроектировал обновлялку таким неприменимым образом? Подсказка: кэш в HTTP работает безо всяких PK.
    Не, ну это смешно. Тебе никто никогда не говорил, что:
    1) Бывают "толстые" клиенты.
    2) Запрос на сервер — это заметная латентность.

    C>>У меня это _уже_ работает с ORM. С сервера приходят дельты вида (ClassName, ID) -> changed_property, которые накладываются на локальный кэш. С полной поддержкой обновления коллекций.

    S>У нас это работало в 1998 году. Поэтому я знаю, о чем говорю — эта технология сосёт.
    А точо работало?
    Sapienti sat!
    Re[31]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 05:13
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    C>>А ты ещё латентность сравни. С локальной базе в Outlook'е операции проходят _мгновенно_.

    S>Ну, с локальной базой в 5.4 GB особенной мгновенности я не замечаю. Что будет при 10GB?
    А это уже проблемы проектировщиков приложения, не умеющих строить индексы.

    S>Да, когда я сижу из Кемеровской области по GPRS, OWA работает неторопливо.

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

    S>А вот по локальному каналу всё летает достаточно шустро. И это я еще не смотрел на OWA от Exchange 14, а они вроде как ее подкрутили.

    По локальному каналу вообще плевать как делать, можно хоть скриншоты гонять в realtime.
    Sapienti sat!
    Re[30]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 05:29
    Оценка:
    Здравствуйте, Cyberax, Вы писали:
    C>Не, ну это смешно. Тебе никто никогда не говорил, что:
    C>1) Бывают "толстые" клиенты.
    И как это противоречит модели кэширования, не построенной на PK? Ты, собственно, пытаешся изобрести на коленке то, что в мире СУБД называется Replication based on log shipping.
    А я пытаюсь объяснить то, что кэш вовсе не обязан воспроизводить структуру серверной БД, и log shipping — не единственное решение для обновлений кэша.
    Я понимаю, это трудно понять, рассматривая кэш только как локальную реплику.
    C>2) Запрос на сервер — это заметная латентность.
    А это тут причём? Если есть обновления — их нужно как-то передать. Кто-то предполагает, что log shipping превысит скорость света и станет работать без латентности?
    Нет, он работает по ровно тому же каналу. Вот только надо постараться, чтобы он не реплицировал лишних данных — я уже приводил пример про потребление трафика аутлуком.

    C>А точо работало?

    Еще как. Я тогда уверовал в ORM как в манну небесную.
    Вот только мы никак не могли нужную производительность получить — работало всё только на синтетических примерах. Ну, то есть тогда сто мегабит были дорогой редкостью.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[28]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 20.04.09 05:41
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>(from o in orders where o.OrderDate < xxx select o).Update(o => o.SetDelayed(true));

    S>В предположении, что SetDelayed имеет семантику

    А как для двух полей?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[32]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 05:46
    Оценка:
    Здравствуйте, Cyberax, Вы писали:
    S>>Да, когда я сижу из Кемеровской области по GPRS, OWA работает неторопливо.
    C>Вот, а у меня в аналогичной ситуации клиент работает без всяких задержек.
    Тут вопрос тонкий. Ок, допустим, аутлук работает "без задержек" на мелких UI операциях. А вот ожидание окончания синхронизации мы в эти задержки будем включать?
    Ну и всё-таки не до конца понятно, "в такой" ли ситуации ты проверял.
    C>По локальному каналу вообще плевать как делать, можно хоть скриншоты гонять в realtime.
    Угу. Вот только в развитом мире широкополосного интернета значительно больше, чем узкополосного. Вон народ через сеть видео в 720p смотрит — и не жужжит. Я тут наш собственный продукт пощупал через узкий канал — умереть ведь можно. А наши клиенты даже не замечают того, что мы делаем всякие full-page refresh или того, что у нас иконки не кэшируются. Вот такая вот альтернативная реальность. А какой-ндь Page Flakes, который спроектирован грамотно, вообще летает на практически любых каналах. Редкий толстый клиент сможет его порвать.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[33]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 05:58
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    C>>Вот, а у меня в аналогичной ситуации клиент работает без всяких задержек.

    S>Тут вопрос тонкий. Ок, допустим, аутлук работает "без задержек" на мелких UI операциях. А вот ожидание окончания синхронизации мы в эти задержки будем включать?
    А это смотря как её сделать...

    S>Ну и всё-таки не до конца понятно, "в такой" ли ситуации ты проверял.

    То есть?

    C>>По локальному каналу вообще плевать как делать, можно хоть скриншоты гонять в realtime.

    S>Угу. Вот только в развитом мире широкополосного интернета значительно больше, чем узкополосного.
    Ага. В развитом мире ещё полно клиентов с криворукими админами, умеющими только Windows XP устанавливать, у которых каналы забиты наглухо вирусами.

    S>Вон народ через сеть видео в 720p смотрит — и не жужжит. Я тут наш собственный продукт пощупал через узкий канал — умереть ведь можно. А наши клиенты даже не замечают того, что мы делаем всякие full-page refresh или того, что у нас иконки не кэшируются. Вот такая вот альтернативная реальность. А какой-ндь Page Flakes, который спроектирован грамотно, вообще летает на практически любых каналах. Редкий толстый клиент сможет его порвать.

    Вот буквально на прошлой неделе у нас появился новый клиент, они отказались от продукта конкурента из-за того, что у нас клиент намного более приятный в использовании. Конкурент делает чистое web-приложение.
    Sapienti sat!
    Re[29]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 06:03
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>А как для двух полей?

    Ну так это ж бубльг... то есть fluent interface:
    (from o in orders where o.OrderDate < xxx select o).Update(o => o.SetDelayed(true).SetDiscount(o.discount + Consts.DelayDiscountRate);
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[30]: Проблемы организации OR-мапинга
    От: Sinix  
    Дата: 20.04.09 06:12
    Оценка:
    Здравствуйте, Sinclair.

    Ы

    Второй раз один и тот же вопрос (http://www.rsdn.ru/Forum/message/3361137.1.aspx
    Автор: Sinix
    Дата: 14.04.09
    ).

    Второй раз отвечу что лучше по старинке:

    (from o in orders where o.OrderDate < xxx select o).
      Update(o => o.SetDelayed(true)).
      Update(o => SetDiscount(o.discount + Consts.DelayDiscountRate)); // кстати чисто в теории такие методы вполне можно мапить на хранимые процедуры - вообще ляпота будет.


    Проще парсить expression tree. Да и в концепцию IQueryable лучше вписывается.
    Re[33]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 06:18
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Редкий толстый клиент сможет его порвать.

    Кстати, могу как-нибудь мой клиент тебе показать Посмотрим, сможешь ли ты его порвать.
    Sapienti sat!
    Re[34]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 06:20
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    S>>Тут вопрос тонкий. Ок, допустим, аутлук работает "без задержек" на мелких UI операциях. А вот ожидание окончания синхронизации мы в эти задержки будем включать?

    C>А это смотря как её сделать...
    Подробнее. Вот Аутлук, к примеру, синхронизуется в обратном порядке и избегает глобальной блокировки (в отличие от RSDN@Home). Тем не менее, ситуация, когда мне нужно подождать 5-10 минут для того, чтобы принять приглашение на митинг, для узкого канала вполне типична. На том же канале то же действие через OWA займет 40-80 секунд.
    Есть какие-то мегарешения, помогающие толстому репликатору?

    C>То есть?

    Какой именно был канал.
    С чем именно сравнивалось.

    C>Ага. В развитом мире ещё полно клиентов с криворукими админами, умеющими только Windows XP устанавливать, у которых каналы забиты наглухо вирусами.

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

    C>Вот буквально на прошлой неделе у нас появился новый клиент, они отказались от продукта конкурента из-за того, что у нас клиент намного более приятный в использовании. Конкурент делает чистое web-приложение.

    Конкурент может делать всё, что угодно. Пока что в мире очень немного людей, умеющих готовить хорошие веб-приложения. Умеющих готовить хороших толстых клиентов, впрочем, тоже немного. То, что ты сумел решить задачу толстым клиентом, а конкурент не смог вебприложением, ничего не говорит о свойствах архитектуры в целом. Это говорит только о квалификации тебя и конкурента.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[35]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 06:50
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Подробнее. Вот Аутлук, к примеру, синхронизуется в обратном порядке и избегает глобальной блокировки (в отличие от RSDN@Home). Тем не менее, ситуация, когда мне нужно подождать 5-10 минут для того, чтобы принять приглашение на митинг, для узкого канала вполне типична. На том же канале то же действие через OWA займет 40-80 секунд.

    S>Есть какие-то мегарешения, помогающие толстому репликатору?
    Могу рассказать как я бы эту проблему решил.

    C>>То есть?

    S>Какой именно был канал.
    S>С чем именно сравнивалось.
    Я беру обычный модем (в моём ноуте) и проверяю как на нём всё работает. Разницы между модемом и толстым каналом практически не было. На GPRS и 3G-модеме я тоже проверял.

    Толстый канал, кстати, тоже у меня не особо замечательный. Латентность порядка 300 миллисекунд (сервер в штате Washington) и пропускная способность около 20-30 килобайт в секунду (что-то с роутингом у провайдеров не то).

    C>>Ага. В развитом мире ещё полно клиентов с криворукими админами, умеющими только Windows XP устанавливать, у которых каналы забиты наглухо вирусами.

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

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

    Самое прикольное, что наш самый опасный конкурент сейчас делает не web-приложение, а консольного клиента к COBOL'ному серверу (я уже стенку головой пробил, пока писал мигратор с него).
    Sapienti sat!
    Re[21]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 08:13
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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


  • Какая разница, размазывать логику или нет, если хранимки генерируются?
  • Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. Ничто тебя не обязывает к этому вызову. Права доступа должны быть уровнем ниже бизнес-логики, иначе будут постоянные проблемы.
  • A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[21]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 08:16
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Вот представь, что "многие-ко-многим" — это авиарейсы между городами. Каждый город, естественно, оборудован огромным количеством подробностей. Но вот ты выводишь табличку, к примеру, рейсов конкретной авиакомпании. Зачем тебе "экземпляры" всех городов? Всё, что тебе нужно — это список вида {string Departure, string Destination}. Ну так ты его и получишь!

    S>Если тебе интересно получить граф типа "полное описание города -> список доступных пунктов назначения", то тебе и нужна коллекция структур вида {Сity city, IEnumerable<string> Destinations}. Зачем тебе опять полные экземпляры в правой части?
    S>Хотеть их — вредное занятие. А то, о чем я пишу, тривиально получается в линке. За что мы его и любим.

    Антон, я уже привёл пример где было надо иметь полный граф. С авиарейсами разговор беспредметный, потому что не ясна задча — что делать с данными, как обрабатывать.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[29]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 08:28
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>Влад, мы не реплицируем БД. в данном случае репликация — это костыль для твоей системы неспособной к локальному кешированию.

    S>Это как раз ОRM-системы неспособны к локальному кэшированию. Там кэш может быть исключительно глобальный, иначе ты мгновенно напорешься на рассогласование.

    Это не правда, соответственно все твои выводы тоже не правильные.

    S>А в linq-подходе, о котором говорит Влад, запросто можно (если нужно) кэшировать конкретный результат конкретного запроса.


    И получать кучу несогласованных кешей, о чём я уже и говорил.

    S>На практике, к примеру, работа с почтой через OWA жрет в разы меньше трафика, чем честная синхронизация Outlook. А это — именно то, о чем ты говоришь. Синхронизация притаскивает на клиента полную реплику базы, и она обязана постоянно бегать и рефрешить все изменившиеся объекты — а то вдруг война (пользователь ткнул в объект), а я без каски (он устарел).


    Кто говорил о полной реплике? По-моему, я ясно дал понять, что неполная реплика вполне может быть целостной. И насчёт "войны", я опять таки говорил, что обновление кеша необходимо только при модификации объекта.

    S>Причем по этому пути можно заходить достаточно далеко — если сделать протокол взаимодействия клиента и сервера более умным, чем плоский SQL/TDS. К примеру, для некоторых (только тех, которые нужны) видов запросов сервер может обучиться вычислять LastModifiedDate и сравнивать ее с датой, переданной клиентом в запросе. Ну, а дальше — традиционное 304 либо 200, смотря что нашлось. Это я не говорю про RFC3229, который позволяет обмениваться только "дельтами".

    S>И при должном развитии Linq в широком смысле слова (как интеграции запросов в язык) это всё можно делать в достаточно обобщенном виде. Как только мы включаем реляционную алгебру, мы опять получаем возможность прицепить "delta-predicate" к любому запросу, который содержит LastModifiedDate. Это не будет затенять основную бизнес-логику, потому что будет описано в совершенно ортогональном ей месте.

    Антон, это всё очень интересно, но к практике отношения не имеет. Чтобы считать дельту надо иметь две версии ответа: старую и новую, для каждого клиента. Кешировать все ответы для всех клиентов? Нет, это не реально.
    Более того, дело даже не в объёмах данных, а во времени отклика. Пустой запрос к серверу может отожрать секунду и интерфейс начнёт сильно тормозить, когда кто-то качает фильм через торент. А ещё, бывает, что соединение с сервером есть не всегда. Linq более или менее приемлем только для веб-сайтов и то ИМХО вызывает проблемы. Для клиент-серверных (и n-tier в целом) систем он неприемлем вообще.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[33]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 08:33
    Оценка:
    Здравствуйте, Sinix, Вы писали:
    S>А на вэйварда я даже подписан, заодно с Bart De Smet. Кcтати, не читали блог последнего? Крайне забавные темы проскальзывают. Из моих любимых — прикручиваем linq ко всему и осло.
    Спасибо, под
    писался.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[22]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 08:33
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>
  • Какая разница, размазывать логику или нет, если хранимки генерируются?
    1. Зачем заниматься генерацией ненужного кода?
    2. Если даже код нужный, то почему не сделать генерацию прозрачной? Например, она может происходить в тот момент, когда запрос собран и происходит вызов .ToArray().

    Пример хорошей генерации кода: IL->x86.
    Пример плохой генерации кода: генерация сотен хранимок "просто так".

    A>
  • Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть.
    A>Ничто тебя не обязывает к этому вызову. Права доступа должны быть уровнем ниже бизнес-логики, иначе будут постоянные проблемы.
    Права доступа зачастую и есть часть бизнес-логики.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
  • Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[22]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 08:33
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Антон, я уже привёл пример где было надо иметь полный граф.
    Нет, не привёл. Ты искусственно потребовал "собрать граф объектов" без малейшей мотивации того, для чего он тебе нужен.
    Это проблема ментальной модели, и я с этой проблемой тесно знаком. Спроси ОРМ-программиста захрена он тащит в тонкого клиента полную географию США — он смотрит на тебя как на идиота и говорит "ну так мне же нужно показать список штатов в дроп-дауне".
    A>С авиарейсами разговор беспредметный, потому что не ясна задча — что делать с данными, как обрабатывать.
    Правильно. Приведи предметный пример, который не сводится к задаче "хочу граф объектов и чтобы внутри обязательно были сцылки".
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[23]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 08:42
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Это проблема ментальной модели, и я с этой проблемой тесно знаком. Спроси ОРМ-программиста захрена он тащит в тонкого клиента полную географию США — он смотрит на тебя как на идиота и говорит "ну так мне же нужно показать список штатов в дроп-дауне".

    Это плохой ORM-программист. Нормальный программист просто вытащит список объектов типа State для заданной страны. В объекте State будет три поля "id", "name" и "abbreviation".
    Sapienti sat!
    Re[23]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 08:47
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>
  • Какая разница, размазывать логику или нет, если хранимки генерируются?
    G>Так что, хранимки генерируются на ВСЕ возможные запросы? В хранимках страшная каша будет из бизнес-логики и деталей представления.

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

    A>>
  • Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. Ничто тебя не обязывает к этому вызову.
    G>Для этого существуют механизмы AOP как compile-time, так и runtime.

    Ну атрибут забудешь, велика разница.

    A>>Права доступа должны быть уровнем ниже бизнес-логики, иначе будут постоянные проблемы.

    G>Чушь повторенная несколько раз истиной не становится.

    Трудно не согласиться.
  • A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[30]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 08:50
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Это не правда, соответственно все твои выводы тоже не правильные.
    Да ладно.
    A>И получать кучу несогласованных кешей, о чём я уже и говорил.
    Нет. От повторения заблуждение не станет правдой. Ты просто неправильно трактуешь кэш.

    A>Кто говорил о полной реплике? По-моему, я ясно дал понять, что неполная реплика вполне может быть целостной.

    Только не дал понять, как этого добиться.
    A>И насчёт "войны", я опять таки говорил, что обновление кеша необходимо только при модификации объекта.
    Ага. И чем больше кэш — тем больше шанс на обновление. Рома, мы всё это уже проходили. И клинышки для подпорок для костылей, и репликацию. И даже predicate-based caching я в свое время пристально рассматривал, а это вам с Cyberax еще только предстоит изобрести.


    A>Антон, это всё очень интересно, но к практике отношения не имеет. Чтобы считать дельту надо иметь две версии ответа: старую и новую, для каждого клиента. Кешировать все ответы для всех клиентов? Нет, это не реально.

    Рома, это не только реально — это работает. Ну почитай наконец RFC, которые я приводил. Не нужно иметь две версии ответа — достаточно таймстампов. Кэшированием всех ответов для всех клиентов занимаются, естественно, сами клиенты. Именно таким образом работает кэширование в HTTP.

    A>Более того, дело даже не в объёмах данных, а во времени отклика. Пустой запрос к серверу может отожрать секунду и интерфейс начнёт сильно тормозить, когда кто-то качает фильм через торент.

    Какой еще фильм через торрент? Рома, мы же говорим о Linq между апп-сервером и дб-сервером. Разве нет? К ORM, где толстые объекты живут прямо на стороне клиента, я отношусь крайне скептически.

    A>А ещё, бывает, что соединение с сервером есть не всегда. Linq более или менее приемлем только для веб-сайтов и то ИМХО вызывает проблемы. Для клиент-серверных (и n-tier в целом) систем он неприемлем вообще.

    Да ладно.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[23]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 08:50
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>1. Зачем заниматься генерацией ненужного кода?


    Проверка прав доступа — ненужный код?

    S>2. Если даже код нужный, то почему не сделать генерацию прозрачной? Например, она может происходить в тот момент, когда запрос собран и происходит вызов .ToArray().


    А кто сказал, что она непрозрачна?

    S>Пример хорошей генерации кода: IL->x86.

    S>Пример плохой генерации кода: генерация сотен хранимок "просто так".

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

    A>>
  • Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть.
    A>>Ничто тебя не обязывает к этому вызову. Права доступа должны быть уровнем ниже бизнес-логики, иначе будут постоянные проблемы.
    S>Права доступа зачастую и есть часть бизнес-логики.

    Установка прав — да, проверка — нет.
  • A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[25]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 08:53
    Оценка:
    Здравствуйте, gandjustas, Вы писали:
    G>А если State обладает значительно более сложной структурой?
    Ну конечно же обладает. У State там дофига всего лежит — начиная от значения VAT и заканчивая ссылкой на текущего губернатора. А если этого там нету, так это означает, что фактически класс StateEntity уже был искусственно обрезан до StateNameInfo, только неявно, в голове архитектора.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[24]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 08:56
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>
  • Какая разница, размазывать логику или нет, если хранимки генерируются?
    G>>Так что, хранимки генерируются на ВСЕ возможные запросы? В хранимках страшная каша будет из бизнес-логики и деталей представления.
    A>Ещё раз, я не считаю механизмы проверки прав доступа бизнес-логикой.
    А это тут причем?
    Пример из моего кода: нужно выбрать все проекты видимые проекты с заданной картинкой в заданной категории, у которых есть видимые клиенты.
    В одном месте мне нужно отобразить список из назавния и услуг, связанных с проектом. А в другом месте надо отобразить 3 последних проекта из той же выборки, но уже с картинкой и описанием.
    Фактически две выборки отличаются только деталями представления.
    В твоем случе это будут разные хранимки?

    A>>>
  • Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. Ничто тебя не обязывает к этому вызову.
    G>>Для этого существуют механизмы AOP как compile-time, так и runtime.
    A>Ну атрибут забудешь, велика разница.
    Ну так вообще что угодно забыть можно Даже вызывать генератор хранимок.
  • Re[23]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 08:57
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Нет, не привёл. Ты искусственно потребовал "собрать граф объектов" без малейшей мотивации того, для чего он тебе нужен.


    Нет, я не потребовал. Я показал, что кеширование отдельных запросов без преобразования в объекты приводит к несогласованности данных кешах запросов. А вот если собрать граф объектов, то такой несогласованности не будет.

    S>Это проблема ментальной модели, и я с этой проблемой тесно знаком. Спроси ОРМ-программиста захрена он тащит в тонкого клиента полную географию США — он смотрит на тебя как на идиота и говорит "ну так мне же нужно показать список штатов в дроп-дауне".


    Антон, второй раз повторяю. Я никогда не говорил о полной реплике. Это понятно?

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

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

    http://www.rsdn.ru/forum/message/3358676.1.aspx
    Автор: adontz
    Дата: 12.04.09

    Задача получения согласованных данных на уровне Linq-подобных запросов не решается.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[31]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 09:03
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>Кто говорил о полной реплике? По-моему, я ясно дал понять, что неполная реплика вполне может быть целостной.

    S>Только не дал понять, как этого добиться.

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

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

    S>Ага. И чем больше кэш — тем больше шанс на обновление.

    Каким образом интеснивность работы пользователя зависит от размера кеша?

    S>Рома, это не только реально — это работает. Ну почитай наконец RFC, которые я приводил. Не нужно иметь две версии ответа — достаточно таймстампов. Кэшированием всех ответов для всех клиентов занимаются, естественно, сами клиенты. Именно таким образом работает кэширование в HTTP.


    Еслинственный практический случай delta в HTTP который я помню это SVN. И там у сервера есть старая и новая версии. Как ты собираешься на сервере строить разницу между старой и новой версией, если он не имеет доступа к обеим?

    A>>Более того, дело даже не в объёмах данных, а во времени отклика. Пустой запрос к серверу может отожрать секунду и интерфейс начнёт сильно тормозить, когда кто-то качает фильм через торент.

    S>Какой еще фильм через торрент? Рома, мы же говорим о Linq между апп-сервером и дб-сервером. Разве нет?

    Нет. Мы говорим об клиенте и апп-сервере
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[24]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 09:03
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Проверка прав доступа — ненужный код?
    Хранимка — ненужный код. Зачем она, если можно просто построить запрос и выполнить его?

    A>А кто сказал, что она непрозрачна?

    Никто не сказал. Но я не имею опыта эксплуатации системы, где хранимки автоматически порождаются Just In Time и убиваются, когда они больше не нужны.

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

    Рома, не нужно агитации. Этот уровень абстракции делает поразительно мало в обмен на геморрой по его поддержанию в up-to-date состоянии. Вся та же функциональность вполне доступна и без генерации хранимок. Я показал, как именно. Страшилки про "а вдруг кто-то забудет обратиться к предикату" идут в топку, потому что это прямой аналог вопроса "а если я сделаю прямой селект из таблицы мимо хранимки".
    Если сильно страшно, то можно поставить проверку наличия предиката безопасности прямо в том месте, где запрос начинает исполняться.

    A>Установка прав — да, проверка — нет.

    Да ладно! "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" — это что, не бизнес-логика? Спустись с небес на землю.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[25]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 09:04
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    C>>Это плохой ORM-программист. Нормальный программист просто вытащит список объектов типа State для заданной страны. В объекте State будет три поля "id", "name" и "abbreviation".

    G>А если State обладает значительно более сложной структурой?
    То это плохая архитектура

    G>Задчача таже — отобразить список в dropdown.

    В крайнем случае — делается специальный DTO.
    Sapienti sat!
    Re[25]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 09:05
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Пример из моего кода: нужно выбрать все проекты видимые проекты с заданной картинкой в заданной категории, у которых есть видимые клиенты.

    G>В одном месте мне нужно отобразить список из назавния и услуг, связанных с проектом. А в другом месте надо отобразить 3 последних проекта из той же выборки, но уже с картинкой и описанием.
    G>Фактически две выборки отличаются только деталями представления.
    G>В твоем случе это будут разные хранимки?

    Не уверен, что правильно понял задачсу. Можно подробнее?

    A>>>>
  • Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. Ничто тебя не обязывает к этому вызову.
    G>>>Для этого существуют механизмы AOP как compile-time, так и runtime.
    A>>Ну атрибут забудешь, велика разница.
    G>Ну так вообще что угодно забыть можно Даже вызывать генератор хранимок.

    Ну тогда у тебя не будет всех хранимок Это легко заметить.
  • A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[25]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 09:08
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    S>Рома, не нужно агитации. Этот уровень абстракции делает поразительно мало в обмен на геморрой по его поддержанию в up-to-date состоянии. Вся та же функциональность вполне доступна и без генерации хранимок. Я показал, как именно. Страшилки про "а вдруг кто-то забудет обратиться к предикату" идут в топку, потому что это прямой аналог вопроса "а если я сделаю прямой селект из таблицы мимо хранимки".

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

    S>Если сильно страшно, то можно поставить проверку наличия предиката безопасности прямо в том месте, где запрос начинает исполняться.


    И там тоже можно забыть.

    A>>Установка прав — да, проверка — нет.

    S>Да ладно! "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" — это что, не бизнес-логика? Спустись с небес на землю.

    Это не те права доступа, о которых я говорил.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[24]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 09:09
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    S>>Нет, не привёл. Ты искусственно потребовал "собрать граф объектов" без малейшей мотивации того, для чего он тебе нужен.

    A>Нет, я не потребовал. Я показал, что кеширование отдельных запросов без преобразования в объекты приводит к несогласованности данных кешах запросов. А вот если собрать граф объектов, то такой несогласованности не будет.
    Именно эта фраза подтевржадет то что кеш в ORM-системах может быть только глобальный.

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

    S>>Правильно. Приведи предметный пример, который не сводится к задаче "хочу граф объектов и чтобы внутри обязательно были сцылки".
    A>http://www.rsdn.ru/forum/message/3358676.1.aspx
    Автор: adontz
    Дата: 12.04.09

    A>Задача получения согласованных данных на уровне Linq-подобных запросов не решается.\
    Кажестся я уже описывал, что эта задача и другими способами нормально не решается.
    Вообще если между двумя запросами свзязанных данных проходит какое-то время, то всегда можно нарваться на рассогласованность, и без пессимистичной блокировки этих данных в общем случае победить такое нельзя.
    Re[26]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 09:13
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


    C>>>Это плохой ORM-программист. Нормальный программист просто вытащит список объектов типа State для заданной страны. В объекте State будет три поля "id", "name" и "abbreviation".

    G>>А если State обладает значительно более сложной структурой?
    C>То это плохая архитектура
    С чего это? Может основная функция системы в работе с географией и административными субъектами.
    Или выбор штата в дропдауне — плохая архитектура?

    G>>Задчача таже — отобразить список в dropdown.

    C>В крайнем случае — делается специальный DTO.
    А потом появляются более сложные сценарии, когда для формирования DTO нам нужно соединение таблиц, группировки данных...
    Обобщая такие крайние случаи и получим модель запросов и полновесный ORM нам никак не поможет.
    Re[27]: Проблемы организации OR-мапинга
    От: Cyberax Марс  
    Дата: 20.04.09 09:18
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    C>>То это плохая архитектура

    G>С чего это? Может основная функция системы в работе с географией и административными субъектами.
    Тогда да, хотя там тоже под вопросом. Но в этом случае скорее всего эта информация и так понадобится в программе, так что осбого вопроса с загрузкой словаря не будет.

    G>Или выбор штата в дропдауне — плохая архитектура?

    Это тоже не очень удачный выбор — 50 элементов уже многовато для комбобокса.

    C>>В крайнем случае — делается специальный DTO.

    G>А потом появляются более сложные сценарии, когда для формирования DTO нам нужно соединение таблиц, группировки данных...
    G>Обобщая такие крайние случаи и получим модель запросов и полновесный ORM нам никак не поможет.
    DTO — это всего лишь объект передачи данных, тот же кортеж им вполне может быть. В этом случае просто всё у нас скатывается к SQL-подобному доступу.
    Sapienti sat!
    Re[26]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 09:20
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Пример из моего кода: нужно выбрать все проекты видимые проекты с заданной картинкой в заданной категории, у которых есть видимые клиенты.

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

    Лучше более обще опишу: есть выборка, полученная наложением кучи условий, соединений, группировок (неважно каких).
    В интерфейсе эта выборка используется в двух местах, в каждом из них надо отображать свой набор полей выборки, со своими условиями сортировки.
    Внимание вопрос: это будет две разные хранимки?
    Re[24]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 09:20
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Нет, я не потребовал. Я показал, что кеширование отдельных запросов без преобразования в объекты приводит к несогласованности данных кешах запросов.
    Да нихрена ты не показал.
    A>http://www.rsdn.ru/forum/message/3358676.1.aspx
    Автор: adontz
    Дата: 12.04.09

    A>Задача получения согласованных данных на уровне Linq-подобных запросов не решается.
    1. Если ты хотел гарантий согласованности, то читал бы их в одной транзакции с уровнем изоляции Serializable и никакой несогласованности бы не увидел. RTFM.
    2. Про штампы времени ты допустил ошибку: у тебя вовсе не "последние версии таблицы городов". Сама постановка вопроса показывает наличие клина в голове: ты не получал в результате никаких таблиц. Ты получил результат запроса. Результат запроса c (CityName, CustomerCount), естественно, устарел.
    Теперь специально для тех, кто быстро пишет и медленно думает, поясняю, каким образом работает timestamp-based cache refresh в приведенном тобой случае.
    select 
    City.Name, CustomerStats.customerCount, CustomerStats.LastModified 
    from Cities 
    inner join 
      ( select cityId, count(*) as customerCount, max(lastModified) as LastModified from customers group by cityId) CustomerStats
    on Cities.ID = CustomerStats.cityID

    Теперь для delta encoding достаточно получить с клиента таймстамп его результата, и добавить к запросу:
    select 
    City.Name, CustomerStats.customerCount, CustomerStats.LastModified 
    from Cities 
    inner join 
      ( select cityId, count(*) as customerCount, max(lastModified) as LastModified from customers group by cityId) CustomerStats
    on Cities.ID = CustomerStats.cityID
    where CustomerStats.LastModified > @LastModified

    Понятно, как это работает?
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[32]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 09:20
    Оценка:
    Здравствуйте, adontz, Вы писали:


    A>Каким образом интеснивность работы пользователя зависит от размера кеша?

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

    A>Еслинственный практический случай delta в HTTP который я помню это SVN. И там у сервера есть старая и новая версии. Как ты собираешься на сервере строить разницу между старой и новой версией, если он не имеет доступа к обеим?

    Рома, почитай RFC про Delta Encoding. Там, вроде бы, был пример того, как строить дельты.

    A>Нет. Мы говорим об клиенте и апп-сервере

    Ну, тогда я не уверен, что понимаю что и зачем мы пытаемся изобрести. Какой тут нафиг ORM вообще? Зачем он нужен? Я могу себе представить ситуацию, в которой толстый клиент лучше тонкого, но в этих ситуациях протоколы репликации строго ортогональны собственно функциям клиента. Я сильно сомневаюсь, что к ним будет нужен какой-то линк или еще что-то. При этом собственно взаимодействие кода клиента с локальными данными по-прежнему может строиться на линке.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[28]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 09:29
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


    C>>>То это плохая архитектура

    G>>С чего это? Может основная функция системы в работе с географией и административными субъектами.
    C>Тогда да, хотя там тоже под вопросом. Но в этом случае скорее всего эта информация и так понадобится в программе, так что осбого вопроса с загрузкой словаря не будет.
    Угу, вот про это и разговор. "информация скорее всего и так понадобится в программе" — первая отмазка ORM-щиков когда им говрят про слишком большой объем данных на клиенте.

    G>>Или выбор штата в дропдауне — плохая архитектура?

    C>Это тоже не очень удачный выбор — 50 элементов уже многовато для комбобокса.
    Для хорошо известных элементов — нормально.
    Страны, штаты, области, города — вполне нормально уживаются в комбобоксах. А вот список сотрудников в комбобоксе — хреновое решение.

    C>>>В крайнем случае — делается специальный DTO.

    G>>А потом появляются более сложные сценарии, когда для формирования DTO нам нужно соединение таблиц, группировки данных...
    G>>Обобщая такие крайние случаи и получим модель запросов и полновесный ORM нам никак не поможет.
    C>DTO — это всего лишь объект передачи данных, тот же кортеж им вполне может быть. В этом случае просто всё у нас скатывается к SQL-подобному доступу.
    Так если SQL-подобный доступ совместить с механизмом отображения полей БД на свойства объектов данных (DTO), то будет счастье. Об этом и говорим.
    Re[26]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 09:37
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Антон, разница есть существенная. Чтобы забыть обратиться к предикату надо забыть написать один вызов функции.

    A>Чтоб сделать SELECT из таблицы напрямую, надо очень сильно помучатсья и очень много чего написать.

    A>И там тоже можно забыть.

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

    A>Это не те права доступа, о которых я говорил.

    Ну так понятно — ты говорил о каких-то других правах доступа, чем те, которые реально нужны.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[30]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 09:40
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


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

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

    G>>>>Обобщая такие крайние случаи и получим модель запросов и полновесный ORM нам никак не поможет.

    C>>>DTO — это всего лишь объект передачи данных, тот же кортеж им вполне может быть. В этом случае просто всё у нас скатывается к SQL-подобному доступу.
    G>>Так если SQL-подобный доступ совместить с механизмом отображения полей БД на свойства объектов данных (DTO), то будет счастье. Об этом и говорим.
    C>Тебе говорят, что в большинстве случаев ORM не даёт существенного overhead'а, поэтому и DTO не нужны.
    Полновесный ORM дает оверхед не только в объеме данных.

    C>Для редких случаев, когда overhead от ORM слишком велик — используем DTO.

    Нормальные люди используют запросы и не парятся с DTO, ORM и другими трухбуквенными сочетаниями.

    C>Ситуация примерно как с ассмеблерными вставками раньше — оптимизируем только узкие места.

    Неверная аналогия. SQL обладает большими возможностями, чем GetById, FindByName и прочее.
    Re[32]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 20.04.09 10:27
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>>>

    L>>>MVC is often seen in web applications, where the view is the actual HTML or XHTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML or XHTML.

    L>>>Ты все еще уверен, что я неправильно понимаю MVC?

    VD>>MVC — это общий архитектурный паттерн и допускает очень вольную трактовку. Но основная суть его — это отделение логики данных от презентационной логики и от логики управления.


    L>Странно, а пару часов назад было

    L>

    L>Ни модель, ни представление не должны знать о контроллере.

    L>

    А что в приведенных цитатах есть противоречия?

    VD>>Так что чем квотить мелкий кусочик из википедии (не являющейся точным источником данных, кстати) ты прочел бы хотя бы весь раздел. А еще лучше прочитай первоисточник.


    L>

    L>Unlike the model, which may be loosely connected to multiple MVC triads, Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling.

    L>

    Опять же, что ты тут вычитал? Нашел несоответствие с описанием в Википедии?

    VD>>Короче понимание MVC — это отдельный вопрос. К сожалению его не понимают очень многие. Не уверен в проценте, но не удивлюсь, если это 70%.


    L>Твои догадки подтверждаются.


    Ага. И таких как ты большинство.

    L>>>Да все это понятно. Поинт лишь в том, что пихать это в presentation — последнее дело.


    VD>>Что это? Доступ к модели? А куда же его пихать, то?


    L>В контроллер, другого не остается.


    Иди и еще раз прочитай задачи контроллера. Если в контроллере будет логика отображения, то это будет смешиванием логики отображения и логики управления, то есть нарушением базового принципа MVC.

    Короче, в данной теме я не намерен продолжать обсуждение паттерна MVC. Если тебе интересно, заводи новую тему.

    L>>>UI должен быть туп как пробка и не должен содежать ни методов для формирования чего-либо, ни оперировать запросами.


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


    L>Если подходить формально, то ты прав. А на практеке от кода еще стребуется как минимум тестируемость. Если мы зашиваем часть логики запросов в представление, мы эту возможность теряем.


    Интересный поворот. С доказательством нарушения принципов MVC не вышло, переключаемся на тестирование...
    При желании организовать тестирование презентационной логике тоже можно. Но это опять таки очередное отклонение от темы. Главное, что для этого нет нужды выносить презентационную логику из представления.

    L>Лучше от мыслительного процесса переходить к практике.


    То есть, трясти, а не думать? Это подход прапорщиков.

    L>Как тогда скрывать детали маппинга? Я кажется, догадываюсь, что ты ответишь. В задницу сокрытие деталей. Оно?


    У тебя будут объекты на которые идет отображение. Вот они и будут скрывать все что нужно. Можешь считать их DAL-ом.
    Мне больше нравится терминология MVC. В ней данные объекты являются публичным интерфейсом модели.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[28]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 20.04.09 11:01
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>А, вот наверное и есть то решение, которое всему поможет.


    Именно.

    S>Но вот насчёт примитивности я не уверен.

    S>Как только ты сделал два типа совместимыми, начинаются разнообразные смешные сценарии использования — например, употребить тип в параметре делегата.

    И какие здесь проблемы?

    S>Или отнаследоваться от такого "типа со структурной идентичностью".


    Тут много вариантов решения. Самое простое решение — обязать помечать типы помечаемые атрибутом структурной идентичности модификатором sealed.

    S>В итоге получается большое количество corner cases, которые должны работать осмысленным образом. Это существенно увеличивает объем QA.


    Не выдумывай. Данная возможность реализована в большинстве ФЯ. Так что все проблемы надуманы. Просто не надо жить в догмах системы типов донета. Надо ее немного расширить.

    S>Ну вот к примеру — будут ли два массива таких типов совместимы по присваиванию, как это работает для string[]->object[]?


    Я считаю, что коваринтность массивов — это ошибка дизайна. На практике данная возможность практически не используется, но вреда для производительности создает не мало. Но это отдельная тема.
    В данном случае массивы обязаны быть совместимы просто потому, что два таких типа обязаны рассматриваться как один. В прочем, даже если это будет не так особых проблем не возникнет.

    S>Регистр тут ни при чём. {string Name, int Age} должен быть совместимым с любым {string, int}. См. SQL — там это используется сплошь и рядом.


    Мой ответ — нет. Но, если что можно произвести копирование через совместимый по типам кортеж. Вот кортежи должны сравниваться только по типам элементов.

    S>В чем отличие? Зачем иметь два типа, выполняющих сходную функцию? Имхо, вполне достаточно одного, но полноценного.


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

    VD>>Скажем так. Реализовать копирование между записями и кортежами.

    S>С копированием есть еще несколько тонких вопросов — это же операция, нарушающая идентичность.

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

    S> Хотя, если считать, что ее у структурных типов быть вовсе не должно... Тем не менее, копирование не спасает для приведения друг к другу IEnumerable<T> и T[]. А без него смысла во взаимозаменяемости особого нету.


    VD>>А вот это плохое решение. Лучше ввести атрибут структурной совместимости и пометить ими анонимные типы.

    S>Почему плохое?

    Откровенно говоря не понимаю причем тут приведение IEnumerable<T> и T[]. Я, видимо, потерял ход мысли.

    VD>>А если бы была структурная совместимость, то проблем бы не возникло. Так что вердикт ясен как божий день. Еще один косяк в системе типов донета который Майкрософт упорно не хочет исправлять.

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

    У команде МС работающей над дотнетом теперь есть Меер который является одним из создателем Хаскеля. Так что у них есть кому объяснить. Если только возникает та же ситуация что у нас, когда другие члены команды не могут понять одного из них.

    Собственно на твоем месте я бы почитал что-нить о системе типов ML-я.
    Кстати апофеозом развития системы типов в ФЯ стали классы типов Хасклея. Очень интересная концепция близкая к интерфейсам явы/дотнета. Если не знаком с ней, очень советую познакомься.

    VD>>Потому что ты исходишь из неверных предпосылок. Нужно не заплаты придумывать, а ошибки исправлять.

    S>Ну, если есть детальное представление о том, как именно нужно исправить ошибку — то велкам.

    Куда? Меня в группу разработки CLR никто не завл. И даже мнения не спрашивал.
    В прочем, я там и н нужен. Меера достаточно. Просто нужно постараться понять то, что он говорит.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[29]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 11:37
    Оценка:
    Здравствуйте, VladD2, Вы писали:
    VD>И какие здесь проблемы?
    Простые. Будет ли верифицироваться операция подписки на событие, если аргументом делегата выступает один из структурно-совместимых типов, а аргументом события — потомок другого.
    VD>Тут много вариантов решения. Самое простое решение — обязать помечать типы помечаемые атрибутом структурной идентичности модификатором sealed.
    Или, что в принципе то же самое, реализовать их как value-типы. Один хрен reference-семантика им только мешает.

    VD>Не выдумывай. Данная возможность реализована в большинстве ФЯ. Так что все проблемы надуманы. Просто не надо жить в догмах системы типов донета. Надо ее немного расширить.

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

    VD>Я считаю, что коваринтность массивов — это ошибка дизайна. На практике данная возможность практически не используется, но вреда для производительности создает не мало. Но это отдельная тема.


    VD>В данном случае массивы обязаны быть совместимы просто потому, что два таких типа обязаны рассматриваться как один. В прочем, даже если это будет не так особых проблем не возникнет.


    VD>Мой ответ — нет.

    В таком случае полезность от анонимных типов резко уменьшится. Смотри: наследоваться ты им только что запретил; интерфейсы в них никак не реализуешь.
    Это означает, что надо быть крайне осторожным при изготовлении кода. Уже не получается сделать метод AddFinancialSecurityCheck, который гарантирует запрет доступа младшего персонала к любым документам с суммой больше $5000 USD. Этот метод будет гвоздями прибит к совершенно конкретному типу результата.
    Это, конечно, не так плохо, как сведение всех запросов к небольшому набору full-blown classes с ORM, но всё равно снижает возможности по декомпозиции.
    VD>Но, если что можно произвести копирование через совместимый по типам кортеж. Вот кортежи должны сравниваться только по типам элементов.
    Угу.

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

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

    VD>Копирование должно осуществляться только для типов между которыми оговорена структурная идентичность. Потом под копированием я понимаю создание нового экзепляра одного типа, на основе данных другого, а не банальное переписывание памяти.

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

    VD>Откровенно говоря не понимаю причем тут приведение IEnumerable<T> и T[]. Я, видимо, потерял ход мысли.

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

    VD>Собственно на твоем месте я бы почитал что-нить о системе типов ML-я.

    VD>Кстати апофеозом развития системы типов в ФЯ стали классы типов Хасклея. Очень интересная концепция близкая к интерфейсам явы/дотнета. Если не знаком с ней, очень советую познакомься.

    VD>Куда? Меня в группу разработки CLR никто не завл. И даже мнения не спрашивал.

    Зато я могу написать гадостей в csharp-insiders mailing list. Что я и делаю, но у меня не хватает компетентности.

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

    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[25]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 12:09
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>А кто сказал, что она непрозрачна?

    S>Никто не сказал. Но я не имею опыта эксплуатации системы, где хранимки автоматически порождаются Just In Time и убиваются, когда они больше не нужны.

    Они не порождаются just-in-time
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[27]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 12:17
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Лучше более обще опишу: есть выборка, полученная наложением кучи условий, соединений, группировок (неважно каких).

    G>В интерфейсе эта выборка используется в двух местах, в каждом из них надо отображать свой набор полей выборки, со своими условиями сортировки.
    G>Внимание вопрос: это будет две разные хранимки?

    it depends.
    Если это отчёт для экспорта в Excel и печати на принтере, то два разных запроса.
    Если это данные которые потенциально могут редактироватся, то скорее всего один запрос.
    Возможно, если сама сущность тяжёлая, например у сотрудника фотография 5 на 6 метров, и тяжёлая часть (фотография) нужна редко, то, возможно, что список сущностей будет загружаться в два этапа. Экономить память и трафик иногда не передавая дату рождения из 8 байт я считаю не разумным.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[25]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 12:21
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>1. Если ты хотел гарантий согласованности, то читал бы их в одной транзакции с уровнем изоляции Serializable и никакой несогласованности бы не увидел. RTFM.


    Ага, только вот между чтениями может пройти существенное количество времени (минуты). Не вариант.

    S>2. Про штампы времени ты допустил ошибку: у тебя вовсе не "последние версии таблицы городов". Сама постановка вопроса показывает наличие клина в голове: ты не получал в результате никаких таблиц. Ты получил результат запроса. Результат запроса c (CityName, CustomerCount), естественно, устарел.

    S>Теперь специально для тех, кто быстро пишет и медленно думает, поясняю, каким образом работает timestamp-based cache refresh в приведенном тобой случае.
    S>
    S>

    S>Понятно, как это работает?

    Ты не обеспечиваешь целостность данных, ты просто позволяешь эффективно читать обновления. Это вообще другая задача.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[30]: Nemerle & Real Life
    От: mrTwister Россия  
    Дата: 20.04.09 12:31
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Это миф.


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

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


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

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


    С чего ты это взял? (hint: учитываем только NHibernate)
    лэт ми спик фром май харт
    Re[33]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 12:38
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>Каким образом интеснивность работы пользователя зависит от размера кеша?

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

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

    A>>Нет. Мы говорим об клиенте и апп-сервере

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

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

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


    Нет большого смысла использовать Linq, когда все нужные объекты помещаются в ОЗУ. Нет, конечно есть Linq2Objects, но лично мне это показалось не очень адекватным решением.
    Современный, так называемый, тонкий клиент это 400МГц процессора, 256Мб памяти, 300Мб свободных на флешке и Windows XP Embedded. То есть тонкий клиент в обычном понимании программиста (что-то типа браузера) и тонкий клиент сходящий с заводов несколько разные вещи.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[27]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 12:41
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>И там тоже можно забыть.

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

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

    A>>Это не те права доступа, о которых я говорил.

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

    Э нет, я говорю о тех правах, которые все только обещают сделать и оставляют на потом, а в итоге так и не делают нормально. То что ты говоришь надо в одном месте, для одногоо бизнес-процесса. То о чём говорю я, нужно всегда. Я уже насмотрелся как кассир в Батуми принимал деньги от доставки Кутаиси в кассу Телави. Ссылочная целостность прав доступа — очень важная вещь.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[26]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 12:43
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Они не порождаются just-in-time
    В таком случае где же "прозрачность"? Прозрачность должна обеспечивать независимость клиента от того, успел ли сервер прогнать скрипты обновления для нужной версии.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[31]: Nemerle & Real Life
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 20.04.09 12:44
    Оценка:
    Здравствуйте, mrTwister, Вы писали:

    VD>>Это миф.


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


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

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


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


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

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


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


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

    На сегодня linq (EF) движется в сторону NHibernate. И на мой взгляд — это совершенно не верное направление.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[27]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 12:58
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

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

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

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

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


    Это, вообще говоря, не верно. Налагая условия на схему БД можно прочесть полностью целостную реплику БД вообще без уровней изоляции, а эта задача куда более жёсткая, чем то, что нужно мне.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[30]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 20.04.09 13:14
    Оценка:
    Здравствуйте, 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.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[28]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 13:17
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>У етбя получится очень сложная проверялка ссылочной целостности.
    При чем тут RI? Она ортогональна безопасности.


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

    A>Я уже насмотрелся как кассир в Батуми принимал деньги от доставки Кутаиси в кассу Телави. Ссылочная целостность прав доступа — очень важная вещь.
    Непонятно, о чем ты говоришь. Ограничения на то, кто где должен иметь право принимать деньги — это как раз бизнес-логика. И именно ее лучше делать так, как я говорю.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[32]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 13:17
    Оценка:
    Здравствуйте, Cyberax, Вы писали:
    C>Что ты привязался к FindByName?? В нормальных ORM есть свой язык запросов, кроме того, есть ещё навигационный доступ.
    Надо отличать язык объектных ограничений от языка структурированных запросов, в котором есть вывод типов и прочие нюансы.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[32]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 20.04.09 13:23
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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


    Это не будет компилироваться.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[28]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 13:34
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Я уже показал как, но ты видимо так и не понял.

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

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

    Ок, от подграфа мы отошли к каким-то "необходимым для работы" записям.

    A>В кеше клиентского ПО можно хранить только вышеупомянутое подмножество.

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

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

    При этом ты путаешь понятия ссылочной целостности и актуальности данных. Печально.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[31]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 13:34
    Оценка:
    Здравствуйте, 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.
    Я против.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[32]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 20.04.09 13:51
    Оценка:
    Здравствуйте, 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>Я против.

    Напрасно. Мне это тоже не нравится, но отсальное не нравиться ещё больше.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[31]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 14:08
    Оценка:
    Здравствуйте, 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 отжигают; народ из команды как-то так, значительно менее активен. Но я попробую.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[33]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 20.04.09 14:08
    Оценка:
    Здравствуйте, IT, Вы писали:

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

    а! Ну, так мы же говорим о (в основном) анонимных типах и приравненных к ним именованных типах.
    Был автопроперти — будет автометод

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

    Не понял. Как дополнительные методы помешают компилятору проверить корректность выражения, которое принимает Order и возвращает новый Order?

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

    А-а, вон ты про что. Тогда, наверное, придется писать Delayd = true

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

    Ты смотрел на Building IQueryable Provider XIII?
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[32]: Nemerle & Real Life
    От: mrTwister Россия  
    Дата: 20.04.09 14:09
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    VD>>>Это миф.


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


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


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

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


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


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


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

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


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

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


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


    У меня сложилось иное впечатление.
    лэт ми спик фром май харт
    Re[34]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 20.04.09 14:34
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    S>Ты смотрел на Building IQueryable Provider XIII?

    Смотрел, мне семантика == тоже не нравится по тем же причинам — перекладывание большинства проверок на рантайм.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[32]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 20.04.09 15:05
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Ну вот собсно основная штука в value-семантике — именно "сравнение работало корректно (по значениям полей)". Или я неправильно понимаю разницу между value- и reference- семантиками?


    Дык операторы и методы сравнения можно переопределить как надо. Для тех же кортежей в немерле так и сделано.

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

    S>Ну, я что вижу — то пою. Вот ты ссылку дал про ML — надо будет посмотреть.

    Я могу сказать как разработчик (фактический) того же Nemerle. Я не стал возиться с анонимным типами по двум причинам.
    1. Не хочется вводить в язык неполноценное решение.
    2. Есть кортежи которые и так позволяют решать проблему и при этом являются полноценным решением.
    Однако я с удовольствием сделал бы поддержку полноценных анонимных типов а-ка записей если бы их поддерживал CLR.

    VD>>Я вообще не понимаю, почему ты не критикуешь скажем анонимные типы C#-а. Ведь они не допускают наследования.

    S>Как это не критикую? Собсно, все мои потребности в записях связаны именно с убогостью существующих анон.типов.

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

    S>Ну, так я согласен. Осталось понять, как решить эту проблему.


    Дык надо всего лишь позволить рассматривать два типа как один если у них одинакова структура. Пусть будут запрещено наследование. Это не помеха. Тогда останется придумать и реализовать синтаксис для описания анонимного типа.

    И главное понять, то этот не имеет никакого отношения к ООП. По этому не стоит рассуждать об инкапсуляции, полиморфизме и прочем (хотя последнее как раз весьма возможно).

    S>OMFG, 422 results. Да, это определенно достаточно много работ, чтобы занять меня на следующие тридцать вечеров пятницы.


    Реально толковых ссылок там не так. Много я если тебе действительно интересен вопрос, то я бы все же начал с вопроса в Декларативном программировании. Там есть народ который такие работы вместо газет на за завтраком читал .

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

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

    Именно так. И именно по этому нужно менять рантайм.

    VD>>Это было бы полезно. Не уверен на счет обраного. Впрочем явное приведение было бы тоже полезно.

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

    А вот это должен скрывать рантайм. Для меня все должно быть прозрачно. Семантика должна быть как у типов-значений, но при этом сами типы могут быть просто не изменяемыми.

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

    S>Надо проверять в реальных сценариях и смотреть, нет ли несовместимых с жизнью проблем с перформансом.

    Это все проверено сто раз в функциональных языках. Даже нехилая теория под это дело подведена.

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

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

    S>Я не упираюсь.

    Дык это и радует!

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


    Решение уже апробировано в ФЯ. Это записи. Анонимные типы и были содраны с них. В общем, найди литературу описывающую записи и кортежи в ML-подобных языках и сам все увидишь.

    Объекты с одинаковой структурой можно сравнивать и копировать без опасений и проблем. Проблема только в поведении рантайма. Он вместо проверки совместимости на уровне типов дотнета должен осуществлять банальную структурную проверку. В реальной реализации конечно надо будет создать таблицу структурной совместимости типов и при осуществлять проверку через нее.

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

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

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

    S>Ну, там пока в основном другие MVP отжигают; народ из команды как-то так, значительно менее активен. Но я попробую.


    Кстати, интересно о чем они там говорят? Что их интересует? Почему-то подозреваю, что разная мелочевка.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[33]: Nemerle & Real Life
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 20.04.09 15:08
    Оценка:
    Здравствуйте, mrTwister, Вы писали:

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


    Я обосновал свое утверждение.

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


    Ты писал о защите. Я тебе продемонстрировал, что защита весьма мнимая. Чем более сложными вещами ты занимаешься, тем меньше вероятность того, что баги на которые ты напоролся будут устранены майкрософтом.

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


    А что тебе дает лэйбак Майкрософт? В чем защита то? Ты же говорил о вере в том, что МС исправит какие-то там ошибки...
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[25]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 20.04.09 15:28
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    L>>Мы сами подобное используем, я имею в виду создание отдельных PE для отдельных страниц. И меня совершенно не радует созерцать кучу одноразовых классов. Так что так уж однозначно называть этот способ правильным я бы не стал.

    S>А что именно в одноразовых классах тебя смущает?

    Меня смущает то, что со временем эта куча превращается в помойку, т.к. никакой внятной схемы именования подобных классов мне придумать не удалось.

    S>Меня вот гораздо больше смущает насильственное использование плохо приспособленных классов.

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

    Был бы аналог удобного глобального вывода типов для анонимных классов, было бы удобно. А так приходится созерцать эти унылые CustomerInfo...

    L>>Но это не является параметром выборки

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

    Свойство хорошее слово. Его оставим как есть.

    L>>Не один, а пачка: если у кастомера в адресе нужно выбрать город, то здравствуй новая PE с двумя полями ID и Name.

    S>Ну и что? Какие проблемы? Я не очень понимаю, что ты имеешь в виду под PE.

    PE = Presentation Entity

    S>Будет просто свойство ViewModel, в котором лежит коллекция пар ID и Name. Всё очень здорово и удобно.


    Удобно, если ID и Name. Но если полей становится больше 2-3-х, то получаем кучу унылого говно-кода.
    Re[29]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 15:29
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>В базе данных можно выделить такое подмножество записей, что любая из этих записей будет ссылаться (foreign key) только на записи того же подмножества.

    S>Это да. Можно выделить связный подграф.

    О, графы это хорошо, молодец. Хотя я тут не согласен насчёт терминологии. Мы выделяем некоторое подмножество сущностей, такое, что сущности из подмножества связаны (есть ссылка) только с сущностями из того же подмножества. Связанность подграфа тут не обязательна. Скажем, если взять пять сущностей
    A <- B <- C -> D -> E

    то (A, B, D, E) будет ссылочно-целостным подмножеством. Подграф A, B, D, E не связанный, но это и не надо. Гораздо важнее что ни одна из сущностей A, B, D, E не ссылается на С — сущность вне подмножества.

    A>>Добавление записей не входящих в данное подмножество непосредственно, не расширяет его.

    S>Этого утверждения я не понял. Добавление куда? Не расширяет кого?

    Это очень просто. Пусть есть 4 сущности: A, B, C, D. Пусть они ссылаются друг на друга следующим образом A->B, A->C, D->A, D->B. Одним из указанных мною подмножеств будет (A, B, C). Хотя D и ссылается на сущности A и B, важно что A, B и C не ссылаются на D. Теперь, если добавить сущность E и ссылки E->A, E->C, то на (A, B, C) это никак не отразится и (A, B, C) останется ссылочно-целостным подмножеством сущностей.

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

    S>Ок, от подграфа мы отошли к каким-то "необходимым для работы" записям.

    Нет. Речь идёт о минимальном ссылочно-целостном подмножестве сущностей включающем в себя все данные необходимые для работы.

    S>1. Этих записей значительно, на порядки, меньше общего количества записей.


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

    S>2. Обеспечение актуальности кэша именно этих записей обеспечивает ссылочную целостность всей БД


    Обеспечение ссылочной целостности этого кеша обеспечивает корреткность операций. Не допустимость, а корректность. Для большинства операций нет необходимости иметь последние, потому что для большинства операций необходимые данные в кеше не меняются. Как часто, например, меняется список филиалов, клиентов, товаров? Так ли необходимо иметь актуальную версию списка при оформлении каждой операции, а следовательно перед каждой операцией проверять обновления?

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

    Более того, есть мобильные торговые агенты. Человек берёт в руки покет, изредка ноутбук, и ездит по клиентам. "Ловит" не везде. Заказ, на уже заблокированного клиента может быть успешно сохранён в кеш, а загрузка его в центральную БД, и отказ в оформлении, произойдёт только вечером. Тут тоже нет никакой катастрофы. Если данный кеш ссылочно-целостный, то у меня не самая последняя версия БД, но достаточная для работы. Это значит, что просматривая объекты кеша и переходя по ссылкам мне не потребуется что-то запрашивать с сервера.

    S>3. Обеспечение актуальности кэша именно этих записей менее затратно, чем обеспечение актуальности кэша результатов конкретных запросов.


    По трафику и количеству запросов, без сомнения.

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

    S>При этом ты путаешь понятия ссылочной целостности и актуальности данных. Печально.

    А вот актуальность я не обещал. Без push со стороны сервера это не реально.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[31]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 20.04.09 15:30
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    L>>>>

    L>>>>Например, некоторые параметры не хранятся один-в-один в полях таблицы, а сериализуются в xml-ную колонку. Наличие DAL-а позволяет этот механизм хранения скрыть от бизнеса, что, имхо, очень удобно и позволяет очень просто дополнять поля сущности.


    L>>Отсутствие DAL-а, вестимо. Entity-то отличается от схемы данных.


    G>От повторения одного и того же оно правдой не становится. В EF маппинг, даже нетривиальный, делается без DAL.


    Расскажи, как мне сделать в EF маппинг полей сущности на xml-колонку. С удовольствие послушаю.
    Re[34]: Nemerle & Real Life
    От: mrTwister Россия  
    Дата: 20.04.09 15:30
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Я обосновал свое утверждение.


    Я тоже.

    VD>Ты писал о защите. Я тебе продемонстрировал, что защита весьма мнимая. Чем более сложными вещами ты занимаешься, тем меньше вероятность того, что баги на которые ты напоролся будут устранены майкрософтом.


    VD>А что тебе дает лэйбак Майкрософт? В чем защита то? Ты же говорил о вере в том, что МС исправит какие-то там ошибки...



    Для тех, кто не читает чужих сообщений, повторю еще раз:

    больше вероятность того, что кто-то другой до тебя найдет workaround твоих проблем и опубликует его в интернете.


    Где тут хоть слово про исправление майкрософтом ошибок?
    Речь о том, что в случае с любой известной и распространенной библиотекой (не обязательно от МС) можно просто набрать в гугле свою проблему и по первой-второй ссылке узнать, как другие пользователи решили эту проблему. Соответственно, чем более экзотическую библиотеку ты используешь, тем больше вероятность того, что тебе самому придется решать твою проблему, тратя на это уйму времени. Отличительной особенностью библиотек от МС является то, что они будут сильно распространены даже если они хреновые.
    лэт ми спик фром май харт
    Re[33]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 20.04.09 15:50
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    L>>>>

    L>>>>MVC is often seen in web applications, where the view is the actual HTML or XHTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML or XHTML.

    L>>>>Ты все еще уверен, что я неправильно понимаю MVC?

    VD>>>MVC — это общий архитектурный паттерн и допускает очень вольную трактовку. Но основная суть его — это отделение логики данных от презентационной логики и от логики управления.


    L>>Странно, а пару часов назад было

    L>>

    L>>Ни модель, ни представление не должны знать о контроллере.

    L>>

    VD>А что в приведенных цитатах есть противоречия?


    Противоречие тут в том, что ты утверждаешь, что view лезет в модаль за данными.
    В приведенной же цитате говорится, что controller подготавливает эти данные для view, а следовательно ни в какую модель view лезть не должен.

    VD>>>Так что чем квотить мелкий кусочик из википедии (не являющейся точным источником данных, кстати) ты прочел бы хотя бы весь раздел. А еще лучше прочитай первоисточник.


    L>>

    L>>Unlike the model, which may be loosely connected to multiple MVC triads, Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling.

    L>>

    VD>Опять же, что ты тут вычитал?


    Ни модель, ни представление не должны знать о контроллере.

    vs

    Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling.


    Как можно не знать о контероллере и при этом иметь ссылку на него?

    L>>>>Да все это понятно. Поинт лишь в том, что пихать это в presentation — последнее дело.


    VD>>>Что это? Доступ к модели? А куда же его пихать, то?


    L>>В контроллер, другого не остается.


    VD>Иди и еще раз прочитай задачи контроллера. Если в контроллере будет логика отображения, то это будет смешиванием логики отображения и логики управления, то есть нарушением базового принципа MVC.


    Совершенно верно, логике отображения не место в контроллере.
    Но только вот формирование запросов к логике отображения не относятся вообще никаким боком. И потому-то им во view и не место.

    VD>Короче, в данной теме я не намерен продолжать обсуждение паттерна MVC. Если тебе интересно, заводи новую тему.


    Слив засчитан.

    L>>>>UI должен быть туп как пробка и не должен содежать ни методов для формирования чего-либо, ни оперировать запросами.


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


    L>>Если подходить формально, то ты прав. А на практеке от кода еще стребуется как минимум тестируемость. Если мы зашиваем часть логики запросов в представление, мы эту возможность теряем.


    VD>Интересный поворот. С доказательством нарушения принципов MVC не вышло, переключаемся на тестирование...


    Задача view — рендеринг UI и только. Формирование запросов к UI никакого отношения не имеет.

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


    Презентационную логику ни в коем случае не надо выносить из представления. Выносить оттуда нужно запросы.

    L>>Как тогда скрывать детали маппинга? Я кажется, догадываюсь, что ты ответишь. В задницу сокрытие деталей. Оно?


    VD>У тебя будут объекты на которые идет отображение. Вот они и будут скрывать все что нужно. Можешь считать их DAL-ом.

    VD>Мне больше нравится терминология MVC. В ней данные объекты являются публичным интерфейсом модели.

    Тут согласен, можно и иначе сделать. +1.
    Re[35]: Nemerle & Real Life
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 20.04.09 17:18
    Оценка:
    Здравствуйте, mrTwister, Вы писали:

    T>Я тоже.


    Где?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[26]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 18:28
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Нет, я не потребовал. Я показал, что кеширование отдельных запросов без преобразования в объекты приводит к несогласованности данных кешах запросов. А вот если собрать граф объектов, то такой несогласованности не будет.

    G>>Именно эта фраза подтевржадет то что кеш в ORM-системах может быть только глобальный.

    A>Ты не прав Вполне можно построить ссылочноцелостное подмножество данных БД, по объёму значительно меньше данныхв БД.

    Это называется локальной репликой — далеко не единственный и уж точно не самый эффективный вариант кеширования.
    Шорош только тем, что его проще всего построить.
    Основной особенностью такого кеша является то, что из него нельзя выделить часть без нрушения работоспособности кеша. Это значит что имеет смысл создавать один глобальный кеш для приложения, а не кешировать локально результаты запроса.

    Если еще и хочется запросы делать к кешу, то можно использовать inprocess БД.

    G>>Кажестся я уже описывал, что эта задача и другими способами нормально не решается.

    G>>Вообще если между двумя запросами свзязанных данных проходит какое-то время, то всегда можно нарваться на рассогласованность, и без пессимистичной блокировки этих данных в общем случае победить такое нельзя.

    A>Ты опять таки не прав.

    Ну а обоснования будут?
    Re[28]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 18:38
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Лучше более обще опишу: есть выборка, полученная наложением кучи условий, соединений, группировок (неважно каких).

    G>>В интерфейсе эта выборка используется в двух местах, в каждом из них надо отображать свой набор полей выборки, со своими условиями сортировки.
    G>>Внимание вопрос: это будет две разные хранимки?

    A>it depends.

    A>Если это отчёт для экспорта в Excel и печати на принтере, то два разных запроса.
    A>Если это данные которые потенциально могут редактироватся, то скорее всего один запрос.
    A>Возможно, если сама сущность тяжёлая, например у сотрудника фотография 5 на 6 метров, и тяжёлая часть (фотография) нужна редко, то, возможно, что список сущностей будет загружаться в два этапа. Экономить память и трафик иногда не передавая дату рождения из 8 байт я считаю не разумным.

    А теперь без теории.
    Мега-генератор хранимок как работает?
    Re[30]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 18:55
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

    S>>При чем тут RI? Она ортогональна безопасности.

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

    Если юз-кейсы другие что делать? Переписывать генератор хранимок?

    A>>>Я уже насмотрелся как кассир в Батуми принимал деньги от доставки Кутаиси в кассу Телави. Ссылочная целостность прав доступа — очень важная вещь.

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

    A>Еси делать права доступа на операции, то получится код, проверяющий, что касса, кассир и сдающий деньги числятся за одним и тем же филиалом. Это код и это не гибко.

    Какой код? Это установка PrincipalPermisiion на методе.

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

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

    Вообще RBS для операций подходит для 95% сценариев.

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

    Ты видимо живешь в своей особенной реальности, созданной множеством ошибок при разработке одной программы.
    Re[32]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 19:04
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

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


    L>>>>>

    L>>>>>Например, некоторые параметры не хранятся один-в-один в полях таблицы, а сериализуются в xml-ную колонку. Наличие DAL-а позволяет этот механизм хранения скрыть от бизнеса, что, имхо, очень удобно и позволяет очень просто дополнять поля сущности.


    L>>>Отсутствие DAL-а, вестимо. Entity-то отличается от схемы данных.


    G>>От повторения одного и того же оно правдой не становится. В EF маппинг, даже нетривиальный, делается без DAL.


    L>Расскажи, как мне сделать в EF маппинг полей сущности на xml-колонку. С удовольствие послушаю.

    В ssdl можно указать запрос, который получает для получения сущностей (Defining query кажись).
    Кроме того в MS SQL 2008 есть sparse columns, которые делают тоже самое, но на уровне БД.
    Вообще говоря инкапсуляция на уровне БД гораздо эффективнее и удобнее.
    Re[27]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 19:11
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Шорош только тем, что его проще всего построить.


    А чем плох, не написал.

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


    G>Если еще и хочется запросы делать к кешу, то можно использовать inprocess БД.


    Кеш может жить не дольше самого приложения.

    G>>>Вообще если между двумя запросами свзязанных данных проходит какое-то время, то всегда можно нарваться на рассогласованность, и без пессимистичной блокировки этих данных в общем случае победить такое нельзя.

    A>>Ты опять таки не прав.
    G>Ну а обоснования будут?

    А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[29]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 19:16
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Если это отчёт для экспорта в Excel и печати на принтере, то два разных запроса.

    A>>Если это данные которые потенциально могут редактироватся, то скорее всего один запрос.
    A>>Возможно, если сама сущность тяжёлая, например у сотрудника фотография 5 на 6 метров, и тяжёлая часть (фотография) нужна редко, то, возможно, что список сущностей будет загружаться в два этапа. Экономить память и трафик иногда не передавая дату рождения из 8 байт я считаю не разумным.
    G>А теперь без теории.
    G>Мега-генератор хранимок как работает?

    На практике, так.

    Если это отчёт для экспорта в Excel и печати на принтере, то два разных запроса.

    Отчёты пока в виде отдельных хранимок и это катастрофа. Я их потихоньку перевожу на Linq. Буду его использовать только для отчётов. Провайдер Linq свой.

    Если это данные которые потенциально могут редактироватся, то скорее всего один запрос.
    Возможно, если сама сущность тяжёлая, например у сотрудника фотография 5 на 6 метров, и тяжёлая часть (фотография) нужна редко, то, возможно, что список сущностей будет загружаться в два этапа. Экономить память и трафик иногда не передавая дату рождения из 8 байт я считаю не разумным.


    Генератор умеет разбивать объект на два куска — маленький грузящийся всегда и большой грузящийся по требованию. Как разбивать решает программист.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[31]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 19:22
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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

    G>Если юз-кейсы другие что делать? Переписывать генератор хранимок?

    А нет других юз-кейзов Переписывать генератор не надо, можно менять права доступа.

    A>>Вот это-то и есть ошибка, котрую я уже много раз видел — права доступа не на объекты, а на операции.

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

    Я на этот очень правильный подход уже насмотрелся — он хорош в теории и, быть может, в лабе. На практике от него одни проблемы.

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

    G>Неверно. Для этого надо включить пользователя в другую группу.

    Нельзя, он тогда должен быть сразу в двух группах-филиалах.

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

    G>Ты видимо живешь в своей особенной реальности, созданной множеством ошибок при разработке одной программы.

    А ты всё никак не приведёшь контрпримеры. А ошибки не мои, это Microsoft Dynamics NAV, например. Часто бывало что операцию запретишь, а её всё равно можно через другое окно сделать.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[32]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 20.04.09 19:38
    Оценка:
    Здравствуйте, adontz, Вы писали:


    A>>>Вот это-то и есть ошибка, котрую я уже много раз видел — права доступа не на объекты, а на операции.

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

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

    G>>Неверно. Для этого надо включить пользователя в другую группу.
    A>Нельзя, он тогда должен быть сразу в двух группах-филиалах.
    В RBS членство в нескольких группах — нормальное явление.

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

    G>>Ты видимо живешь в своей особенной реальности, созданной множеством ошибок при разработке одной программы.

    A>А ты всё никак не приведёшь контрпримеры. А ошибки не мои, это Microsoft Dynamics NAV, например. Часто бывало что операцию запретишь, а её всё равно можно через другое окно сделать.

    Отсуствие тестирования и кривость рук разработчиков теперь будем лечить введением row-level security?

    Кроме всего прочего RBS позволяет описывать гораздо больше сценариев, чем row-level security.
    Пример Синклера: "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" отлично описывается в RBS, и нифига не работает в варианте row-level security.
    Re[29]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 21:48
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Кеш может жить не дольше самого приложения.

    G>С чего бы?
    G>Вот Янус и почта так работает.

    Может в смысле may, а не can.

    A>>А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо.

    G>Еще раз. Я (и не только) говорю что сохранить согласованность данных между двумя запросами в общем случае можно только используя транзакционные методы (блокировки).
    G>Ты так и не смог доказать обратного. Частные случаи, вероятности и отстраненные размышения мало интересуют.

    Ты (и не только) говорите глупость. Нельзя обеспечить актуальность и согласованность. Согласованность обеспечить можно.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[33]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 20.04.09 21:53
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Я на этот очень правильный подход уже насмотрелся — он хорош в теории и, быть может, в лабе. На практике от него одни проблемы.

    G>И какие проблемы?

    Сложная и слабо контролируемая система прав доступа, в которой практически всегда у кого-то есть права больше, чем должны быть.

    G>>>Неверно. Для этого надо включить пользователя в другую группу.

    A>>Нельзя, он тогда должен быть сразу в двух группах-филиалах.
    G>В RBS членство в нескольких группах — нормальное явление.

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

    A>>А ты всё никак не приведёшь контрпримеры. А ошибки не мои, это Microsoft Dynamics NAV, например. Часто бывало что операцию запретишь, а её всё равно можно через другое окно сделать.

    G>Отсуствие тестирования и кривость рук разработчиков теперь будем лечить введением row-level security?

    О да, все в дерьме и только ты в белом. Недостаточное тестирование и кривость рук это факторы существующие в любом проекте.

    G>Кроме всего прочего RBS позволяет описывать гораздо больше сценариев, чем row-level security.

    G>Пример Синклера: "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" отлично описывается в RBS, и нифига не работает в варианте row-level security.

    А и не должен работать, row-level security решает другие задачи.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[33]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 20.04.09 23:51
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    L>>Расскажи, как мне сделать в EF маппинг полей сущности на xml-колонку. С удовольствие послушаю.

    G>В ssdl можно указать запрос, который получает для получения сущностей (Defining query кажись).

    Значение колонки вряд ли можно отнести к сущностям.

    G>Кроме того в MS SQL 2008 есть sparse columns, которые делают тоже самое, но на уровне БД.

    G>Вообще говоря инкапсуляция на уровне БД гораздо эффективнее и удобнее.

    Поднимись выше по ветке и посмотри, по каким причинам понадобилась xml-колонка.
    Re[30]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 02:54
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Кеш может жить не дольше самого приложения.

    G>>С чего бы?
    G>>Вот Янус и почта так работает.
    A>Может в смысле may, а не can.
    И что? Сам придумал сограничения, а тереь сам придумываешь оправдания.

    A>>>А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо.

    G>>Еще раз. Я (и не только) говорю что сохранить согласованность данных между двумя запросами в общем случае можно только используя транзакционные методы (блокировки).
    G>>Ты так и не смог доказать обратного. Частные случаи, вероятности и отстраненные размышения мало интересуют.
    A>Ты (и не только) говорите глупость. Нельзя обеспечить актуальность и согласованность. Согласованность обеспечить можно.
    Решение в студию
    Re[34]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 03:09
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Я на этот очень правильный подход уже насмотрелся — он хорош в теории и, быть может, в лабе. На практике от него одни проблемы.

    G>>И какие проблемы?
    A>Сложная и слабо контролируемая система прав доступа, в которой практически всегда у кого-то есть права больше, чем должны быть.

    RBS для операций гораздо проще в создании, поддержке и управлении, чем RLS.
    Только чтобы сделать RBS правильно думать надо. А вариант с RLS позволяет сказать "у меня все настраивается разрешениями, а дальше е****сь сами".

    G>>>>Неверно. Для этого надо включить пользователя в другую группу.

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


    A>>>А ты всё никак не приведёшь контрпримеры. А ошибки не мои, это Microsoft Dynamics NAV, например. Часто бывало что операцию запретишь, а её всё равно можно через другое окно сделать.

    G>>Отсуствие тестирования и кривость рук разработчиков теперь будем лечить введением row-level security?
    A>О да, все в дерьме и только ты в белом. Недостаточное тестирование и кривость рук это факторы существующие в любом проекте.
    И что? Затыкать проблемы разработчиков кривыми архитектурными решениями, пороздая только новые проблемы?
    Надо разработчиков учить, а не оберегать ((с) не помню кто)

    G>>Кроме всего прочего RBS позволяет описывать гораздо больше сценариев, чем row-level security.

    G>>Пример Синклера: "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" отлично описывается в RBS, и нифига не работает в варианте row-level security.
    A>А и не должен работать, row-level security решает другие задачи.

    Какие? И как решать задачу описанную выше?
    Re[31]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 03:13
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>>>Кеш может жить не дольше самого приложения.

    G>>>С чего бы?
    G>>>Вот Янус и почта так работает.
    A>>Может в смысле may, а не can.
    G>И что? Сам придумал сограничения, а тереь сам придумываешь оправдания.

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

    A>>>>А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо.

    G>>>Еще раз. Я (и не только) говорю что сохранить согласованность данных между двумя запросами в общем случае можно только используя транзакционные методы (блокировки).
    G>>>Ты так и не смог доказать обратного. Частные случаи, вероятности и отстраненные размышения мало интересуют.
    A>>Ты (и не только) говорите глупость. Нельзя обеспечить актуальность и согласованность. Согласованность обеспечить можно.
    G>Решение в студию

    gandjustas ты сперва заявляешь что локальная реплика это самое простое, что можно сделать, потом просишь меня показать решение. Ты уж как-нибудь определись с тем что ты знаешь, а что нет.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[32]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 03:21
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>>>Кеш может жить не дольше самого приложения.

    G>>>>С чего бы?
    G>>>>Вот Янус и почта так работает.
    A>>>Может в смысле may, а не can.
    G>>И что? Сам придумал сограничения, а тереь сам придумываешь оправдания.

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

    Причем тут язык?
    Я не вижу причин по которым согласованный слепок данных не может жить дольше приложения.

    A>>>>>А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо.

    G>>>>Еще раз. Я (и не только) говорю что сохранить согласованность данных между двумя запросами в общем случае можно только используя транзакционные методы (блокировки).
    G>>>>Ты так и не смог доказать обратного. Частные случаи, вероятности и отстраненные размышения мало интересуют.
    A>>>Ты (и не только) говорите глупость. Нельзя обеспечить актуальность и согласованность. Согласованность обеспечить можно.
    G>>Решение в студию
    A>gandjustas ты сперва заявляешь что локальная реплика это самое простое, что можно сделать, потом просишь меня показать решение. Ты уж как-нибудь определись с тем что ты знаешь, а что нет.
    Локальная реплика предлагается как решение?
    А чтобы получить согласованную реплику её не надо читать в одной транзакции? Может у тебя есть способы магического согласования данных в режиме read uncommited?
    Ты путаешь способ получения согласованных данных со способом их использования.
    Re[33]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.04.09 03:41
    Оценка:
    Здравствуйте, VladD2, Вы писали:
    VD>Дык операторы и методы сравнения можно переопределить как надо. Для тех же кортежей в немерле так и сделано.
    Операторы биндятся в компайл-тайме на основе статически известного типа аргументов. Поэтому нужно убедиться, что ни в одном из сценариев компилятор не потеряет тип.

    VD>Я могу сказать как разработчик (фактический) того же Nemerle. Я не стал возиться с анонимным типами по двум причинам.

    VD>1. Не хочется вводить в язык неполноценное решение.
    VD>2. Есть кортежи которые и так позволяют решать проблему и при этом являются полноценным решением.
    VD>Однако я с удовольствием сделал бы поддержку полноценных анонимных типов а-ка записей если бы их поддерживал CLR.

    VD>OK. Тогда поставим вопрос по другому. Ты же не говоришь, что проблема анонимных типов заключается в отсутствии наследования. Тебе не нравится, то что их нельзя возвращать из метода. Так?

    Ну да.

    VD>Дык надо всего лишь позволить рассматривать два типа как один если у них одинакова структура.

    Дык надо понять, что такое "структура". Набор полей? Набор свойств?
    VD>Пусть будут запрещено наследование. Это не помеха. Тогда останется придумать и реализовать синтаксис для описания анонимного типа.

    VD>И главное понять, то этот не имеет никакого отношения к ООП. По этому не стоит рассуждать об инкапсуляции, полиморфизме и прочем (хотя последнее как раз весьма возможно).

    Согласен.

    VD>Реально толковых ссылок там не так. Много я если тебе действительно интересен вопрос, то я бы все же начал с вопроса в Декларативном программировании. Там есть народ который такие работы вместо газет на за завтраком читал .

    Ок, посмотрим, как время будет.

    VD>А вот это должен скрывать рантайм. Для меня все должно быть прозрачно. Семантика должна быть как у типов-значений, но при этом сами типы могут быть просто не изменяемыми.

    Ну да, вот Nullable пришлось специальным образом хардкодить в рантайме, чтобы гарантировать корректные результаты при анбоксинге null и прочие весёлости.

    Я nen подумал о том, что для неизменяемых типов нужна специальный Property pattern.

    В CLR встроена возможность обозвать пропертью пару методов с сигнатурами void SetXXX(T value), T GetXXX().
    Для immutable-типов void SetXXX не подходит. Зато подойдет метод SetXXX, который возвращает новый экземпляр, который отличается от старого только значением свойства.
    Ну, и собственно сами проперти должны иметь тот же смысл.
    То есть мы пишем как-то так:
    var newDate = GetDate().Days += 1;


    VD>Это все проверено сто раз в функциональных языках. Даже нехилая теория под это дело подведена.

    Ну так в этих языках нет проблемы интероперабельности с CLR.

    VD>К тому же в реальных языках такие типы будут скрываться за интерфейсом каких-нить анонимных типов или записей.

    Вот это поинтереснее.

    VD>Так что на эти типы априори будут наложены более строгие ограничения. Например, для записей операторы сравнения будут генерироваться самим компилятором. Сравнение будет просто по полям (вызов Equals() для каждого члена). Просто соответствия структуры будет достаточно чтобы все работало как надо.



    VD>Ну, вот пусть они приведут воркэраунд позволяющий возвращать IQueryble<анонимный тип или список значений>.


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


    VD>Кстати, интересно о чем они там говорят? Что их интересует? Почему-то подозреваю, что разная мелочевка.

    Да, мелочевка — в том числе и поддержка туплов. Но в основном люди страдают ерундой. Например, некоторые C# MVP из Калифорнии искренне полагают, что switch("test") порождает словарь строк при каждом проходе.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[35]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.04.09 03:41
    Оценка:
    Здравствуйте, IT, Вы писали:
    IT>Смотрел, мне семантика == тоже не нравится по тем же причинам — перекладывание большинства проверок на рантайм.
    Каких проверок?
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[26]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.04.09 03:41
    Оценка:
    Здравствуйте, Lloyd, Вы писали:
    L>Меня смущает то, что со временем эта куча превращается в помойку, т.к. никакой внятной схемы именования подобных классов мне придумать не удалось.
    Ну, идеально было бы их вообще не именовать.

    L>Был бы аналог удобного глобального вывода типов для анонимных классов, было бы удобно. А так приходится созерцать эти унылые CustomerInfo...

    Называй класс по имени View.


    L>PE = Presentation Entity


    L>Удобно, если ID и Name. Но если полей становится больше 2-3-х, то получаем кучу унылого говно-кода.

    Откуда взялся говнокод?
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[30]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.04.09 03:41
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

    Это ошибка. Ты не обратил внимание на то, что в большинстве СУБД права на REFERENCE отделены от прав на SELECT?

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

    Этот код должен просто быть декларативным. И это гибко.

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

    Зачем переписывать? Если человек не имел права направлять машины в Тбилиси до ограбления, то не должен иметь право и после — может быть, это он и организовал это ограбление. Если кассу в Телави ограбили, то решение должен принимать человек с несколько большими полномочиями, чем региональный менеджер.

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

    Ну, собственно, вывод прав на операции над одними объектами из прав на операции над другими объектами — тоже некоторая бизнес-логика. Просто у тебя вот такой бизнес-случай. У кого-то — другой. Пойми, что RBS покрывает все сценарии, в том числе и RLS. RLS — это просто частный случай, с правилами, вычисляемыми над Discretionary Access Control Lists.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[36]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 03:44
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>RBS для операций гораздо проще в создании, поддержке и управлении, чем RLS.

    G>>Только чтобы сделать RBS правильно думать надо. А вариант с RLS позволяет сказать "у меня все настраивается разрешениями, а дальше е****сь сами".
    A>Это всё только в теории. Практика показывает что управляемыми являются права доступа на элементарные операции над объектами, а не сложные бизнес-процессы.
    Хреновая у тебя практика. RLS требует оперированием разрешениями на кучи объектов. При правильном подходе с RBS разрешений в разы меньше, но они с таким же успехом покрывают все потребности.

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

    G>>А что значит "дополнительных"? В RBS группы (в смысле роли) создаются как раз для разделения групп разрешений.

    A>Да-да-да, это и есть убогость. Подобная ситуация наблюдается в файловой системе старых Линуксов и Юниксов, где невозможно тонко раздать разрешения на объект и в итоге создаётся куча дополнительных групп пользователей, потом появляются всякие sudo, запись в файл через нарошный пайп и прочие извращения. Ты глубоко уверен что говоришь о чём-то прогрессивном, то твоим ошибкам уже лет 30. Сейчас у нас есть seLinux, HP-UX в которые сие исправили, потому что ошибка. Подожду 30 лет пока и ты эволюционируешь.


    Так и знал что ты скатишься к ФС. Банально.
    Посмотри разрешения в Windows — все привелегии раздаются в стиле RBS, а права на доступ к файлам — ACL. Причем при появлении XP именно ACL вызывали наиболшине непоняки и сложности в настройке (а у некоторых до сих пор вызывают).
    Но для файлов другого не придумаешь. Если бизнес-системе есть какой-то контент, аналогичный по сути файлам в ФС, то для него имеет смыл RLS с ACL.
    Разрешениями на высокоуровневые операции (аналог привелегий в ОС) гораздо удобнее управлять в RBS.
    Так что эволюционировать тебе надо.

    A>>>О да, все в дерьме и только ты в белом. Недостаточное тестирование и кривость рук это факторы существующие в любом проекте.

    G>>И что? Затыкать проблемы разработчиков кривыми архитектурными решениями, пороздая только новые проблемы?
    G>>Надо разработчиков учить, а не оберегать ((с) не помню кто)
    A>О нет, fine grained access rights это как раз правильная архитектура.
    Ага, в переводе на русский звучит "с настройкой прав е****сь сами". Пользователями обычно нету дела до fine grained access rights на такие сущности как "филиал", "покупатель" итп.

    G>>>>Кроме всего прочего RBS позволяет описывать гораздо больше сценариев, чем row-level security.

    G>>>>Пример Синклера: "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" отлично описывается в RBS, и нифига не работает в варианте row-level security.
    A>>>А и не должен работать, row-level security решает другие задачи.
    G>>
    G>>Какие? И как решать задачу описанную выше?

    A>Я в последний раз пытаюсь до тебя донести элементарную истину. Row level security решает задачи доступа не требующие анализа объектов. Это настолько часто встречающаяся задача, что её крайне выгодно выделить в отдельную универсальную подсистему. Есть задачи которые в RLS не укладываются и их надо решать отдельно, но это не значит что универсальная система RLS перестала быть выгодной или раздавать права на объекты стало ошибкой.


    Ага, есть RLS — давайте куда-нить приткнем, отличная логика.
    Если пользоваться принципом KISS и YAGNI, то надобность в RLS возникает очень редко.

    Кстати, как у тебя решается вопрос с павами доступа при таком требовании "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера"?
    Re[30]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.04.09 03:58
    Оценка:
    Здравствуйте, adontz, Вы писали:


    A>Это очень просто. Пусть есть 4 сущности: A, B, C, D. Пусть они ссылаются друг на друга следующим образом A->B, A->C, D->A, D->B. Одним из указанных мною подмножеств будет (A, B, C). Хотя D и ссылается на сущности A и B, важно что A, B и C не ссылаются на D. Теперь, если добавить сущность E и ссылки E->A, E->C, то на (A, B, C) это никак не отразится и (A, B, C) останется ссылочно-целостным подмножеством сущностей.

    А если добавить сущность E и ссылку A->E?

    S>>1. Этих записей значительно, на порядки, меньше общего количества записей.


    A>Теоретически для всех возможных задач такого доказать, конечно же, нельзя. А вот исходя из практики, моего опыта, да, так и есть.

    Ок, поехали дальше.
    S>>2. Обеспечение актуальности кэша именно этих записей обеспечивает ссылочную целостность всей БД

    A>Обеспечение ссылочной целостности этого кеша обеспечивает корреткность операций.

    Ты не юли, ты доказывай. Мне вот, к примеру, очевидно, что в твоей системе за нефиг делать можно нарушить ссылочную целостность "большой" базы.
    A>Не допустимость, а корректность.
    Определение корректности в студию.
    A>Для большинства операций нет необходимости иметь последние, потому что для большинства операций необходимые данные в кеше не меняются. Как часто, например, меняется список филиалов, клиентов, товаров? Так ли необходимо иметь актуальную версию списка при оформлении каждой операции, а следовательно перед каждой операцией проверять обновления?

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

    Ок, и каким образом твой кэш учитывает тот факт, что есть разные требования к актуальности данных? Ты вот приводил "катастрофический" пример про некорректность статистики по городам. Это что, так ужасно — думать, что в Тбилиси 102 клиента, а не 103?

    A>Более того, есть мобильные торговые агенты. Человек берёт в руки покет, изредка ноутбук, и ездит по клиентам. "Ловит" не везде. Заказ, на уже заблокированного клиента может быть успешно сохранён в кеш, а загрузка его в центральную БД, и отказ в оформлении, произойдёт только вечером. Тут тоже нет никакой катастрофы. Если данный кеш ссылочно-целостный, то у меня не самая последняя версия БД, но достаточная для работы. Это значит, что просматривая объекты кеша и переходя по ссылкам мне не потребуется что-то запрашивать с сервера.

    Определение "работы" в студию.


    S>>3. Обеспечение актуальности кэша именно этих записей менее затратно, чем обеспечение актуальности кэша результатов конкретных запросов.

    A>По трафику и количеству запросов, без сомнения.
    Доказательство в студию.

    A>А вот актуальность я не обещал. Без push со стороны сервера это не реально.

    Всё реально. Главное — понять, что такое "актуальность".
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[36]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.04.09 03:58
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Я в последний раз пытаюсь до тебя донести элементарную истину. Row level security решает задачи доступа не требующие анализа объектов. Это настолько часто встречающаяся задача, что её крайне выгодно выделить в отдельную универсальную подсистему. Есть задачи которые в RLS не укладываются и их надо решать отдельно, но это не значит что универсальная система RLS перестала быть выгодной или раздавать права на объекты стало ошибкой.
    Рома, ты бы сам почитал про историю пермиссий. Тебя не удивляет то, что в DACL NTFS есть черты предикатной системы, к примеру пермиссии на CREATOR_OWNER? Или, к примеру, что применили наследование DACL? Это как раз потому, что система RLS перестала быть выгодной.
    В большинстве промышленных инсталляций серъёзных продуктов никто не заморачивается fine-grained security control. Вместо этого разрабатывается конкретная схема, т.е. как раз правила раздачи прав. И делается автоматика, которая наруливает эти права ровно одним, утверждённым образом. Делаются скрипты, которые "чинят" DACLы после вмешательств админов "в связи с ограблением кассы в Телави". Задачи-то все укладываются, RLS позволяет нарулить всё, что угодно. Вот только стоимость администрирования начинает в интересных случаях превышать разумные пределы.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[36]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 21.04.09 05:04
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    IT>>Смотрел, мне семантика == тоже не нравится по тем же причинам — перекладывание большинства проверок на рантайм.
    S>Каких проверок?

    В варианте

    ...Update(p => new Person { ID = 1, FirstName = "Tester", LastName = "Testerson" })

    нечего лишнего не напишешь. Компилятор всё проверит и далее прямая трансляция в SQL в самом лучшем виде. Единственный косяк, который может быть, это вместо класса Person анонимный тип или ещё какая неуставная хрень.

    Любой другой вариант либо дополнительная писанина, либо проверяется только в рантайм, либо и то и другое.

    ...Update(o => o.SetDelayed(true).SetDiscount(o.discount + Consts.DelayDiscountRate)

    Здесь нужно писать дополнительные неочевидные методы. Нафиг такое счастье?

    ...Update(c, d => d.City == originalCity, d => d.ComputedColumn);

    Здесь можно такого понаписать, что потом будешь долго соображать почему у тебя в рантайме выкидыши.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[37]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.04.09 05:23
    Оценка:
    Здравствуйте, IT, Вы писали:


    IT>
    IT>...Update(p => new Person { ID = 1, FirstName = "Tester", LastName = "Testerson" })
    IT>

    IT>нечего лишнего не напишешь. Компилятор всё проверит и далее прямая трансляция в SQL в самом лучшем виде. Единственный косяк, который может быть, это вместо класса Person анонимный тип или ещё какая неуставная хрень.
    Именно. А теперь приведи мне в этом стиле пример с Delayed и Discount, а то я што-то не проникся способом оставить другие свойства ордера в неизменности.

    IT>Любой другой вариант либо дополнительная писанина, либо проверяется только в рантайм, либо и то и другое.

    IT>
    IT>...Update(o => o.SetDelayed(true).SetDiscount(o.discount + Consts.DelayDiscountRate)
    IT>

    IT>Здесь нужно писать дополнительные неочевидные методы. Нафиг такое счастье?
    Ну, я бы ожидал от взрослого языка или макрогенератора наличия этих методов забесплатно. Чё там, если уж мечтать так мечтать, не так ли?

    IT>
    IT>...Update(c, d => d.City == originalCity, d => d.ComputedColumn);
    IT>

    IT>Здесь можно такого понаписать, что потом будешь долго соображать почему у тебя в рантайме выкидыши.
    Ну, здесь всё действительно похуже.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[31]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 06:03
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>Это очень просто. Пусть есть 4 сущности: A, B, C, D. Пусть они ссылаются друг на друга следующим образом A->B, A->C, D->A, D->B. Одним из указанных мною подмножеств будет (A, B, C). Хотя D и ссылается на сущности A и B, важно что A, B и C не ссылаются на D. Теперь, если добавить сущность E и ссылки E->A, E->C, то на (A, B, C) это никак не отразится и (A, B, C) останется ссылочно-целостным подмножеством сущностей.

    S>А если добавить сущность E и ссылку A->E?

    Тогда подмножество (A, B, C) придётся увеличить как минимум на E.

    S>>>2. Обеспечение актуальности кэша именно этих записей обеспечивает ссылочную целостность всей БД

    A>>Обеспечение ссылочной целостности этого кеша обеспечивает корреткность операций.
    S>Ты не юли, ты доказывай. Мне вот, к примеру, очевидно, что в твоей системе за нефиг делать можно нарушить ссылочную целостность "большой" базы.

    Ну покажи пример

    A>>Не допустимость, а корректность.

    S>Определение корректности в студию.

    Я имел ввиду, что, на стороне клиента можно будет проверить все желаемые условия, в том числе довольно сложные и они правильно посчитаются. Например, правильно рассчитается *ожидаемая* скидка. Конечно можно при желании обновлять кеш, но делать это при каждом запросе необходимости нет никакой.

    Надо заметить, что вне зависимости от подхода, если есть желание работать только с актуальными данными, то придётся помучаться. Можно обновление исходных данных и оформления заказа совершать в транзакции. Впрочем это плохо, потому что данное решение крайне плохо масштабируется. Так же, при операции клиент может передавать версию данных, на основе которых операция оформляется, а сервер отказывать в оформлении, если исходные данные устарели. На практике это очень хорошее решение. Очень хорошее оно в первую очередь потому, что деление данных в программе достаточно хорошо соответствует распределению обязанностей между персоналом. Скажем, клиенты распределены по торговым агентам (одному и тому же клиенту два агента с одинаковым ассортиментом не продают). Как следствие, кеш клиентского ПО торгового агента в штатном режиме работе, фактически, обновлять нет необходимости вообще, так как его меняет только сам торговый агент, совершая продажи. Бывают исключения, например корректировка остатка склада, но их можно обрабатывать обнулением кеша. Из практики, корректировка остатсков происходит раз в неделю, а операций продажи до ста в сутки. Соответственно, кеш себя абсолютно оправдывает.

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

    S>Ок, и каким образом твой кэш учитывает тот факт, что есть разные требования к актуальности данных? Ты вот приводил "катастрофический" пример про некорректность статистики по городам. Это что, так ужасно — думать, что в Тбилиси 102 клиента, а не 103?

    Я показал природу проблемы. Неправильно считаться может всё что угодно. Самый простой пример — скидки, бонусы. При желании можно придумать ещё, у нас же не соревнование в богатстве фантазии.

    A>>Более того, есть мобильные торговые агенты. Человек берёт в руки покет, изредка ноутбук, и ездит по клиентам. "Ловит" не везде. Заказ, на уже заблокированного клиента может быть успешно сохранён в кеш, а загрузка его в центральную БД, и отказ в оформлении, произойдёт только вечером. Тут тоже нет никакой катастрофы. Если данный кеш ссылочно-целостный, то у меня не самая последняя версия БД, но достаточная для работы. Это значит, что просматривая объекты кеша и переходя по ссылкам мне не потребуется что-то запрашивать с сервера.

    S>Определение "работы" в студию.

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

    S>>>3. Обеспечение актуальности кэша именно этих записей менее затратно, чем обеспечение актуальности кэша результатов конкретных запросов.

    A>>По трафику и количеству запросов, без сомнения.
    S>Доказательство в студию.

    Антон, а что тут доказывать? И сам объём данных меньше, потому что нет дублирования, и необходимость в обновлении меньше.

    A>>А вот актуальность я не обещал. Без push со стороны сервера это не реально.

    S>Всё реально. Главное — понять, что такое "актуальность".

    Я думал, ты под актуальностью понимаешь синхронность с версией в центральной БД.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[37]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 06:23
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Рома, ты бы сам почитал про историю пермиссий. Тебя не удивляет то, что в DACL NTFS есть черты предикатной системы, к примеру пермиссии на CREATOR_OWNER? Или, к примеру, что применили наследование DACL? Это как раз потому, что система RLS перестала быть выгодной.


    Учитывая что row level security применили к дереву, опциональное наследование как раз очень органично выглядит.

    CREATOR_OWNER это вообще сделано для совместимости со всякими Юниксами. Есть ещё CREATOR_GROUP, есть "главная" группа у доменных пользователей. Самому Windows права доступа на псевдоним CREATOR_OWNER не нужны, вполне подошёл бы механизм привелегий.

    S>В большинстве промышленных инсталляций серъёзных продуктов никто не заморачивается fine-grained security control. Вместо этого разрабатывается конкретная схема, т.е. как раз правила раздачи прав. И делается автоматика, которая наруливает эти права ровно одним, утверждённым образом. Делаются скрипты, которые "чинят" DACLы после вмешательств админов "в связи с ограблением кассы в Телави". Задачи-то все укладываются, RLS позволяет нарулить всё, что угодно. Вот только стоимость администрирования начинает в интересных случаях превышать разумные пределы.


    Ой, да ладно. Вот так всё плохо и никто не придумал ничего существенно лучше?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[32]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.04.09 06:31
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Тогда подмножество (A, B, C) придётся увеличить как минимум на E.
    Тогда непонятно, зачем вообще обсуждать "добавление не расширяет".

    A>Ну покажи пример

    Очень просто. Вот у тебя были сущности A->B->C<-D.
    Клиент запросил A, ты закачал A->B->C. Теперь клиент удалил C, убрав в B ccылку. Всё в порядке — у него ссылок на C больше нет, ссылочная целостность не нарушена. При коммите выяснится, что упс — есть еще D, про которого твой клиент ничего не знает.

    A>Я имел ввиду, что, на стороне клиента можно будет проверить все желаемые условия, в том числе довольно сложные и они правильно посчитаются. Например, правильно рассчитается *ожидаемая* скидка. Конечно можно при желании обновлять кеш, но делать это при каждом запросе необходимости нет никакой.

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

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


    A>Можно обновление исходных данных и оформления заказа совершать в транзакции. Впрочем это плохо, потому что данное решение крайне плохо масштабируется. Так же, при операции клиент может передавать версию данных, на основе которых операция оформляется, а сервер отказывать в оформлении, если исходные данные устарели. На практике это очень хорошее решение. Очень хорошее оно в первую очередь потому, что деление данных в программе достаточно хорошо соответствует распределению обязанностей между персоналом. Скажем, клиенты распределены по торговым агентам (одному и тому же клиенту два агента с одинаковым ассортиментом не продают). Как следствие, кеш клиентского ПО торгового агента в штатном режиме работе, фактически, обновлять нет необходимости вообще, так как его меняет только сам торговый агент, совершая продажи. Бывают исключения, например корректировка остатка склада, но их можно обрабатывать обнулением кеша. Из практики, корректировка остатсков происходит раз в неделю, а операций продажи до ста в сутки. Соответственно, кеш себя абсолютно оправдывает.

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


    A>Я показал природу проблемы. Неправильно считаться может всё что угодно. Самый простой пример — скидки, бонусы. При желании можно придумать ещё, у нас же не соревнование в богатстве фантазии.

    Нет, у нас точная наука. Пока что ты оперируешь соображениями уровня "палец к носу". Ни понятия корректности, ни допустимости ты определить не хочешь. Никаких внятных утверждений доказывать не собираешься. И даже пример проблемы привести не можешь. О чём мы вообще говорим?

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

    Угу. Твой кэш заточен на то, чтобы ровно эти операции не требовали обращения к серверу, так?


    A>Антон, а что тут доказывать? И сам объём данных меньше, потому что нет дублирования, и необходимость в обновлении меньше.

    Здрасте, приехали. С чего объем данных-то меньше? В твоём примере было про A->B->C, и про D->E. Неужели же это будет меньше, чем только A и D? Ну давай, докажи.

    A>Я думал, ты под актуальностью понимаешь синхронность с версией в центральной БД.

    Это без транзакционности, естественно, невозможно гарантировать вообще никак.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[38]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.04.09 06:48
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Учитывая что row level security применили к дереву, опциональное наследование как раз очень органично выглядит.
    Совершенно верно, Рома, выглядит. Я надеюсь, ты в курсе, что появилось оно не сразу?

    A>CREATOR_OWNER это вообще сделано для совместимости со всякими Юниксами.


    Нет, Рома, это сделано из соображений уменьшения затрат на администрирование. Чтобы пользователи могли хоть как-то совместно пользоваться фолдерами без постоянного вмешательства админа.
    A> Есть ещё CREATOR_GROUP, есть "главная" группа у доменных пользователей. Самому Windows права доступа на псевдоним CREATOR_OWNER не нужны, вполне подошёл бы механизм привелегий.
    Ага. Ну расскажи мне, как при помощи механизма привилегий дать людям возможность создавать новые документы в некоторой папке, но при этом по умолчанию не иметь возможности править документы друг друга.

    A>Ой, да ладно. Вот так всё плохо и никто не придумал ничего существенно лучше?

    Придумал. Тебе про это как раз рассказывают. А ты упираешься.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[33]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 06:53
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>Ну покажи пример

    S>Очень просто. Вот у тебя были сущности A->B->C<-D.
    S>Клиент запросил A, ты закачал A->B->C. Теперь клиент удалил C, убрав в B ccылку. Всё в порядке — у него ссылок на C больше нет, ссылочная целостность не нарушена. При коммите выяснится, что упс — есть еще D, про которого твой клиент ничего не знает.

    Такая проблема не специфична для моего подхода. В твоём случае D (или только ссылку D->C) могли создать после запроса и твои Linq-образные запросы не помогли бы. Тут, и вообще по жизни, правильно вообще ничего из базы не удалять, а только помечать флажками: удалено, старая версия, и т.д.

    A>>Я имел ввиду, что, на стороне клиента можно будет проверить все желаемые условия, в том числе довольно сложные и они правильно посчитаются. Например, правильно рассчитается *ожидаемая* скидка. Конечно можно при желании обновлять кеш, но делать это при каждом запросе необходимости нет никакой.

    S>Не очень понятно, что такое "правильно". Если объект, на основе которого скидка рассчитывается, изменился, то ничего правильного не получится.

    Правильно в том смысле что в какой момент времени это было правильно.

    A>>Можно обновление исходных данных и оформления заказа совершать в транзакции. Впрочем это плохо, потому что данное решение крайне плохо масштабируется. Так же, при операции клиент может передавать версию данных, на основе которых операция оформляется, а сервер отказывать в оформлении, если исходные данные устарели. На практике это очень хорошее решение. Очень хорошее оно в первую очередь потому, что деление данных в программе достаточно хорошо соответствует распределению обязанностей между персоналом. Скажем, клиенты распределены по торговым агентам (одному и тому же клиенту два агента с одинаковым ассортиментом не продают). Как следствие, кеш клиентского ПО торгового агента в штатном режиме работе, фактически, обновлять нет необходимости вообще, так как его меняет только сам торговый агент, совершая продажи. Бывают исключения, например корректировка остатка склада, но их можно обрабатывать обнулением кеша. Из практики, корректировка остатсков происходит раз в неделю, а операций продажи до ста в сутки. Соответственно, кеш себя абсолютно оправдывает.

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

    Формального строго доказательства экономии трафика у меня нет, по моему я этого и не скрывал и никогда не представлял экономию трафика как главное благо. Что касается архитектуры вообще, то мы может обсуждать негативные моменты и их последствия. Если мы будем давать субъективную разную оценку серьёзности негативных последствий то к общему мнению не придём, что и наблюдается.

    A>>Я показал природу проблемы. Неправильно считаться может всё что угодно. Самый простой пример — скидки, бонусы. При желании можно придумать ещё, у нас же не соревнование в богатстве фантазии.

    S>Нет, у нас точная наука.

    Если бы у нас была точная наука, мы бы с тобой не спорили.

    S>Ни понятия корректности, ни допустимости ты определить не хочешь. Никаких внятных утверждений доказывать не собираешься. И даже пример проблемы привести не можешь. О чём мы вообще говорим?


    Антон, я не вкладываю в слова корректность и допустимость какой-то особый смысл. Воспользуйся толковым словарём Ожегова.

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

    S>Угу. Твой кэш заточен на то, чтобы ровно эти операции не требовали обращения к серверу, так?

    Кеш заточен на предоставление минимально необходимого ссылочно-целостного подмножества БД. Что входит в необходимые данные, конечно же, определяется операциями над этими данными.

    A>>Антон, а что тут доказывать? И сам объём данных меньше, потому что нет дублирования, и необходимость в обновлении меньше.

    S>Здрасте, приехали. С чего объем данных-то меньше? В твоём примере было про A->B->C, и про D->E. Неужели же это будет меньше, чем только A и D? Ну давай, докажи.

    А ты отвлекись от одной операции. Для одной операции тебе надо A и D, для другой B, C, D, для третьей A и B. Если кешировать результаты запросов, дублирование будет обязательно.

    A>>Я думал, ты под актуальностью понимаешь синхронность с версией в центральной БД.

    S>Это без транзакционности, естественно, невозможно гарантировать вообще никак.

    Было бы здорово если бы ты ещё объяснил что всё это время подразумевал под актуальностью.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[39]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 07:04
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>CREATOR_OWNER это вообще сделано для совместимости со всякими Юниксами.

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

    Антон, объясни мне пожалуйста в чём принципиальная разница между заданием пользователя Sinclair как CREATOR_OWNER файла и заданием Full Access для CREATOR_OWNER и заданием Full Access для Sinclair?

    A>> Есть ещё CREATOR_GROUP, есть "главная" группа у доменных пользователей. Самому Windows права доступа на псевдоним CREATOR_OWNER не нужны, вполне подошёл бы механизм привелегий.

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

    По уму надо делать hook script, CREATOR_OWNER в данном случае это кривое решение частного случая. Таких костылей можно делать ещё кучу, на разные потребности. Смысла в них нет никакого, по той простой причине, что дать пользователю персональную папку проще и правильнее.

    A>>Ой, да ладно. Вот так всё плохо и никто не придумал ничего существенно лучше?

    S>Придумал. Тебе про это как раз рассказывают. А ты упираешься.

    Что-то ваша реализация пока нигде себя не оправдала.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[34]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 07:11
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Ну покажи пример

    S>>Очень просто. Вот у тебя были сущности A->B->C<-D.
    S>>Клиент запросил A, ты закачал A->B->C. Теперь клиент удалил C, убрав в B ccылку. Всё в порядке — у него ссылок на C больше нет, ссылочная целостность не нарушена. При коммите выяснится, что упс — есть еще D, про которого твой клиент ничего не знает.

    A>Такая проблема не специфична для моего подхода. В твоём случае D (или только ссылку D->C) могли создать после запроса и твои Linq-образные запросы не помогли бы. Тут, и вообще по жизни, правильно вообще ничего из базы не удалять, а только помечать флажками: удалено, старая версия, и т.д.

    Не надо никаких флажков. Достаточно не делать операция вставки\удаления в отсоединенный набор данных.

    A>>>Я имел ввиду, что, на стороне клиента можно будет проверить все желаемые условия, в том числе довольно сложные и они правильно посчитаются. Например, правильно рассчитается *ожидаемая* скидка. Конечно можно при желании обновлять кеш, но делать это при каждом запросе необходимости нет никакой.

    S>>Не очень понятно, что такое "правильно". Если объект, на основе которого скидка рассчитывается, изменился, то ничего правильного не получится.
    A>Правильно в том смысле что в какой момент времени это было правильно.
    Когда? Год назад?
    Рассчеты скидок должны быть правильными "сейчас".

    A>>>Я показал природу проблемы. Неправильно считаться может всё что угодно. Самый простой пример — скидки, бонусы. При желании можно придумать ещё, у нас же не соревнование в богатстве фантазии.

    S>>Нет, у нас точная наука.
    A>Если бы у нас была точная наука, мы бы с тобой не спорили.
    Наука у нас точная, а вот точных методов анализа и доказательств не хватает.
    Re[40]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.04.09 07:14
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Антон, объясни мне пожалуйста в чём принципиальная разница между заданием пользователя Sinclair как CREATOR_OWNER файла и заданием Full Access для CREATOR_OWNER и заданием Full Access для Sinclair?
    В том, что первое работает автоматически, а второе должен выполнить админ для каждого файла.

    A>По уму надо делать hook script,

    о-о-о, начинается. Вот она — великая мощь RLS. Нужен хук скрипт. Цитирую одного человека по поводу этого:

    Это код и это не гибко.


    A> CREATOR_OWNER в данном случае это кривое решение частного случая. Таких костылей можно делать ещё кучу, на разные потребности. Смысла в них нет никакого, по той простой причине, что дать пользователю персональную папку проще и правильнее.

    Да-да. То-то я смотрю это бессмысленное решение применяется в 100% инсталляций. Добро пожаловать в реальный мир.

    A>Что-то ваша реализация пока нигде себя не оправдала.

    Твоя пока тоже
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[33]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 07:54
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Для автоматизации коллективной работы (любые CRM, ERP, систкемы документооборота) такая схема не подойдет. Там в большенстве процессов участвует много людей (менеджеры, кураторы, исполнители), с пересекающимися обязанностями, а самое главное они работают с одними и теми же данными (клиентами, договорами).


    Напротив, если бы вместе работала большая группа людей, она была бы неуправляема. Тип данных может быть одинаковый, а вот секционирование всё равно выходит. В CRM конкретные люди решают разные типы проблем или работают с небольшим количеством клиентов, в документообороте конкретные люди оформляют разные типы документов.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[35]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 07:57
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Не надо никаких флажков. Достаточно не делать операция вставки\удаления в отсоединенный набор данных.


    Да, я помню что ты любишь удалять из БД

    A>>Правильно в том смысле что в какой момент времени это было правильно.

    G>Когда? Год назад?

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

    G>Рассчеты скидок должны быть правильными "сейчас".


    Это можно сделать только на сервере.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[41]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 08:04
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>По уму надо делать hook script,

    S>о-о-о, начинается. Вот она — великая мощь RLS. Нужен хук скрипт. Цитирую одного человека по поводу этого:
    S>

    Это код и это не гибко.


    Если ты хочешь что-то особенное, это всегда негибкий код. Вопрос не в том, как не писать его вовсе, это утопия. Вопрос в том, как решение 99% задач сделать data driven.

    A>> CREATOR_OWNER в данном случае это кривое решение частного случая. Таких костылей можно делать ещё кучу, на разные потребности. Смысла в них нет никакого, по той простой причине, что дать пользователю персональную папку проще и правильнее.

    S>Да-да. То-то я смотрю это бессмысленное решение применяется в 100% инсталляций. Добро пожаловать в реальный мир.

    Антон, ты живёшь в альтернативной реальности. Во всех (не моих!) инсталляциях которые я видел пользователям делают личные папочки на сервере, на которые редиректится My Documents, Desktop и т.д., а CREATOR_OWNER вообще не используется. Обмен документами происходит либо через почту/мессенджер, либо черех спецпапку Inbox в которой у чужаков только право CREATE. Надо перетащить файл поверх папки и он запишется внутрь, зайти нельзя.

    A>>Что-то ваша реализация пока нигде себя не оправдала.

    S>Твоя пока тоже

    Ну да, до вас прав доступа вообще не было.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[34]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 08:18
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Для автоматизации коллективной работы (любые CRM, ERP, систкемы документооборота) такая схема не подойдет. Там в большенстве процессов участвует много людей (менеджеры, кураторы, исполнители), с пересекающимися обязанностями, а самое главное они работают с одними и теми же данными (клиентами, договорами).


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


    Тебе так хочется в это верить?
    Но так не выходит. Весь прикол в том что в CRM можество людей отвечают за работу с одним клиентом, так же как в документоообороте множество людей работают с одним документом.
    Попытка внедрить туда раздеоление данных только усложняет работу.

    Ты видимо как раз занимаешься торгово-закупочтым софтом для малых огранизаций, поэтому думаешь что именно так везде работает.
    Я, к счастью, успел поучаствовать в разработке разного софта.
    Re[36]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 08:24
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>>>Правильно в том смысле что в какой момент времени это было правильно.

    G>>Когда? Год назад?
    A>Недавно, иначе кеш не имеет смысла. Причём настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора.
    Ну, конкретнее, сколько времени оценка будет правильной?
    Что делать если в один прекрасный момент появится необходимость это время увеличить в 2 раза?

    G>>Рассчеты скидок должны быть правильными "сейчас".

    A>Это можно сделать только на сервере.
    Тогда зачем что-то делать на клиенте, если корректный результат возможен только при вычислении на сервере?
    Ведь все эти кеши, запреты удаления, прочая муть только от того что хочется что-то безопасно делать на клиенте.

    Или можно просто откзаться от идеи безопасности операций на клиенте, а сразу предполагать что любая операция на клиенте может происходить на уже недействительных данных.
    Re[42]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 08:28
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>По уму надо делать hook script,

    S>>о-о-о, начинается. Вот она — великая мощь RLS. Нужен хук скрипт. Цитирую одного человека по поводу этого:
    S>>

    Это код и это не гибко.


    A>Если ты хочешь что-то особенное, это всегда негибкий код. Вопрос не в том, как не писать его вовсе, это утопия. Вопрос в том, как решение 99% задач сделать data driven.


    Вопрос в том как сделать максимум кода декларативным, а не то что ты написал.
    Re[35]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 08:38
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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


    G>Тебе так хочется в это верить?

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

    gandjustas, если ты себе не представляешь как выделять данные в кеш, то так и скажи. Дистрибуцию я приводил как общепонятный контекст, уж точно я не только этим занимался. Твой пафос неуместен.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[42]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 21.04.09 08:42
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Если ты хочешь что-то особенное, это всегда негибкий код. Вопрос не в том, как не писать его вовсе, это утопия. Вопрос в том, как решение 99% задач сделать data driven.

    Совершенно верно. И data-driven — это не отдельный DACL, а безопасность, построенная на предикатах. Где нет страха, что хук скрипт не отработал, и при смене правил нет необходимости бегать по всем объектам и проверять их DACL.

    A>>> CREATOR_OWNER в данном случае это кривое решение частного случая. Таких костылей можно делать ещё кучу, на разные потребности. Смысла в них нет никакого, по той простой причине, что дать пользователю персональную папку проще и правильнее.

    S>>Да-да. То-то я смотрю это бессмысленное решение применяется в 100% инсталляций. Добро пожаловать в реальный мир.

    A>Антон, ты живёшь в альтернативной реальности. Во всех (не моих!) инсталляциях которые я видел пользователям делают личные папочки на сервере, на которые редиректится My Documents, Desktop и т.д., а CREATOR_OWNER вообще не используется.

    Рома, не тренди.
    Читать здесь. Creator/Owner подчеркнуть, или сам найдешь?
    Посмотри также насчет того, что поменяли в висте на эту тему. Аналогичная фигня — дефолтные DACL подправили так, чтобы соответствовать реальным сценариям.
    A>Ну да, до вас прав доступа вообще не было.
    Головой просто думать надо, головой.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[37]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 08:47
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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

    G>Ну, конкретнее, сколько времени оценка будет правильной?

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

    G>Что делать если в один прекрасный момент появится необходимость это время увеличить в 2 раза?


    А в чём проблема-то? Кеш обновляется не по таймеру.

    A>>Это можно сделать только на сервере.

    G>Тогда зачем что-то делать на клиенте, если корректный результат возможен только при вычислении на сервере?
    G>Ведь все эти кеши, запреты удаления, прочая муть только от того что хочется что-то безопасно делать на клиенте.

    Нет. Запрет удаления с кешем совсем не связан. Ты ничего не понял и решил свалить всё в кучу. В Active Directory, например, объекты удаляются в распределённой системе. И ничего, всё работает. Запрет удаления это не ограничение вызванное использованием кеша, это совершенно отдельная песня.

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

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


    Не любая, потому что не все данные можно редактировать, но некоторые могут. И, кстати, часто возможность продолжить работу важнее, чем возможность продолжить её корректно. Например, если филиал магазина с двухтысячным ассортиментом отрубился от сети, а в центре обновили цены на три товара, лучше продолжить продавать по старым ценам, а не закрывать филиал.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[32]: Проблемы организации OR-мапинга
    От: IB Австрия http://rsdn.ru
    Дата: 21.04.09 09:52
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S> Правда, меня пока что забанили в том списке — на выходных лежала даже гуглопочта нашего сайта, за что меня и тово, лишили доступа к телу.

    Та же фигня. Попросил Лизу переключить меня на другой мэйл, но пока молчит...

    S>Не думаю, что его слова там как-то особенно непонятны.

    Собственно Меер в той команде уже лет несколько, так что...

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

    +1

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

    Проблема в том, что в этой версии они категорически хотят менять компилятор по минимуму и основные изменения будут в C# 5. В плоть до того, что выкидываются вещи, которые еще полгода назад обещались обязательно реализовать.

    S>Ну, там пока в основном другие MVP отжигают; народ из команды как-то так, значительно менее активен. Но я попробую.

    Да, отжигают они там неподецки, от некоторых идей в дрож бросает.. ))
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
    Мы уже победили, просто это еще не так заметно...
    Re[43]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 11:56
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Читать здесь. Creator/Owner подчеркнуть, или сам найдешь?

    S>Посмотри также насчет того, что поменяли в висте на эту тему. Аналогичная фигня — дефолтные DACL подправили так, чтобы соответствовать реальным сценариям.

    Из твоих ссылок следует, что в Висте перестали использовать CREATOR_OWNER. Это, по-твоему, подтверждает твои слова?

    A>>Ну да, до вас прав доступа вообще не было.

    S>Головой просто думать надо, головой.

    Трудно не согласится.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[37]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 11:57
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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


    Это, как минимум, приводит к хорошему повторному использованию кода между клиентом и сервером.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[39]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 12:00
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Я уже написал, ты не удосужился прочесть. "настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора".

    G>Критерий полезности в студию. Работа с деньгами в программе должна быть точной, иначе проблема может быть очень много.

    Критерий полезности зависит от конкретной задачи, так что не надо заниматься демагогией.

    G>>>Что делать если в один прекрасный момент появится необходимость это время увеличить в 2 раза?

    A>>А в чём проблема-то? Кеш обновляется не по таймеру.
    G>И как же он обновляется? Вытягиванием changeset с сервера при каждом обращении?

    Не при каждом, в том то и суть. когда, зависит от задачи. Можно по запросу пользователя, можно при указании со стороны сервера на передачу устаревших данных.

    G>Ну и чем же запрет удаления вызван?


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

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

    G>Угу, опять сведение к разделению данных между пользователями.

    Нет, в данном случае разделение не при чём. Дело в реальных потребностях бизнеса. От того что что-то не обновилось нельзя всё останавливать.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[38]: Nemerle & Real Life
    От: mrTwister Россия  
    Дата: 21.04.09 13:10
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Не считаю нужным тратить время на неадекватных собеседников. За сим прощаюсь.


    А, то есть по-этому ты и не читаешь сообщения "неадекватных собеседников"?
    лэт ми спик фром май харт
    Re[40]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 15:17
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Я уже написал, ты не удосужился прочесть. "настолько недавно, чтобы оценки на основе сохранённых данных были полезными для оператора".

    G>>Критерий полезности в студию. Работа с деньгами в программе должна быть точной, иначе проблема может быть очень много.
    A>Критерий полезности зависит от конкретной задачи, так что не надо заниматься демагогией.
    Так это ты демагогию разводишь. Есть конкретная ситуация со скидками, ты можешь сказать как будет осщуствляться кеширование в таком случае? Конкретно время и условия устаревания, способ обновления кеша.

    G>>>>Что делать если в один прекрасный момент появится необходимость это время увеличить в 2 раза?

    A>>>А в чём проблема-то? Кеш обновляется не по таймеру.
    G>>И как же он обновляется? Вытягиванием changeset с сервера при каждом обращении?
    A>Не при каждом, в том то и суть. когда, зависит от задачи. Можно по запросу пользователя, можно при указании со стороны сервера на передачу устаревших данных.
    Ну по запросу пользователя — это понятнно, зачасту такой подход гораздо менее эффективен, чем передача только нужных данных по запросу пользователя.
    А вот насчет указания сервреа я не понял. Нету ведь постоянной связи с сервером, да и как будет выполняться оповещение?

    G>>Ну и чем же запрет удаления вызван?

    A>Накопленным опытом. Часто, удалённые данные тоже нужны, хотя бы чтобы точно знать что именно удалили.
    Большенство твоего опыта — следствие архитектурных ошибок.

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

    G>>Угу, опять сведение к разделению данных между пользователями.
    A>Нет, в данном случае разделение не при чём. Дело в реальных потребностях бизнеса. От того что что-то не обновилось нельзя всё останавливать.
    Можешь не доказывать, я уже понгял с какими программами ты работаешь. Такой подход применим в очень небольшом количестве случаев.
    Re[28]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 21.04.09 16:22
    Оценка:
    Здравствуйте, 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.
    now playing: Gregor Tresher — Unfold
    Re[26]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 21.04.09 16:50
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>Меня смущает то, что со временем эта куча превращается в помойку, т.к. никакой внятной схемы именования подобных классов мне придумать не удалось.


    А если творчески применить пространства имён?
    now playing: Dusty Kid — Train No 1
    Re[27]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 21.04.09 16:55
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    L>>Меня смущает то, что со временем эта куча превращается в помойку, т.к. никакой внятной схемы именования подобных классов мне придумать не удалось.

    S>Ну, идеально было бы их вообще не именовать.

    И как же их не именовать?

    L>>Был бы аналог удобного глобального вывода типов для анонимных классов, было бы удобно. А так приходится созерцать эти унылые CustomerInfo...

    S>Называй класс по имени View.

    Не получится.
    Например, есть страница Customer. Не ней отображаются не только текущий Customer, но и всякие зависящие от него Location-ы, Department-ы, Person-ы и прочее. Как минимум кроме CustomerInfo придется заводить и *Info для всех остальны сущностей.
    А если учесть, что многие сущности выводятся на более чем одной странице и зачастую выводятся разные поля, то становится совсем весело.


    L>>PE = Presentation Entity


    L>>Удобно, если ID и Name. Но если полей становится больше 2-3-х, то получаем кучу унылого говно-кода.

    S>Откуда взялся говнокод?

    Эти плодящиеся CustomerInfo и есть он.
    Re[27]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 21.04.09 17:46
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    L>>Меня смущает то, что со временем эта куча превращается в помойку, т.к. никакой внятной схемы именования подобных классов мне придумать не удалось.


    EC>А если творчески применить пространства имён?


    Тогда будет помойка, размазанная по пространствам имен.
    Re[28]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 21.04.09 18:36
    Оценка:
    Здравствуйте, 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 уменьшается.
    Re[29]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 21.04.09 20:00
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    L>>>>Был бы аналог удобного глобального вывода типов для анонимных классов, было бы удобно. А так приходится созерцать эти унылые CustomerInfo...

    S>>>Называй класс по имени View.

    L>>Не получится.

    G>Неправльно формируешь PE.

    Конечно, неправильно, раз помойка получается.

    L>>Например, есть страница Customer. Не ней отображаются не только текущий Customer, но и всякие зависящие от него Location-ы, Department-ы, Person-ы и прочее. Как минимум кроме CustomerInfo придется заводить и *Info для всех остальны сущностей.

    L>>А если учесть, что многие сущности выводятся на более чем одной странице и зачастую выводятся разные поля, то становится совсем весело.
    G>Presentation Entity надо формировать не на основе сущностей, а на основе отображаемых полей. Часто оказывается что набор полей при отображении разных сущностей семантически совпадает.

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

    На странице 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 уменьшается.


    Из-за чего?
    Re[41]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 21.04.09 21:04
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Так это ты демагогию разводишь. Есть конкретная ситуация со скидками, ты можешь сказать как будет осщуствляться кеширование в таком случае? Конкретно время и условия устаревания, способ обновления кеша.


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

    G>А вот насчет указания сервеа я не понял. Нету ведь постоянной связи с сервером, да и как будет выполняться оповещение?


    При синхронизации. Например взял заказ на 50 банок, на складе реально 48 (2 списали как разбитые), при синхронизации попросят заказ скорерктировать, так как остатки склада устарели.

    A>>Накопленным опытом. Часто, удалённые данные тоже нужны, хотя бы чтобы точно знать что именно удалили.

    G>Большенство твоего опыта — следствие архитектурных ошибок.

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

    A>>Нет, в данном случае разделение не при чём. Дело в реальных потребностях бизнеса. От того что что-то не обновилось нельзя всё останавливать.

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

    Я в своих рассуждениях ссылался минимум на 4 типа программ для систем с весьма разными бизнес-процессами, но ты видимо слишком неопытен чтобы это понять.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[30]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 22.04.09 02:35
    Оценка:
    Здравствуйте, Lloyd, Вы писали:


    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 используются непосредственно сущности БД.
    Re[29]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 22.04.09 03:49
    Оценка:
    Здравствуйте, 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>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[35]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 22.04.09 03:49
    Оценка:
    Здравствуйте, 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>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[39]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 22.04.09 04:07
    Оценка:
    Здравствуйте, 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 случаев.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[28]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 22.04.09 04:07
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>Не получится.

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

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

    Не вижу особенного веселья.

    L>Эти плодящиеся CustomerInfo и есть он.

    Конкретнее. Много места занимает декларация класса с автопропертями?
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[30]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 22.04.09 04:07
    Оценка:
    Здравствуйте, 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).

    И всё это — на одной странице? Покажи скриншот.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[43]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 22.04.09 04:11
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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

    G>Можешь ссылаться хоть на 8 типов. Все равно они все сводятся к одному сценарию. А те которые не сводятся ты искусственно пытаешься свести к такому сценарию.

    Вот это и есть твоя неопытность Для тебя вся торговля это ларёк, хотя только дисрибьюторы могут работать по трём кранйе различным схемам. А ещё есть магазины, сети магазинов, рестораны, гостиницы...
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[44]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 22.04.09 04:17
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

    G>>Можешь ссылаться хоть на 8 типов. Все равно они все сводятся к одному сценарию. А те которые не сводятся ты искусственно пытаешься свести к такому сценарию.

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

    Вау, круто.
    А есть еще интернет-магазины, как для них твое кешрование работать будет?
    Как там будет определяться адкеватное время устаревани кеша?
    Re[44]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 22.04.09 04:42
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

    G>>Можешь ссылаться хоть на 8 типов. Все равно они все сводятся к одному сценарию. А те которые не сводятся ты искусственно пытаешься свести к такому сценарию.

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


    Кстати. В каком из вариантов толстый клиент с удаленным сервреом при нестабиьном канале?
    В ресторахнах, гостиница, магазинах связь с сервером есть всегда (lan, wifi), там рулят тонкие клиенты.
    Re[40]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 22.04.09 05:38
    Оценка:
    Здравствуйте, 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 он мало интересует.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[46]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 22.04.09 09:44
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

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

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


    Словами не кидайся. Высказывай свою точку зрения.
    Re[36]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 22.04.09 13:24
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

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

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

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

    S>Наверное, классы?

    Да, конечно.

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

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

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

    VD>>Ну, дык и гнат его из MVP.

    S>Тогда много кого гнать придется.

    Ну, дык не проблема. Остальные будут больше ценить данное им звание, и будут суетиться.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[47]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 22.04.09 13:55
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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

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

    Моя точка зрения — ты неопытный
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[48]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 22.04.09 14:15
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

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

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

    Ну не надо сливать так откровенно.

    Может хоть одно доказательство своих слов в этой теме приведешь? А то все "может быть", "в некоторых случаях", "моя точка зрения".
    Re[49]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 22.04.09 14:50
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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

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

    Дистрибьюторы:
  • Клиент присылает заказ в виде файла в экселе.
    Постоянная связь с сервером, тонкий клиент.
  • Торговый агент берёт заказ, служба доставки обрабатывает его позднее.
    Периодическая связь с сервером, толстый клиент, односторонняя синхронизация.
  • Торговый агент продаёт товар из машины.
    Периодическая связь с сервером, толстый клиент, двусторонняя синхронизация.

    Магазины/Рестораны/Гостиницы:
  • Один.
    Постоянная связь с сервером, тонкий клиент.
  • Сеть.
    Периодическая связь с сервером, толстый клиент, двусторонняя синхронизация.

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

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

    В общем понятно, что большой бизнес (распределённые географически сети) это всегда периодическая связь с сервером, потому что такова жизнь, толстый клиент и реплика БД, так как надо полноценно работать в офлайне.
  • A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[31]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 22.04.09 15:04
    Оценка:
    Здравствуйте, 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_ов сделал бы одну структуру отображения

    Какую?
    Re[29]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 22.04.09 15:07
    Оценка:
    Здравствуйте, 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>Конкретнее. Много места занимает декларация класса с автопропертями?
    Проблема не в том, что они занимают место, а в том, что их становится много.
    Re[31]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 22.04.09 15:08
    Оценка:
    Здравствуйте, 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>И всё это — на одной странице? Покажи скриншот.

    Да, на одной. Но скриншот не покажу.
    Re[50]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 22.04.09 15:19
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

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

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

    Это что за зверь такой?

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

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

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


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

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

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

    Бред, в "большом бизнесе" интернет есть в кажом офисе.
  • Re[51]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 22.04.09 15:35
    Оценка:
    Здравствуйте, 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>Бред, в "большом бизнесе" интернет есть в кажом офисе.

    Большой бизнес делается не только в офисе, это раз, и не может полагаться на работоспособность интернета, это два.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[52]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 22.04.09 18:26
    Оценка:
    Здравствуйте, 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>Большой бизнес делается не только в офисе, это раз, и не может полагаться на работоспособность интернета, это два.
    А где же еще делается "большой бизнес" ? И почему не может полагаться на работоспособность инета?
    Интернет — самая надежная сеть на сегодняшний момент.
    Re[30]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 23.04.09 04:00
    Оценка:
    Здравствуйте, Lloyd, Вы писали:
    L>А можно подробнее, как у CustomerViewModel будет выглядет свойство Locations? Уж не List<Dictionary<string, object>> ли?
    Скорее всего — Dictionary<Guid, string>. Потому что очень вряд ли на одной странице нужны ОО-детали от Location. Вот когда они понадобятся для конкретного Location, вот тогда и затащишь туда нужный по месту LocationInfo.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[31]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 23.04.09 05:45
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    S>Скорее всего — Dictionary<Guid, string>. Потому что очень вряд ли на одной странице нужны ОО-детали от Location.

    Нужны.
    здесь
    Автор: Lloyd
    Дата: 22.04.09


    S>Вот когда они понадобятся для конкретного Location, вот тогда и затащишь туда нужный по месту LocationInfo.

    Куда "туда"?
    Re[32]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 23.04.09 06:15
    Оценка:
    Здравствуйте, Lloyd, Вы писали:
    L>Нужны.
    L>здесь
    Автор: Lloyd
    Дата: 22.04.09

    Мне сложно принять такое на веру. Это какой-то super-busy UI получается. Вон, ты даже скриншот его не можешь прислать.
    S>>Вот когда они понадобятся для конкретного Location, вот тогда и затащишь туда нужный по месту LocationInfo.
    L>Куда "туда"?
    Туда — это в тот UI, в котором они потребовались.
    Ну вот, к примеру, в гуглопочте довольно-таки нагруженный UI. Тем не менее, он почти весь построен на списках строк с идентификаторами. Всё остальное отображается в отдельных View, которые отдельно проектируются. Тут как-бы довольно странно жаловаться на то, что тебе в одном месте нужно описать, какие именно компоненты Location тебе нужны в LocationHintInfo.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[33]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 23.04.09 06:39
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    L>>Нужны.

    L>>здесь
    Автор: Lloyd
    Дата: 22.04.09

    S>Мне сложно принять такое на веру. Это какой-то super-busy UI получается.

    Не, получается совершено обычный UI для учетных систем. Они все на одно лицо.

    S>Вон, ты даже скриншот его не можешь прислать.


    Открой какой-нить 1С, да посмотри. Куда поще-то?

    S>>>Вот когда они понадобятся для конкретного Location, вот тогда и затащишь туда нужный по месту LocationInfo.

    L>>Куда "туда"?
    S>Туда — это в тот UI, в котором они потребовались.

    Что значит "затащить LocationInfo в UI"?

    S>Ну вот, к примеру, в гуглопочте довольно-таки нагруженный UI.


    В гугл-почте как раз очень постой UI. Количество сущностей, с которым оно оперирует очень ограничено. Поэтому приводить его в качестве примера не совсем уместно.

    S>Тем не менее, он почти весь построен на списках строк с идентификаторами. Всё остальное отображается в отдельных View, которые отдельно проектируются. Тут как-бы довольно странно жаловаться на то, что тебе в одном месте нужно описать, какие именно компоненты Location тебе нужны в LocationHintInfo.


    А последнее предложение я вообще не понял. Откуда взялся LocationHintInfo?
    Re[34]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 23.04.09 07:02
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

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


    L>>>Нужны.

    L>>>здесь
    Автор: Lloyd
    Дата: 22.04.09

    S>>Мне сложно принять такое на веру. Это какой-то super-busy UI получается.
    L>Не, получается совершено обычный UI для учетных систем. Они все на одно лицо.
    "обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.

    S>>Вон, ты даже скриншот его не можешь прислать.

    L>Открой какой-нить 1С, да посмотри. Куда поще-то?
    1С в данном случае — не тот пример. Система которая умеет потенциально все в 95% случаев имеет перегруженный интрефейс.
    И надо прилагать усислия чтобы его упростить.

    S>>Ну вот, к примеру, в гуглопочте довольно-таки нагруженный UI.

    L>В гугл-почте как раз очень постой UI. Количество сущностей, с которым оно оперирует очень ограничено. Поэтому приводить его в качестве примера не совсем уместно.
    Так хороший UI и должен отображать минимум сущностей и при этом покрывать максимум задач пользователя. Желательно в интуитивно-понятной форме с подсказками.

    Крмое того в веб-приложении октрытие дополнительных окон ничего не стоит, в отличие от десктопа. Этим надо пользоваться.
    Кстати поэтому навигация на постбеках — зло.
    Re[35]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 23.04.09 07:42
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>"обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.


    Как раз в тему: http://habrahabr.ru/blogs/ui_design_and_usability/58023/
    Re[54]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 23.04.09 14:08
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

    G>>Интересно, а как же кешироване в HTTP работает? Причем работает в разы лучше любой схемы с локальной репликой и синхронизацией, которую ты можешь придумать.
    A>Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер.
    И каким образом должно учитываться содержание?

    G>>>>Бред, в "большом бизнесе" интернет есть в кажом офисе.

    A>>>Большой бизнес делается не только в офисе, это раз, и не может полагаться на работоспособность интернета, это два.
    G>>А где же еще делается "большой бизнес"?
    A>Вне офиса
    Ну где? Конкретнее.

    G>>И почему не может полагаться на работоспособность инета?

    A>А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня.
    Ну время даунтайма пару часов в месяц — мелочи. Бывает и свет на большее время отключают.
    Кроме того для малых бизнесов подходят интранет решения, без выхода во внешнюю сеть.
    Если нужно взаимодействие между несколькими крупными офисами, то интранет решения в каждом из них могут обмениваться информацией через веб-сервисы и репликацию БД.

    G>>Интернет — самая надежная сеть на сегодняшний момент.

    A>Из общедоступных, как минимум GSM сети надёжнее интернета.
    Мда.. сравнивать средства канального уровня и сетевого конечно круто.
    Re[29]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 23.04.09 17:37
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    EC>>Ты уверен, что имеешь в виду именно динамическую типизацию, а не диспетчеризацию?


    V>А вопрос-то не так прост. Всегда, когда мы делаем динамическое приведение типа, мы имеем диспетчеризацию как минимум на 2 ветки — успешную и неуспешную. А если еще поднятся на шаг выше, то динамическое приведение обычно и используется там, где предполагается некая _группа_ типов, иначе можно обойтись статической типизацией.

    Это всё хорошо, но где при паттерн матчинге происходит динамическое приведение типа?

    V>---------

    V>Согласен, что матчинг помимо подобного динамического определения типа еще умеет и значения матчить.
    Да нет там динамического определения типа. Мы матчимся по значениям одного типа.
    Это тупо свитч на стероидах.
    V>Так же напомню, что шли обсуждения конструкций для C# типа этой:
    V>
    V>switch(obj.GetType()) {
    V>  case typeof(A): ...
    V>  case typeof(B): ...
    V>}
    V>

    V>Но, думается, вместо подобной билеберды введут все-таки матчинг, ибо он более удобен в этих самых задачах, для которых сегодня используется динамическая типизация.
    Я здесь исключительно про ПМ в хаскеле.
    now playing: Alex Under — Las Bicicletas Son Para El Verano (Alex Smoke's Rusty Bike Mix)
    Re[35]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 23.04.09 18:12
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    L>>>>Нужны.

    L>>>>здесь
    Автор: Lloyd
    Дата: 22.04.09

    S>>>Мне сложно принять такое на веру. Это какой-то super-busy UI получается.
    L>>Не, получается совершено обычный UI для учетных систем. Они все на одно лицо.
    G>"обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.

    Где ты увидел сотню полей? По приведенной ссылке их всего несколько. Так что давай, не увиливай, пиши как PE делать.

    S>>>Вон, ты даже скриншот его не можешь прислать.

    L>>Открой какой-нить 1С, да посмотри. Куда поще-то?
    G>1С в данном случае — не тот пример. Система которая умеет потенциально все в 95% случаев имеет перегруженный интрефейс.
    G>И надо прилагать усислия чтобы его упростить.

    PE-то будет?

    S>>>Ну вот, к примеру, в гуглопочте довольно-таки нагруженный UI.

    L>>В гугл-почте как раз очень постой UI. Количество сущностей, с которым оно оперирует очень ограничено. Поэтому приводить его в качестве примера не совсем уместно.
    G>Так хороший UI и должен отображать минимум сущностей и при этом покрывать максимум задач пользователя. Желательно в интуитивно-понятной форме с подсказками.

    В гмейле отображение минимума сущностей объясняется не продуманностью UI, а простотой предметной области и только.

    G>Крмое того в веб-приложении октрытие дополнительных окон ничего не стоит, в отличие от десктопа. Этим надо пользоваться.

    G>Кстати поэтому навигация на постбеках — зло.

    Не уходи от темы. Я все еще жду правильных PE.
    Re[54]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 24.04.09 03:48
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер.
    Что, серъезно? В каком смысле "не учитывает содержание"? В каком смысле "учитывается тип"?
    Кому-то из нас нужно перечитать RFC.

    A>Вне офиса

    Прикольно. Посмотреть бы еще на этот большой бизнес.
    Вот у нас, к примеру, маленький. Вот неполный список офисов: http://www.parallels.com/contact/. Пока что все работает по интернету. Даже телефонов у нас обычных не выдают, стоят IP-Phones. А тем, кто часто бывает вне офиса, рекомендуют использовать скайп.

    A>А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня.


    A>Из общедоступных, как минимум GSM сети надёжнее интернета.

    То есть интернет по GPRS надежнее интернета. Прикольно.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[36]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 24.04.09 03:52
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

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


    L>>>>>Нужны.

    L>>>>>здесь
    Автор: Lloyd
    Дата: 22.04.09

    S>>>>Мне сложно принять такое на веру. Это какой-то super-busy UI получается.
    L>>>Не, получается совершено обычный UI для учетных систем. Они все на одно лицо.
    G>>"обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.

    L>Где ты увидел сотню полей? По приведенной ссылке их всего несколько. Так что давай, не увиливай, пиши как PE делать.

    Я же сказал, что для отображения списков и списков списков сущностей можно придумать общую структуру а не плодить *Info классы.

    S>>>>Вон, ты даже скриншот его не можешь прислать.

    L>>>Открой какой-нить 1С, да посмотри. Куда поще-то?
    G>>1С в данном случае — не тот пример. Система которая умеет потенциально все в 95% случаев имеет перегруженный интрефейс.
    G>>И надо прилагать усислия чтобы его упростить.
    L>PE-то будет?
    В 1с ?

    S>>>>Ну вот, к примеру, в гуглопочте довольно-таки нагруженный UI.

    L>>>В гугл-почте как раз очень постой UI. Количество сущностей, с которым оно оперирует очень ограничено. Поэтому приводить его в качестве примера не совсем уместно.
    G>>Так хороший UI и должен отображать минимум сущностей и при этом покрывать максимум задач пользователя. Желательно в интуитивно-понятной форме с подсказками.
    L>В гмейле отображение минимума сущностей объясняется не продуманностью UI, а простотой предметной области и только.
    Это уже отмазка.
    Без компьютеров люди могут управляться с весьма малым количеством сущностей и их атрибутов.
    В основном все бизнес-операции зависят от некоторого среза (проекции) атрибутов сущности или группы сущностей.
    При этом построители интерфейса счиатют что можно на одной форме вывалить три десятка аотрибутов и заставить пользователя управляться с этим.

    G>>Крмое того в веб-приложении октрытие дополнительных окон ничего не стоит, в отличие от десктопа. Этим надо пользоваться.

    G>>Кстати поэтому навигация на постбеках — зло.
    L>Не уходи от темы. Я все еще жду правильных PE.
    См выше.
    Вообще говоря без кода я вряд ли смогу что-нить адекватое предложить.
    Re[55]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 24.04.09 04:24
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер.

    S>Что, серъезно? В каком смысле "не учитывает содержание"? В каком смысле "учитывается тип"?
    S>Кому-то из нас нужно перечитать RFC.

    RFC тут не при чём. Есть сайт, у его HTMLок (ну или генерируемого активными страницами HTML кода) стандартные заголовок и окончание. Отдельно их кешировать нельзя.

    A>>Вне офиса

    S>Прикольно. Посмотреть бы еще на этот большой бизнес.

    Антон, приводить IT компанию как пример довольно нелепо.

    A>>А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня.

    A>>Из общедоступных, как минимум GSM сети надёжнее интернета.
    S>То есть интернет по GPRS надежнее интернета. Прикольно.
    Нет. Именно GSM надёжнее.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[55]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 24.04.09 04:29
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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

    A>>Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер.
    G>И каким образом должно учитываться содержание?

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

    A>>Вне офиса

    G>Ну где? Конкретнее.

    А что тут не конкретного?

    A>>А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня.

    G>Ну время даунтайма пару часов в месяц — мелочи. Бывает и свет на большее время отключают.

    Есть фирмы для которых пара часов в месяц не мелочь. Вот представь себе что так.

    G>Кроме того для малых бизнесов подходят интранет решения, без выхода во внешнюю сеть.

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

    Для которых нужен интернет или личная оптика.

    A>>Из общедоступных, как минимум GSM сети надёжнее интернета.

    G>Мда.. сравнивать средства канального уровня и сетевого конечно круто.

    Уверен, что GSM сеть это канальный уровень?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[56]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 24.04.09 04:56
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>RFC тут не при чём. Есть сайт, у его HTMLок (ну или генерируемого активными страницами HTML кода) стандартные заголовок и окончание. Отдельно их кешировать нельзя.

    И не нужно. Потому, что в общем случае для HTML эта проблема неразрешима — нет средств выражения "общих частей".
    Зато в частных случаях эта проблема разрешима — достаточно порезать документ на фрагменты, которые можно кэшировать независимо. Эту технику с успехом демонстрируют современные сайты типа pageflakes. Для типичных в приложениях "документов-списков" есть стандартное решение для delta encoding, которое позволяет выполнять частичное обновление с гранулярностью меньше документа.

    Для всех остальных случаев, когда HTTP используется не стандартным браузером, есть стандартизованные способы расширения протокола, которые позволяют всё то, чего ты хочешь.
    A>Антон, приводить IT компанию как пример довольно нелепо.
    А кого надо приводить? Вот есть katren.ru. У них филиальная сеть поширше, чем у нас. Не поверишь — тоже интернет пользуют
    A>Нет. Именно GSM надёжнее.
    Что ты имеешь в виду? Голос по GSM? Рома, это даже не смешно.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[56]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 24.04.09 05:09
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

    A>>>Кеширование в HTTP работает отвратительно, так как никак не учитывает содержание кешируемых объектов. Максимум что учитывается это тип (mime-type) и размер.
    G>>И каким образом должно учитываться содержание?

    A>Например, могли бы кешироваться одинаковые фрагменты страниц, картинок.

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

    A>>>Вне офиса

    G>>Ну где? Конкретнее.
    A>А что тут не конкретного?
    Вне офиса много чего находится. Я вот сильно сомневаюсь что "большой бизнес", с использованием компьютеров (именно такой нас интересует), делается в сортире.
    Так что давай конкретнее.

    A>>>А что, у интернета 100% работоспособность? Во всех регионах? И не выключается совсем? Не смеши меня.

    G>>Ну время даунтайма пару часов в месяц — мелочи. Бывает и свет на большее время отключают.
    A>Есть фирмы для которых пара часов в месяц не мелочь. Вот представь себе что так.
    Так они банально платят деньги чтобы получить 99,999% работосособности.

    G>>Кроме того для малых бизнесов подходят интранет решения, без выхода во внешнюю сеть.

    G>>Если нужно взаимодействие между несколькими крупными офисами, то интранет решения в каждом из них могут обмениваться информацией через веб-сервисы и репликацию БД.
    A>Для которых нужен интернет или личная оптика.
    Нужен, только не постоянно.
    Можно по расписаних синхронизироватся через супер-пупер надежный GSM\GPRS.

    A>>>Из общедоступных, как минимум GSM сети надёжнее интернета.

    G>>Мда.. сравнивать средства канального уровня и сетевого конечно круто.
    A>Уверен, что GSM сеть это канальный уровень?
    Да
    Re[37]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 24.04.09 07:26
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    L>>>>Не, получается совершено обычный UI для учетных систем. Они все на одно лицо.

    G>>>"обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.

    L>>Где ты увидел сотню полей? По приведенной ссылке их всего несколько. Так что давай, не увиливай, пиши как PE делать.

    G>Я же сказал, что для отображения списков и списков списков сущностей можно придумать общую структуру а не плодить *Info классы.

    Ну так приведи ее? Или это настолько редкая задача?
    G>>>Так хороший UI и должен отображать минимум сущностей и при этом покрывать максимум задач пользователя. Желательно в интуитивно-понятной форме с подсказками.
    L>>В гмейле отображение минимума сущностей объясняется не продуманностью UI, а простотой предметной области и только.
    G>Это уже отмазка.

    Какая еще отмазка? Это совершенно разные классы приложений.

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

    G>В основном все бизнес-операции зависят от некоторого среза (проекции) атрибутов сущности или группы сущностей.
    G>При этом построители интерфейса счиатют что можно на одной форме вывалить три десятка аотрибутов и заставить пользователя управляться с этим.

    Опять три десятка атрибутов. Откуда ты их взял. В моей потановке их 3 на сущность.
    Кстати, с десятком и париться бы не пришлось, т.к. *Info-классов тогда не понадбилось бы, можно было бы использовать непосредственно сущности.

    G>>>Крмое того в веб-приложении октрытие дополнительных окон ничего не стоит, в отличие от десктопа. Этим надо пользоваться.

    G>>>Кстати поэтому навигация на постбеках — зло.
    L>>Не уходи от темы. Я все еще жду правильных PE.
    G>См выше.
    G>Вообще говоря без кода я вряд ли смогу что-нить адекватое предложить.

    Re[38]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 24.04.09 07:33
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

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


    L>>>>>Не, получается совершено обычный UI для учетных систем. Они все на одно лицо.

    G>>>>"обычный UI для учетных систем" это и есть super-busy UI. Вообще-то ui также надо проектировать под задачи, а не вываливать списки с сотнями полей и десятками действий.

    L>>>Где ты увидел сотню полей? По приведенной ссылке их всего несколько. Так что давай, не увиливай, пиши как PE делать.

    G>>Я же сказал, что для отображения списков и списков списков сущностей можно придумать общую структуру а не плодить *Info классы.
    L>Ну так приведи ее? Или это настолько редкая задача?
    Покажи код. Умением "лечит геморрой по фотографии" не обладаю.

    G>>>>Так хороший UI и должен отображать минимум сущностей и при этом покрывать максимум задач пользователя. Желательно в интуитивно-понятной форме с подсказками.

    L>>>В гмейле отображение минимума сущностей объясняется не продуманностью UI, а простотой предметной области и только.
    G>>Это уже отмазка.
    L>Какая еще отмазка? Это совершенно разные классы приложений.
    Принципы хорошего UI не зависит от класса приложений.

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

    G>>В основном все бизнес-операции зависят от некоторого среза (проекции) атрибутов сущности или группы сущностей.
    G>>При этом построители интерфейса счиатют что можно на одной форме вывалить три десятка аотрибутов и заставить пользователя управляться с этим.
    L>Опять три десятка атрибутов. Откуда ты их взял. В моей потановке их 3 на сущность.
    L>Кстати, с десятком и париться бы не пришлось, т.к. *Info-классов тогда не понадбилось бы, можно было бы использовать непосредственно сущности.
    Это были общие размышения.
    Конкретно по твоему случаю без кода сказать ничего не могу.
    Re[39]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 24.04.09 07:46
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    L>>>>Где ты увидел сотню полей? По приведенной ссылке их всего несколько. Так что давай, не увиливай, пиши как PE делать.

    G>>>Я же сказал, что для отображения списков и списков списков сущностей можно придумать общую структуру а не плодить *Info классы.
    L>>Ну так приведи ее? Или это настолько редкая задача?
    G>Покажи код. Умением "лечит геморрой по фотографии" не обладаю.

    Код чего?

    L>>>>В гмейле отображение минимума сущностей объясняется не продуманностью UI, а простотой предметной области и только.

    G>>>Это уже отмазка.
    L>>Какая еще отмазка? Это совершенно разные классы приложений.
    G>Принципы хорошего UI не зависит от класса приложений.

    Ладно, проехали. Пусть будет так.
    PE-то будут?

    L>>Опять три десятка атрибутов. Откуда ты их взял. В моей потановке их 3 на сущность.

    L>>Кстати, с десятком и париться бы не пришлось, т.к. *Info-классов тогда не понадбилось бы, можно было бы использовать непосредственно сущности.
    G>Это были общие размышения.

    Не надо общих размышлений по вполне конкретному вопросу.

    G>Конкретно по твоему случаю без кода сказать ничего не могу.


    Без какого кода-то?
    Re[40]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 24.04.09 08:11
    Оценка:
    Здравствуйте, Lloyd, Вы писали:

    L>Без какого кода-то?

    Без кода вьюхи и контроллера помочь не могу.
    Re[30]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 24.04.09 14:41
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    EC>Это всё хорошо, но где при паттерн матчинге происходит динамическое приведение типа?


    Динамическое приведение может и есть, но вот ошибки типов быть не может, так как тип изначально закрытый (известны все вхождения) и можно проверить правильность приведения еще во время компиляции. Более того, сама конструкция match (case и т.п.) предусматривает только перечисление конкретных типов и одного случая в случае если ни один из перечисленных случаев не работает. Так что ошибки быть не может.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[41]: Проблемы организации OR-мапинга
    От: Lloyd Россия  
    Дата: 24.04.09 19:00
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    L>>Без какого кода-то?

    G>Без кода вьюхи и контроллера помочь не могу.

    Зачем он тебе?
    Re[31]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 24.04.09 19:46
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    EC>>Это всё хорошо, но где при паттерн матчинге происходит динамическое приведение типа?


    VD>Динамическое приведение может и есть, но вот ошибки типов быть не может, так как тип изначально закрытый (известны все вхождения) и можно проверить правильность приведения еще во время компиляции. Более того, сама конструкция match (case и т.п.) предусматривает только перечисление конкретных типов и одного случая в случае если ни один из перечисленных случаев не работает. Так что ошибки быть не может.

    Я именно об этом и толкую.
    Динамическому приведению типа всё равно там делать нечего.
    now playing: Swat-Squad — Monsterism
    Re[57]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 25.04.09 08:43
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>>>И каким образом должно учитываться содержание?

    G>При желании сам разработчик может разбит документ на несколько.

    Нет механизма client side includes, так что сам разработчик разбить документы на несколько не может.

    G>Вне офиса много чего находится. Я вот сильно сомневаюсь что "большой бизнес", с использованием компьютеров (именно такой нас интересует), делается в сортире.

    G>Так что давай конкретнее.

    Послушай, если ты не знаешь что такое "вне офиса", то это конечно очень странно. По-твоему строители, например, в кабинете сидят? Есть виды деятельности где большая часть сотрудников занимается не перекладыванием бумажек, а чем-то другим.

    A>>Есть фирмы для которых пара часов в месяц не мелочь. Вот представь себе что так.

    G>Так они банально платят деньги чтобы получить 99,999% работосособности.

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

    G>Нужен, только не постоянно.

    G>Можно по расписаних синхронизироватся через супер-пупер надежный GSM\GPRS.

    Это не решение. Например, в зависимости от размера добавленной стоимости может меняться налогообложение, поэтому очень важно иметь актуальные данные о себестоимости.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[60]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 25.04.09 10:17
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Нет механизма client side includes, так что сам разработчик разбить документы на несколько не может.

    G>>Есть, фреймы называется.
    G>>А уж с помощью AJAX вообще можно сделать все.
    A>Эти все технологии имеют очевидные минусы. Например, нельзя получить адрес страницы.
    Какой страницы?

    A>>>Послушай, если ты не знаешь что такое "вне офиса", то это конечно очень странно. По-твоему строители, например, в кабинете сидят? Есть виды деятельности где большая часть сотрудников занимается не перекладыванием бумажек, а чем-то другим.

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

    A>Видишь ли, резервирование каналов не работает, если кабели разных компаний лежат в одной траншее. То есть, конечно, можно себя убеждать что покупая тырнет у разных фирм ты что-то меняешь, но хорошо бы и с физической топологией ознакомиться для начала. Реальная альтернатива кабелям — беспроводные сети. К сожалению качество работы разных WiMAX пока не впечатляет, а GSM провайдеры берут дорого.

    Не надо плачей в пользу бедных. Кому надо, те делают.

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

    G>>Не надо налоги считать по факту совершения проводки, отчетность сдается за период.
    G>>В 1С например "документы" — информация о движении средств, отделена от "регистов" — непосредственно учетных единиц. Правла проведения документов можно менять, поменяются регистры, но документы останутся теми же.

    A>Ага, ага. Вот почему в 1С есть понятие "восстановления последовательности" Нельзя считать налоги постфактум если от конечной цены меняются налоги. Такое документы надо проводить оперативно. Кстати, 1С в этом смысле полностью облажались предложив рассчитывать себестоимость раз в 5 минут.

    Ниче не понял, приведи пример что нужно сделать. А потом расскажи как локальная реплика поможет в этом случае и как часто надо её синхронизировать.
    Re[61]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 25.04.09 10:29
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>>>А уж с помощью AJAX вообще можно сделать все.

    A>>Эти все технологии имеют очевидные минусы. Например, нельзя получить адрес страницы.
    G>Какой страницы?

    Той которую видишь. Зайди на сайт RSDN.ru, открой в дереве слева список форумов, щёлкни на форуме, шёлкни вверху на сообщении в форуме. Сверху будет адрес — rsdn.ru. Это про фреймы. Про AJAX — в GoogleMaps, аналогичная ситуация. Прокручиваешь карту, масштабируешь, а адрес не меняется.

    G>>>Cеть бабушек, торгующих семечками, нас не интересует.

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

    Более предметно, практически все до кого дошёл прогресс ходят с покетами. То есть ты конечно можешь смотреть в окно на красивые, не тронутые человеком, пейзажи Мухосранска, но с покетами сейчас ходят представители практически всех родов деятельности: менеджеры, почтальоны, официанты, полицейские, лекторы, студенты и т.д. Если этого где-то ещё нет, то это вопрос отставания от прогресса, а не отсутствия необходимости.

    A>>Видишь ли, резервирование каналов не работает, если кабели разных компаний лежат в одной траншее. То есть, конечно, можно себя убеждать что покупая тырнет у разных фирм ты что-то меняешь, но хорошо бы и с физической топологией ознакомиться для начала. Реальная альтернатива кабелям — беспроводные сети. К сожалению качество работы разных WiMAX пока не впечатляет, а GSM провайдеры берут дорого.

    G>Не надо плачей в пользу бедных. Кому надо, те делают.

    Ясно, с темой не знаком вообще.

    A>>Ага, ага. Вот почему в 1С есть понятие "восстановления последовательности" Нельзя считать налоги постфактум если от конечной цены меняются налоги. Такое документы надо проводить оперативно. Кстати, 1С в этом смысле полностью облажались предложив рассчитывать себестоимость раз в 5 минут.

    G>Ниче не понял, приведи пример что нужно сделать.

    Что не ясного? На момент продажи надо знать себестоимость, так как от размера прибыли меняется налоговая ставка.

    G>А потом расскажи как локальная реплика поможет в этом случае и как часто надо её синхронизировать.


    ЛОЛ. Вообще-то тут обсуждалась необходимость постоянного соединения, а не локальной реплики. Надо не только писать, но и читать иногда.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[62]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 25.04.09 11:33
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Той которую видишь. Зайди на сайт RSDN.ru, открой в дереве слева список форумов, щёлкни на форуме, шёлкни вверху на сообщении в форуме. Сверху будет адрес — rsdn.ru. Это про фреймы. Про AJAX — в GoogleMaps, аналогичная ситуация. Прокручиваешь карту, масштабируешь, а адрес не меняется.

    Зайди на википамию, посмотри как такие проблемы побеждаются.

    G>>>>Cеть бабушек, торгующих семечками, нас не интересует.

    A>>>У тебя очень узкое понятие компьютера, вспомни о покетах.
    G>>Угу, все подряд строители, ассенизаторы и бабушки с семечками юзают покеты с установленными торговыми системами
    A>Более предметно, практически все до кого дошёл прогресс ходят с покетами. То есть ты конечно можешь смотреть в окно на красивые, не тронутые человеком, пейзажи Мухосранска, но с покетами сейчас ходят представители практически всех родов деятельности: менеджеры, почтальоны, официанты, полицейские, лекторы, студенты и т.д. Если этого где-то ещё нет, то это вопрос отставания от прогресса, а не отсутствия необходимости.
    Конкретно опиши процесс "большого бизнеса" в котором используются массово кпк без наличия постоянного соединения.

    A>>>Видишь ли, резервирование каналов не работает, если кабели разных компаний лежат в одной траншее. То есть, конечно, можно себя убеждать что покупая тырнет у разных фирм ты что-то меняешь, но хорошо бы и с физической топологией ознакомиться для начала. Реальная альтернатива кабелям — беспроводные сети. К сожалению качество работы разных WiMAX пока не впечатляет, а GSM провайдеры берут дорого.

    G>>Не надо плачей в пользу бедных. Кому надо, те делают.
    A>Ясно, с темой не знаком вообще.
    Знаком. А в общем какая разница.
    Мало какому бизнесу требуется постоянное соединение, а какому требуется, те платят деньги и обеспечивают себе таковое. Принципиальных преград в этом нет.

    A>Что не ясного? На момент продажи надо знать себестоимость, так как от размера прибыли меняется налоговая ставка.

    С чего ты это взял? На момент продажи нужна цена. Остальное считается потом.
    Re[63]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 25.04.09 12:11
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Более предметно, практически все до кого дошёл прогресс ходят с покетами. То есть ты конечно можешь смотреть в окно на красивые, не тронутые человеком, пейзажи Мухосранска, но с покетами сейчас ходят представители практически всех родов деятельности: менеджеры, почтальоны, официанты, полицейские, лекторы, студенты и т.д. Если этого где-то ещё нет, то это вопрос отставания от прогресса, а не отсутствия необходимости.

    G>Конкретно опиши процесс "большого бизнеса" в котором используются массово кпк без наличия постоянного соединения.

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

    G>>>Не надо плачей в пользу бедных. Кому надо, те делают.

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

    Речь изначально шла о том, что тонкие клиенты не выход в общем случае.

    A>>Что не ясного? На момент продажи надо знать себестоимость, так как от размера прибыли меняется налоговая ставка.

    G>С чего ты это взял?

    Есть такая штука — налоговое законодательство.

    G>На момент продажи нужна цена. Остальное считается потом.


    Цена может меняться в зависимости от объёма партии и клиента. В общем твои аргументы не в кассу, потому что я говорю о реальной ситуации возникшей с 1С.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[64]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 25.04.09 12:23
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Более предметно, практически все до кого дошёл прогресс ходят с покетами. То есть ты конечно можешь смотреть в окно на красивые, не тронутые человеком, пейзажи Мухосранска, но с покетами сейчас ходят представители практически всех родов деятельности: менеджеры, почтальоны, официанты, полицейские, лекторы, студенты и т.д. Если этого где-то ещё нет, то это вопрос отставания от прогресса, а не отсутствия необходимости.

    G>>Конкретно опиши процесс "большого бизнеса" в котором используются массово кпк без наличия постоянного соединения.

    A>Дистрибуция. Агент приходит с покетом в магазин брать заказ или продавать. Никаких гарантий интернета на "чужой" территории нет и быть не может.

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

    G>>>>Не надо плачей в пользу бедных. Кому надо, те делают.

    A>>>Ясно, с темой не знаком вообще.
    G>>Знаком. А в общем какая разница.
    G>>Мало какому бизнесу требуется постоянное соединение, а какому требуется, те платят деньги и обеспечивают себе таковое. Принципиальных преград в этом нет.
    A>Речь изначально шла о том, что тонкие клиенты не выход в общем случае.
    По тезису, который я привел выше — очень даже выход.
    Даже покеты чуть ли не поголовно умеют выходить в инет через GPRS\3g\WiMax.


    A>>>Что не ясного? На момент продажи надо знать себестоимость, так как от размера прибыли меняется налоговая ставка.

    G>>С чего ты это взял?
    A>Есть такая штука — налоговое законодательство.
    Есть, и что? Отчеты сдаются несколько раз в год.

    G>>На момент продажи нужна цена. Остальное считается потом.

    A>Цена может меняться в зависимости от объёма партии и клиента. В общем твои аргументы не в кассу, потому что я говорю о реальной ситуации возникшей с 1С.
    Да мне как-то все равно что в 1с возникало. Я говорю что нету принципиальной необходимости знать что-то кроме цены на момент продажи.
    Поэтоу даже если вдруг в магазине не будет связи с головной конторой, то продать все равно можно.

    А если речь идет о торговле b2b, то её сейчас вообще мало кто без инета делает (ну или факсом счета отправляют).
    Re[65]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 25.04.09 12:37
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Дистрибуция. Агент приходит с покетом в магазин брать заказ или продавать. Никаких гарантий интернета на "чужой" территории нет и быть не может.

    G>Заказать через инет из офиса не проще?

    Кому заказать из офиса?
    Агенту? Там несколько тысяч позиций, куда записывать заказ, в блокнот?
    Клиенту? Это уменьшит продажи дистрибуторской фирмы в разы.

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


    Бу-га-га.

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

    A>>Речь изначально шла о том, что тонкие клиенты не выход в общем случае.
    G>По тезису, который я привел выше — очень даже выход.
    G>Даже покеты чуть ли не поголовно умеют выходить в инет через GPRS\3g\WiMax.

    То что у покетов есть GPRS вовсе не означает что это хорошее решение. Я сталкивался на своём ропыте с ситуацийе когда кабельного интернета (оптика) не было твое суток, GSM связи не было около суток. Торговые агенты при этом продолжали брать заказы и вообще работали почти как обычно.

    G>Я говорю что нету принципиальной необходимости знать что-то кроме цены на момент продажи.


    Это не верно.

    G>Поэтому даже если вдруг в магазине не будет связи с головной конторой, то продать все равно можно.


    Вопрос — какие скидки делать?

    G>А если речь идет о торговле b2b, то её сейчас вообще мало кто без инета делает (ну или факсом счета отправляют).


    Речь идёт об очень простой штукенции. У тебя промо-акция, например, на каждые 5 купленных штук ты одну даришь. Это в среднем, можно на 24 подарить 5, а можно на 100 подарить 3. Прочие скидки (на позицию, на группу товаров, на общую сумму) тоже работают. Есть вдруг продаёшь ниже себестоимости платишь дополнительный налог на данную конкретную продажу. Когда делается отчёт, через год или через два, по фиг. Ты из себя строишь супер-опытного, но когда я говорю об элементарнейших сценариях выясняется что ты вообще ничего не смыслишь с реальных бизнес процессах реальных компаний. Это странно для супер-опытного.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[66]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 25.04.09 13:00
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Дистрибуция. Агент приходит с покетом в магазин брать заказ или продавать. Никаких гарантий интернета на "чужой" территории нет и быть не может.

    G>>Заказать через инет из офиса не проще?

    A>Кому заказать из офиса?

    A>Агенту? Там несколько тысяч позиций, куда записывать заказ, в блокнот?
    A>Клиенту? Это уменьшит продажи дистрибуторской фирмы в разы.
    Не выдумывай, полмира делает закупки удаленно, а ты все про агентов с покетами.

    A>То что у покетов есть GPRS вовсе не означает что это хорошее решение. Я сталкивался на своём ропыте с ситуацийе когда кабельного интернета (оптика) не было твое суток, GSM связи не было около суток. Торговые агенты при этом продолжали брать заказы и вообще работали почти как обычно.


    У нормальных людей b2b системы стоят на выделенных серверах хостеров, которые обеспечивают uptime 99.5%-99.9% (SLA)

    G>>Я говорю что нету принципиальной необходимости знать что-то кроме цены на момент продажи.

    A>Это не верно.
    Докажи. Только не указывая ограничения конкретных программ и конкретных процессов.
    Я уверен что любой твой придуманный сценарий можно свести к необходимости только знать цену на момент продажи.

    G>>Поэтому даже если вдруг в магазине не будет связи с головной конторой, то продать все равно можно.

    A>Вопрос — какие скидки делать?
    Это зависит от способа идентификации клиента. Если карточка — то вполне достаточно алгоритма валидации карты и считывания величины скидки с нее.
    Если требуется lookup по базе клиентов, то никуда не денешься, реплицировать надо или соединение держать.
    В случае розницы карточки удобнее, в случае b2b — гораздо удеобнее удаленное взаимодействие (вплоть до автоматического) без хождения агентов или еще кого-то.

    G>>А если речь идет о торговле b2b, то её сейчас вообще мало кто без инета делает (ну или факсом счета отправляют).

    A>Речь идёт об очень простой штукенции. У тебя промо-акция, например, на каждые 5 купленных штук ты одну даришь. Это в среднем, можно на 24 подарить 5, а можно на 100 подарить 3. Прочие скидки (на позицию, на группу товаров, на общую сумму) тоже работают. Есть вдруг продаёшь ниже себестоимости платишь дополнительный налог на данную конкретную продажу. Когда делается отчёт, через год или через два, по фиг.
    Ну и? Что кроме цены надо знать на момент продажи?
    Ведь вся информация сохраняется, сколько продали за раз, сколько дали в подарок итп.
    Это является "документом", когда проводится в бухгалтерской системе оно становится набором проводок и все счиается нормально.

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

    Конечно я не знаю рельных процессов компаний, с которыми ты работал.
    А вообще не стоит на личности переходить.
    Лучше аргументированно доказывай свою точку зрения, если в какой-то фирме процесс поставлен так как ты описываешь, то это не значит что это единственный вариант работы.
    Re[67]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 25.04.09 14:28
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Клиенту? Это уменьшит продажи дистрибуторской фирмы в разы.

    G>Не выдумывай, полмира делает закупки удаленно, а ты все про агентов с покетами.

    Не говори глупости, если не разбираешься в предметной области.

    G>Докажи. Только не указывая ограничения конкретных программ и конкретных процессов.

    G>Я уверен что любой твой придуманный сценарий можно свести к необходимости только знать цену на момент продажи.

    gandjustas, я говорю о реальной(!) ситуации. Это у тебя всё теория сплошная.

    A>>Речь идёт об очень простой штукенции. У тебя промо-акция, например, на каждые 5 купленных штук ты одну даришь. Это в среднем, можно на 24 подарить 5, а можно на 100 подарить 3. Прочие скидки (на позицию, на группу товаров, на общую сумму) тоже работают. Есть вдруг продаёшь ниже себестоимости платишь дополнительный налог на данную конкретную продажу. Когда делается отчёт, через год или через два, по фиг.

    G>Ну и? Что кроме цены надо знать на момент продажи?
    G>Ведь вся информация сохраняется, сколько продали за раз, сколько дали в подарок итп.
    G>Это является "документом", когда проводится в бухгалтерской системе оно становится набором проводок и все счиается нормально.

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

    Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11.
    После начисления всех скидок конечная цена стала 10.5. Компании выгоднее продать по 11 оформив 0 прибыли, чем продать по 10.5 и заплатить налог за продажу ниже себестоимости. Для этого надо знать текущую себестоимость. Для этого надо иметь связь. Ты почему-то этот простейший пример, ситуацию которая встречается не так уж редко, совершенно не понимаешь.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[68]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 25.04.09 16:36
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11.

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

    Ну и нужна связь, тонкий клиент в таком случае очень даже работает. Если всегда надо знать текущую себестоимость, то накакое кеширование на клиенте не спасет.
    Re[69]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 26.04.09 06:54
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11.

    A>>После начисления всех скидок конечная цена стала 10.5. Компании выгоднее продать по 11 оформив 0 прибыли, чем продать по 10.5 и заплатить налог за продажу ниже себестоимости. Для этого надо знать текущую себестоимость. Для этого надо иметь связь. Ты почему-то этот простейший пример, ситуацию которая встречается не так уж редко, совершенно не понимаешь.
    G>Теперь понял, сразу бы такой сценарий описал.
    G>Ну и нужна связь, тонкий клиент в таком случае очень даже работает. Если всегда надо знать текущую себестоимость, то накакое кеширование на клиенте не спасет.

    Боже, а кто говорил что от этого кеширование спасает? Ты вообще заметил что мы тут несколько вопросов обсуждаем?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[70]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 26.04.09 06:59
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11.

    A>>>После начисления всех скидок конечная цена стала 10.5. Компании выгоднее продать по 11 оформив 0 прибыли, чем продать по 10.5 и заплатить налог за продажу ниже себестоимости. Для этого надо знать текущую себестоимость. Для этого надо иметь связь. Ты почему-то этот простейший пример, ситуацию которая встречается не так уж редко, совершенно не понимаешь.
    G>>Теперь понял, сразу бы такой сценарий описал.
    G>>Ну и нужна связь, тонкий клиент в таком случае очень даже работает. Если всегда надо знать текущую себестоимость, то накакое кеширование на клиенте не спасет.

    A>Боже, а кто говорил что от этого кеширование спасает? Ты вообще заметил что мы тут несколько вопросов обсуждаем?


    Дык весь разговор начался с того что тонкий клиент применить не везде возможно именно по причине отсустствия постоянного соединения. Именно локальная реплика + синхронизация позволяют работать в таких условиях.
    А в итоге ты привел пример где нужно постоянное соединение даже при работе с мобильным устройством.
    Re[68]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 26.04.09 07:05
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11.

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

    Кстати этот сценарий тоже попадает в категорию необходимости знания только цены. Ведь агента мало интересует налоги и прочее, достаточно знать цену по которой надо продавать.
    Re[71]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 26.04.09 07:59
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Боже, а кто говорил что от этого кеширование спасает? Ты вообще заметил что мы тут несколько вопросов обсуждаем?

    G>Дык весь разговор начался с того что тонкий клиент применить не везде возможно именно по причине отсутствия постоянного соединения. Именно локальная реплика + синхронизация позволяют работать в таких условиях. А в итоге ты привел пример где нужно постоянное соединение даже при работе с мобильным устройством.

    Всё несколько не так. Давай я ещё раз объясню.

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

    Вот. С этим по большому счёту никто и не спорил, насколько я заметил.

    Далее. Тонкие клиенты не позволяют работать в offline режиме, накапливая изменения. Мобильные сотрудники в связи с дешевизной мобильных компьютеров становятся всё более распространены. Работа в online режиме всегда хорошо, но не всегда возможно. Отсутствие связи не повод для отказа. Тут пошли разговоры про 99.999% аптайма каналов связи. Я не считаю что стоит полагаться на аптайм канала связи.

    Вот это и повод для спора: что делать? Ты предлагаешь требовать работоспособность канала. Я считаю это недопустимым. Ты предлагаешь кешировать результаты отдельных запросов, я считаю что лучше делать реплику, так как она строиться сложно, по ресурсам (трафик, место) выгоднее и функциональнее. Ты почему-то считаешь что с репликой сложнее работать.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[72]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 26.04.09 10:16
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Боже, а кто говорил что от этого кеширование спасает? Ты вообще заметил что мы тут несколько вопросов обсуждаем?

    G>>Дык весь разговор начался с того что тонкий клиент применить не везде возможно именно по причине отсутствия постоянного соединения. Именно локальная реплика + синхронизация позволяют работать в таких условиях. А в итоге ты привел пример где нужно постоянное соединение даже при работе с мобильным устройством.

    A>Всё несколько не так. Давай я ещё раз объясню.


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


    A>Вот. С этим по большому счёту никто и не спорил, насколько я заметил.

    Как раз с этим и спорили, потому что твое утверждение неверно в общем случае.

    Тонкий клиент получает минимум данных, необходимых для отображения, причем можно организовать локальное кеширование на timestamp и rowversion (как в HTTP) для оптимизации. Самое главное что такой кеш не требует дополнительных приседания для поддержания его когерентности.
    В случае с локальной репликой, как ты сам говорил, требуют ссылочно-целостного подмножества данных, чтобы не пришлоль разруливать конфликты целостности на сервере. Поддержание когерентности такой реплики при постоянно меняющихся данных требует больше ресурсов, как на клиенте, так и на сервере.
    Единственный вариант, когда локальная реплика может оказаться предпочтительнее — когда для нормальной работы не требуются 100% актуальные данные, а сама реплика по размеру не велика. Пример такому — торговые терминалы.

    A>Далее. Тонкие клиенты не позволяют работать в offline режиме, накапливая изменения. Мобильные сотрудники в связи с дешевизной мобильных компьютеров становятся всё более распространены. Работа в online режиме всегда хорошо, но не всегда возможно. Отсутствие связи не повод для отказа. Тут пошли разговоры про 99.999% аптайма каналов связи. Я не считаю что стоит полагаться на аптайм канала связи.

    С мобильными компьютерами разщвивются и мобильные средства связи. Поэтому получить соединение — не проблема.
    Многе сознательно отказываются от толстых клиентов в пользу веб-приложений чтобы избежать проблем с деплоем.

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

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

    Требовать работоспособность канала — громко сказано. Требовать у клиента такое неполчучается. Обычно клиент приходит со своими параметрами и надо подбирать решенее, наиболее удовлетворяющее этим параметрам.
    Только можно выбирать исходя из пессимистичных соображений, типа "связи с сервером вероятнее всего не будет", или из оптимистичных — "связь таки будет".
    Re[73]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 26.04.09 10:39
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    G>Тонкий клиент получает минимум данных, необходимых для отображения, причем можно организовать локальное кеширование на timestamp и rowversion (как в HTTP) для оптимизации. Самое главное что такой кеш не требует дополнительных приседания для поддержания его когерентности.

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

    На самом деле всё не так. Если клиент видит не все данные, то изменение данных, которые он не видит поменяет timestamp/rowversion и приведёт к лишней загрузке данных. То есть либо эффективность использования кеша конкретным тонким клиентом зависит от активности остальных (не масштабируемая система), либо мы тратим ресурсы сервера (а именно они дорогие, на клиента плевать) на поддержание персональных timestamp/rowversion.

    G>Единственный вариант, когда локальная реплика может оказаться предпочтительнее — когда для нормальной работы не требуются 100% актуальные данные, а сама реплика по размеру не велика. Пример такому — торговые терминалы.


    Ну да. А антипример можно?

    A>>Далее. Тонкие клиенты не позволяют работать в offline режиме, накапливая изменения. Мобильные сотрудники в связи с дешевизной мобильных компьютеров становятся всё более распространены. Работа в online режиме всегда хорошо, но не всегда возможно. Отсутствие связи не повод для отказа. Тут пошли разговоры про 99.999% аптайма каналов связи. Я не считаю что стоит полагаться на аптайм канала связи.

    G>С мобильными компьютерами разщвивются и мобильные средства связи. Поэтому получить соединение — не проблема.

    Получить соединение вообще никогда не было проблемой. Проблема — постоянно иметь соединение.

    G>Многе сознательно отказываются от толстых клиентов в пользу веб-приложений чтобы избежать проблем с деплоем.


    Веб-приложение это очень простой и негибкий кеш (а wireless провайдеры тарифицируют трафик) и убогий интерфейс. К тому же это не приемлемо из административных соображений. Как показала практика — главная проблема для покета — это позволить запускать только фронт-офис. Несознательные личности, пользуясь корпоративными картами, оплачивают сервисы (оценки на грёбаных одноклассниках), качают порно и что только ещё не делают. Позволить запускать IE или любой другой браузер просто крайне дорого. При стоимости необходимых компании услуг в 3$, приходят счета на 50-100$. Это, конечно, разбирается, вычитается из зарплаты, бывают увольнения. Но практика показала, что покет должен быть в kiosk mode, иначе его эксплуатация обойдётся очень-очень дорого. Если сравнить необходимые человеческие ресурсы, какой-то там деплоймент это сущие пустяки. Кроме того есть системы прошивки покетов, которые значительно упрощают процесс.

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


    Но предметной области так и не привёл, а я сам такую не припомню. Можно конкретики?

    G>Требовать работоспособность канала — громко сказано. Требовать у клиента такое неполчучается. Обычно клиент приходит со своими параметрами и надо подбирать решенее, наиболее удовлетворяющее этим параметрам.

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

    Админы делятся на две категории: те, которые уже делают резервные копии, и те, которые ещё не делают.
    Вот я уже не считаю что "связь таки будет". И делаю резервные копии
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[74]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 26.04.09 11:52
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    G>>Тонкий клиент получает минимум данных, необходимых для отображения, причем можно организовать локальное кеширование на timestamp и rowversion (как в HTTP) для оптимизации. Самое главное что такой кеш не требует дополнительных приседания для поддержания его когерентности.

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

    A>На самом деле всё не так. Если клиент видит не все данные, то изменение данных, которые он не видит поменяет timestamp/rowversion и приведёт к лишней загрузке данных.

    Это неверно. Timestamp выбирается максимальный из выборки видимых записей. Синклер приводил запрос для получения дельты.

    A>То есть либо эффективность использования кеша конкретным тонким клиентом зависит от активности остальных (не масштабируемая система)

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

    A>либо мы тратим ресурсы сервера (а именно они дорогие, на клиента плевать) на поддержание персональных timestamp/rowversion.

    Персональные timestamp/rowversion держит клиент и передает при каждом запросе данных.

    G>>Единственный вариант, когда локальная реплика может оказаться предпочтительнее — когда для нормальной работы не требуются 100% актуальные данные, а сама реплика по размеру не велика. Пример такому — торговые терминалы.

    A>Ну да. А антипример можно?
    Wiki

    A>Получить соединение вообще никогда не было проблемой. Проблема — постоянно иметь соединение.

    А зачем? Достаточно иметь возможность подключиться в любой момент.

    G>>Многе сознательно отказываются от толстых клиентов в пользу веб-приложений чтобы избежать проблем с деплоем.


    A>Веб-приложение это очень простой и негибкий кеш (а wireless провайдеры тарифицируют трафик)

    История показывает что самые простые решения оказываются самым эффективными. При правильном применении HTTP кеширование может быть очень эффективным.

    A>и убогий интерфейс.

    По сравнению с чем? Для бизнес-задач более чем хватает.

    A>К тому же это не приемлемо из административных соображений. Как показала практика — главная проблема для покета — это позволить запускать только фронт-офис. Несознательные личности, пользуясь корпоративными картами, оплачивают сервисы (оценки на грёбаных одноклассниках), качают порно и что только ещё не делают. Позволить запускать IE или любой другой браузер просто крайне дорого. При стоимости необходимых компании услуг в 3$, приходят счета на 50-100$. Это, конечно, разбирается, вычитается из зарплаты, бывают увольнения. Но практика показала, что покет должен быть в kiosk mode, иначе его эксплуатация обойдётся очень-очень дорого. Если сравнить необходимые человеческие ресурсы, какой-то там деплоймент это сущие пустяки. Кроме того есть системы прошивки покетов, которые значительно упрощают процесс.


    Мда... Решать проблемы быдлоперсонала тамими методами — это смешно.
    Ктсати, кто мешает сделать kiosk-mode для браузера с одним адресом?

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

    A>Но предметной области так и не привёл, а я сам такую не припомню. Можно конкретики?
    В любой предметной области. вообще-то предметная область ортогональна архитектурным решениям.
    Только не надо опять сводить к случаю, где каждый пользователь работает только со своей частью данных. Это практически тоже самое, что и однопользовательская система, а там вообще серверы не нужны.
    Re[75]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 26.04.09 12:25
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>На самом деле всё не так. Если клиент видит не все данные, то изменение данных, которые он не видит поменяет timestamp/rowversion и приведёт к лишней загрузке данных.

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

    Во-первых, либо надо синхронизировать время между клиентом и сервером, либо с каждым запросом передавать timestamp. Сразу скажу, на практике работает только второй вариант То есть интерфейс мы уже усложнили. Далее, когда делать обновления? При каждой визуализации списка? Если нет, то когда кеш устаревает? В твоём случае однозначного ответа нет, в моём есть — при нарушении ссылочной целостности. Я хочу сказать что если ты не обновляешь список при каждой визуализации то сталкиваешься с очень серьёзными проблемами. А если обновляешь при каждой, то сталкиваешься с сильной нагрузкой на сервер. И мне совсем не ясно зачем это делать и какая тут выгода.

    A>>То есть либо эффективность использования кеша конкретным тонким клиентом зависит от активности остальных (не масштабируемая система)

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

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

    G>>>Единственный вариант, когда локальная реплика может оказаться предпочтительнее — когда для нормальной работы не требуются 100% актуальные данные, а сама реплика по размеру не велика. Пример такому — торговые терминалы.

    A>>Ну да. А антипример можно?
    G>Wiki

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

    A>>Получить соединение вообще никогда не было проблемой. Проблема — постоянно иметь соединение.

    G>А зачем? Достаточно иметь возможность подключиться в любой момент.

    Ну да, это я и имел ввиду. Иметь возможность подключиться в любой момент.

    A>>и убогий интерфейс.

    G>По сравнению с чем? Для бизнес-задач более чем хватает.

    Хватает и эффективно суть разные вещи. Хватает для всего даже командной строки.

    A>>К тому же это не приемлемо из административных соображений. Как показала практика — главная проблема для покета — это позволить запускать только фронт-офис. Несознательные личности, пользуясь корпоративными картами, оплачивают сервисы (оценки на грёбаных одноклассниках), качают порно и что только ещё не делают. Позволить запускать IE или любой другой браузер просто крайне дорого. При стоимости необходимых компании услуг в 3$, приходят счета на 50-100$. Это, конечно, разбирается, вычитается из зарплаты, бывают увольнения. Но практика показала, что покет должен быть в kiosk mode, иначе его эксплуатация обойдётся очень-очень дорого. Если сравнить необходимые человеческие ресурсы, какой-то там деплоймент это сущие пустяки. Кроме того есть системы прошивки покетов, которые значительно упрощают процесс.

    G>
    G>Мда... Решать проблемы быдлоперсонала тамими методами — это смешно.

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

    G>Кстати, кто мешает сделать kiosk-mode для браузера с одним адресом?


    Вот уже просото не хочется. Поверишь, 6 месяцев шаг за шагом запрещаем разные способы отсылки СМСок, запретили tmail, Pocket Outlook, перехватываем открытие знакомых окон, если нельзя процесс запретить. И всё равно шлют, хотя уже догадываюсь как и прикрою лавочку. И это СМСки. А если будет браузер... О-о-о-о! Не хочу.

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

    A>>Но предметной области так и не привёл, а я сам такую не припомню. Можно конкретики?
    G>В любой предметной области. вообще-то предметная область ортогональна архитектурным решениям.
    G>Только не надо опять сводить к случаю, где каждый пользователь работает только со своей частью данных. Это практически тоже самое, что и однопользовательская система, а там вообще серверы не нужны.

    Понимаешь, ты описываешь как всё классно у сферического коня в вакууме. Это не убедительно.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[76]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 26.04.09 13:35
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>На самом деле всё не так. Если клиент видит не все данные, то изменение данных, которые он не видит поменяет timestamp/rowversion и приведёт к лишней загрузке данных.

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

    A>Во-первых, либо надо синхронизировать время между клиентом и сервером, либо с каждым запросом передавать timestamp. Сразу скажу, на практике работает только второй вариант

    И отлично работает.

    A>То есть интерфейс мы уже усложнили.

    Это того стоит.

    A>Далее, когда делать обновления? При каждой визуализации списка? Если нет, то когда кеш устаревает? В твоём случае однозначного ответа нет, в моём есть — при нарушении ссылочной целостности. Я хочу сказать что если ты не обновляешь список при каждой визуализации то сталкиваешься с очень серьёзными проблемами. А если обновляешь при каждой, то сталкиваешься с сильной нагрузкой на сервер. И мне совсем не ясно зачем это делать и какая тут выгода.

    Обновление какого списка имеется ввиду?

    Ты видимо мало знаком с таким видом кеширования. В отличие от локальной реплики, одного паттерна для всех случаев обновления кеша при timestamp_ах нету. Надо в каждом случае подбирать наиболее эффективный вариант.


    A>>>То есть либо эффективность использования кеша конкретным тонким клиентом зависит от активности остальных (не масштабируемая система)

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

    A>Надо уметь разделять БД в соответсвии с бизнес-процессами. Никогда не бывает чтобы за одно и тоже дело было одновременно ответственно много человек. Тогда будет бардак, что с программой, что без.

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

    G>>>>Единственный вариант, когда локальная реплика может оказаться предпочтительнее — когда для нормальной работы не требуются 100% актуальные данные, а сама реплика по размеру не велика. Пример такому — торговые терминалы.

    A>>>Ну да. А антипример можно?
    G>>Wiki

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

    Не путай теплое с мягким. в Wiki важно увидеть последние изменения как можно быстрее, а при коллективной разработке это не самое важное.
    Кроме того в Wiki есть ссылочность, в отличе от исходных текстов.

    A>>>и убогий интерфейс.

    G>>По сравнению с чем? Для бизнес-задач более чем хватает.
    A>Хватает и эффективно суть разные вещи. Хватает для всего даже командной строки.
    Хватает чтобы эффективно решать задачи. Хочешь поспорить — посмотри гугловые приложения.

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

    A>Вот уже просото не хочется. Поверишь, 6 месяцев шаг за шагом запрещаем разные способы отсылки СМСок, запретили tmail, Pocket Outlook, перехватываем открытие знакомых окон, если нельзя процесс запретить. И всё равно шлют, хотя уже догадываюсь как и прикрою лавочку. И это СМСки. А если будет браузер... О-о-о-о! Не хочу.
    Пока человек имеет прямой доступ к устройству, то совем запретить ему что-то делать не получится.
    Проще через оператора запретить ходить на любые адреса, кроме определенных и запритеть пользоваться чем угодно, кроме GPRS\3G.
    А вирусы на флешках — не беда если админ не совсем баран.

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

    A>>>Но предметной области так и не привёл, а я сам такую не припомню. Можно конкретики?
    G>>В любой предметной области. вообще-то предметная область ортогональна архитектурным решениям.
    G>>Только не надо опять сводить к случаю, где каждый пользователь работает только со своей частью данных. Это практически тоже самое, что и однопользовательская система, а там вообще серверы не нужны.
    A>Понимаешь, ты описываешь как всё классно у сферического коня в вакууме. Это не убедительно.
    Я тебе привожу примеры, а ты их снова пытаешься свести к своему паттерну.
    Re[77]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 26.04.09 14:51
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Далее, когда делать обновления? При каждой визуализации списка? Если нет, то когда кеш устаревает? В твоём случае однозначного ответа нет, в моём есть — при нарушении ссылочной целостности. Я хочу сказать что если ты не обновляешь список при каждой визуализации то сталкиваешься с очень серьёзными проблемами. А если обновляешь при каждой, то сталкиваешься с сильной нагрузкой на сервер. И мне совсем не ясно зачем это делать и какая тут выгода.

    G>Обновление какого списка имеется ввиду?
    G>Ты видимо мало знаком с таким видом кеширования. В отличие от локальной реплики, одного паттерна для всех случаев обновления кеша при timestamp_ах нету. Надо в каждом случае подбирать наиболее эффективный вариант.

    Именно это я и назвал "очень серьёзными проблемами".

    A>>Надо уметь разделять БД в соответсвии с бизнес-процессами. Никогда не бывает чтобы за одно и тоже дело было одновременно ответственно много человек. Тогда будет бардак, что с программой, что без.

    G>Не выдумывай. Во многих задачах с одними и теме же данными работает много человек. Большая часть сайтов такова, любые задачи документооборота и многое другое.

    Работает в смысле читает или в смысле создаёт и модифицирует? Для чтения ручное обновление совершенно нормальная ситуация. Вот ты как смотришь что сайт обновился, жмёшь Refresh? Надо различать кеширование объектной модели для создания и модификации объектов и отчёты, которые кешировать стоит крайне редко.

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

    G>Не путай теплое с мягким. в Wiki важно увидеть последние изменения как можно быстрее, а при коллективной разработке это не самое важное.

    В Вики ты жмёшь Refresh, а конечная страница (в отличие от markup source history) носит характер отчёта.

    G>Кроме того в Wiki есть ссылочность, в отличе от исходных текстов.


    Ну да, а #include, using что такое? Имена файлов в файле проекта?

    A>>Хватает и эффективно суть разные вещи. Хватает для всего даже командной строки.

    G>Хватает чтобы эффективно решать задачи. Хочешь поспорить — посмотри гугловые приложения.

    Да видел я гугловские приложения. Интерфейс богатый, но странный. Меня, например, раздражает. Кроме того, если бы всё было так замечательно с приложениями, никто бы не делал Google Chrome.

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

    G>Проще через оператора запретить ходить на любые адреса, кроме определенных и запритеть пользоваться чем угодно, кроме GPRS\3G.

    Это если оператор такое поддерживает. Нам отказали, хотя лично я пролил не менее полулитра раздражённых слюней. Да и вообще, привязывать GPRS карту к APN штука нетипичная. Кстати, тем которые отказали софт писал CBOSS афаик, так что даже на местную тупизну пожаловаться не могу.

    G>А вирусы на флешках — не беда если админ не совсем баран.


    Согласен, но если нет проблемы, то не надо платить за её решение.

    A>>Понимаешь, ты описываешь как всё классно у сферического коня в вакууме. Это не убедительно.

    G>Я тебе привожу примеры, а ты их снова пытаешься свести к своему паттерну.

    Ты в качестве примера привёл Вики. Вики это как бы не типично для ERP/CRM.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[78]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 26.04.09 15:54
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Далее, когда делать обновления? При каждой визуализации списка? Если нет, то когда кеш устаревает? В твоём случае однозначного ответа нет, в моём есть — при нарушении ссылочной целостности. Я хочу сказать что если ты не обновляешь список при каждой визуализации то сталкиваешься с очень серьёзными проблемами. А если обновляешь при каждой, то сталкиваешься с сильной нагрузкой на сервер. И мне совсем не ясно зачем это делать и какая тут выгода.

    G>>Обновление какого списка имеется ввиду?
    G>>Ты видимо мало знаком с таким видом кеширования. В отличие от локальной реплики, одного паттерна для всех случаев обновления кеша при timestamp_ах нету. Надо в каждом случае подбирать наиболее эффективный вариант.

    A>Именно это я и назвал "очень серьёзными проблемами".


    Это мелочи, по сравнению с синхронизацей реплики, особено без использования како-нибудь Sync Framework.

    A>>>Надо уметь разделять БД в соответсвии с бизнес-процессами. Никогда не бывает чтобы за одно и тоже дело было одновременно ответственно много человек. Тогда будет бардак, что с программой, что без.

    G>>Не выдумывай. Во многих задачах с одними и теме же данными работает много человек. Большая часть сайтов такова, любые задачи документооборота и многое другое.

    A>Работает в смысле читает или в смысле создаёт и модифицирует?

    В смысле один читает, другой создает, а третий модифицирует.

    A>Для чтения ручное обновление совершенно нормальная ситуация. Вот ты как смотришь что сайт обновился, жмёшь Refresh?

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

    A>Надо различать кеширование объектной модели для создания и модификации объектов и отчёты, которые кешировать стоит крайне редко.

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


    A>Ты в качестве примера привёл Вики. Вики это как бы не типично для ERP/CRM.

    Да ну, а knowelege base на чем делать? Уж не на вордовских файлах.
    Re[79]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 26.04.09 16:45
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Именно это я и назвал "очень серьёзными проблемами".

    G>Это мелочи, по сравнению с синхронизацей реплики, особено без использования како-нибудь Sync Framework.

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

    A>>Для чтения ручное обновление совершенно нормальная ситуация. Вот ты как смотришь что сайт обновился, жмёшь Refresh?

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

    Есть данные только для чтения (на их основе не производится операций), то не надо сохранять ссылочную целостность. Ы?

    A>>Ты в качестве примера привёл Вики. Вики это как бы не типично для ERP/CRM.

    G>Да ну, а knowelege base на чем делать? Уж не на вордовских файлах.

    И где там такая страшная проблема актуальности данных? Ты вроде должен был привести пример, где была бы очень важна актуальность данных. А в примере с KB клиент увидит обновление через час из-за какого-нибудь squid'а.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[80]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 26.04.09 17:04
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Именно это я и назвал "очень серьёзными проблемами".

    G>>Это мелочи, по сравнению с синхронизацей реплики, особено без использования како-нибудь Sync Framework.

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

    Технически это просто делается. А то что надо головой думать — это да.

    A>>>Для чтения ручное обновление совершенно нормальная ситуация. Вот ты как смотришь что сайт обновился, жмёшь Refresh?

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

    A>Есть данные только для чтения (на их основе не производится операций), то не надо сохранять ссылочную целостность. Ы?

    Во, уже лучше.
    А теперь осталось отказаться от мысли что вообще нужны каке-то закешированные объекты для изменения данных и все будет ок.



    A>>>Ты в качестве примера привёл Вики. Вики это как бы не типично для ERP/CRM.

    G>>Да ну, а knowelege base на чем делать? Уж не на вордовских файлах.
    A>И где там такая страшная проблема актуальности данных? Ты вроде должен был привести пример, где была бы очень важна актуальность данных. А в примере с KB клиент увидит обновление через час из-за какого-нибудь squid'а.
    Ну если так рассуждать, тогда все можно.
    На деле уже много раз встречал ситуацию, когда лаг в десять секунд между изменением данных и отображением результата другому пользователю не устраивал зказчика.
    Re[81]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 26.04.09 17:14
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

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

    G>Технически это просто делается. А то что надо головой думать — это да.

    Ну и зачем думать о мелочах, когда можно не думать?

    A>>Есть данные только для чтения (на их основе не производится операций), то не надо сохранять ссылочную целостность. Ы?

    G>А теперь осталось отказаться от мысли что вообще нужны каке-то закешированные объекты для изменения данных и все будет ок.

    А нет, не откажусь

    A>>И где там такая страшная проблема актуальности данных? Ты вроде должен был привести пример, где была бы очень важна актуальность данных. А в примере с KB клиент увидит обновление через час из-за какого-нибудь squid'а.

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

    Любое кеширование, при возможности ручного обновления, не вызовет задержки. А обеспечить синхронное обновление без server push или параноидального client poll вообще нельзя.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[82]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 26.04.09 17:33
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

    G>>Технически это просто делается. А то что надо головой думать — это да.
    A>Ну и зачем думать о мелочах, когда можно не думать?
    Грамотное кеширование — не мелочи.

    A>>>Есть данные только для чтения (на их основе не производится операций), то не надо сохранять ссылочную целостность. Ы?

    G>>А теперь осталось отказаться от мысли что вообще нужны каке-то закешированные объекты для изменения данных и все будет ок.
    A>А нет, не откажусь
    Ну и зря.

    A>>>И где там такая страшная проблема актуальности данных? Ты вроде должен был привести пример, где была бы очень важна актуальность данных. А в примере с KB клиент увидит обновление через час из-за какого-нибудь squid'а.

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

    A>Любое кеширование, при возможности ручного обновления, не вызовет задержки. А обеспечить синхронное обновление без server push или параноидального client poll вообще нельзя.

    А оно и не нужно, нужно чтобы в начале бизнес-транзакции данные были в акуальном состоянии.
    Причем желательно не заставлять пользователя жать кнопку "обновить" и курить пока локальная реплика синхронизируется.
    Re[83]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 26.04.09 17:51
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Ну и зачем думать о мелочах, когда можно не думать?

    G>Грамотное кеширование — не мелочи.

    Оно не мелочи только с твоим подходом, потому что оно не прозрачно. Я его вообще не замечаю. Просто откуда-то взялись данные...
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[84]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 26.04.09 18:33
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Ну и зачем думать о мелочах, когда можно не думать?

    G>>Грамотное кеширование — не мелочи.

    A>Оно не мелочи только с твоим подходом, потому что оно не прозрачно.

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

    A>Я его вообще не замечаю. Просто откуда-то взялись данные...

    при таком подходе быстродействием не пахнет.
    Re[85]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 26.04.09 18:46
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Оно не мелочи только с твоим подходом, потому что оно не прозрачно.

    G>У меня все прозрачно. Для тебя может быть непрозрачно потому что этого не понимаешь.

    Тебе надо думать о кешировании, как минимум о стратегии.

    A>>Я его вообще не замечаю. Просто откуда-то взялись данные...

    G> при таком подходе быстродействием не пахнет.

    Напротив, всё шикарно
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[86]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 26.04.09 19:03
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    A>>>Оно не мелочи только с твоим подходом, потому что оно не прозрачно.

    G>>У меня все прозрачно. Для тебя может быть непрозрачно потому что этого не понимаешь.
    A>Тебе надо думать о кешировании, как минимум о стратегии.

    A>>>Я его вообще не замечаю. Просто откуда-то взялись данные...

    G>> при таком подходе быстродействием не пахнет.
    A>Напротив, всё шикарно
    Ну да, у тебя же каждый пользователь работает только со своим куском.
    Re[32]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.04.09 20:21
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    VD>>Динамическое приведение может и есть, но вот ошибки типов быть не может, так как тип изначально закрытый (известны все вхождения) и можно проверить правильность приведения еще во время компиляции. Более того, сама конструкция match (case и т.п.) предусматривает только перечисление конкретных типов и одного случая в случае если ни один из перечисленных случаев не работает. Так что ошибки быть не может.

    EC>Я именно об этом и толкую.
    EC>Динамическому приведению типа всё равно там делать нечего.

    Это не так. Вариант (в терминах немерла) — это базовый тип имеющий ряд подтипов. Ссылка на какой из подтипов была помещена в переменную можно узнать только в рантайме.

    Просто динамическое приведение типов не имеет никакого отношения к динамической типизации. Это один из видов полиморфизма. Список типов известен в момент компиляции, а конкретный определяется в рантайме. Но весь код статически типизирован. И это главное, так как динамический код от статического как раз и отличается тем, что первый может иметь ошибки типизации в рантайме, и тем, что все типы неизвестны о стадии выполнения.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[30]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 27.04.09 09:19
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    EC>Это всё хорошо, но где при паттерн матчинге происходит динамическое приведение типа?


    В месте определения/сопоставления дискриминатора алгебраического типа. Для того же Nemerle — это динамическая проверка типа.
    Re[32]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 27.04.09 09:21
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    EC>Динамическому приведению типа всё равно там делать нечего.


    Ты случайно не путаешь приведение и преобразование типа?
    Re[31]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 27.04.09 17:01
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    EC>>Это всё хорошо, но где при паттерн матчинге происходит динамическое приведение типа?


    V>В месте определения/сопоставления дискриминатора алгебраического типа. Для того же Nemerle — это динамическая проверка типа.


    Так происходит исключительно потому, что алгебраические типы замапили на классы, которые уже есть у нас нахаляву в CLR.
    С точки зрения системы типов приведений нет — это деталь реализации.
    now playing: Rekorder — Rekorder 9.3
    Re[34]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 27.04.09 18:09
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    EC>В F# сделано аналогично, но это артефакт реализации, такие типы компилятор помечет атрибутом CompilationMapping(SourceConstructFlags.SumType), чтобы отличать их от обычных.

    EC>Сделано так, думаю, исключительно исходя из простоты реализации, а не потому, что нам для реализации ПМ нужны динамические приведения типа.
    EC>В OCaml или Haskell уверен сделано совсем иначе.

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

    Другое дело, что само определение может сводится к банальной проверке некоторой целочисленной переменной которая точно имеется у всех АлгТД.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[35]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 27.04.09 20:06
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    EC>>В F# сделано аналогично, но это артефакт реализации, такие типы компилятор помечет атрибутом CompilationMapping(SourceConstructFlags.SumType), чтобы отличать их от обычных.

    EC>>Сделано так, думаю, исключительно исходя из простоты реализации, а не потому, что нам для реализации ПМ нужны динамические приведения типа.
    EC>>В OCaml или Haskell уверен сделано совсем иначе.

    VD>А я уверен в обратно. Тип определяет то, что можно сделать с его экземпляром. В рантайме мы можем получить разные экземпляры разных типов. Стало быть не зная того, что за тип имеется в наличии нельзя с ним работать.

    По поводу выделенного.
    Есть определение:
    type expr = Plus of expr * expr
            | Minus of expr * expr
            | Times of expr * expr
            | Divide of expr * expr
            | Value of string
            ;;

    и выражение:
    let rec to_string e =
      match e with
        Plus (left, right)   -> "(" ^ (to_string left) ^ " + " ^ (to_string right) ^ ")"
      | Minus (left, right)  -> "(" ^ (to_string left) ^ " - " ^ (to_string right) ^ ")"
      | Times (left, right)  -> "(" ^ (to_string left) ^ " * " ^ (to_string right) ^ ")"
      | Divide (left, right) -> "(" ^ (to_string left) ^ " / " ^ (to_string right) ^ ")"
      | Value v -> v
      ;;

    У меня к тебе 2 вопроса:
    1. сколько здесть опеделено алгебраических типов данных?
    2. где здесь разные экземпляры разных типов?

    По мне так здесть все типы известны статически и необходимости в динамическом приведении типа нет совсем.
    now playing: The Future Sound Of London — Globular (Longform)
    Re[32]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 28.04.09 00:38
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    V>>В месте определения/сопоставления дискриминатора алгебраического типа. Для того же Nemerle — это динамическая проверка типа.


    EC>Так происходит исключительно потому, что алгебраические типы замапили на классы, которые уже есть у нас нахаляву в CLR.

    EC>С точки зрения системы типов приведений нет — это деталь реализации.

    В твоем хаскеле точно такая же деталь: динамически проверяется дискриминатор объединения, который определяет тип содержащегося в нем значения. Для CLR дискриминатором выступает хендл типа, как говорится — найдите отличия.

    Динамическое приведение типа — суть рантайм тест значения на соответствие типу. Отличие в CLR лишь в том, что в этой ОО-платформе можно приводить так же к базовому типу или интерфейсу.
    Re[33]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 28.04.09 04:19
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>>>В месте определения/сопоставления дискриминатора алгебраического типа. Для того же Nemerle — это динамическая проверка типа.


    EC>>Так происходит исключительно потому, что алгебраические типы замапили на классы, которые уже есть у нас нахаляву в CLR.

    EC>>С точки зрения системы типов приведений нет — это деталь реализации.

    V>В твоем хаскеле точно такая же деталь: динамически проверяется дискриминатор объединения, который определяет тип содержащегося в нем значения. Для CLR дискриминатором выступает хендл типа, как говорится — найдите отличия.


    V>Динамическое приведение типа — суть рантайм тест значения на соответствие типу. Отличие в CLR лишь в том, что в этой ОО-платформе можно приводить так же к базовому типу или интерфейсу.


    Зачем выполнять рантайм тест значения на соответствие типу, если тип известен на этапе компиляции?
    Вот есть у тебя тип
    data Maybe a = Nothing | Just a

    в функцию приходит значение этого типа и мы по нему матчимся.
    Nothing и Just a имеют один и тот же тип и это известно на этапе компиляции.
    Мы матчимся по разным значениям одного типа.
    now playing: Andreas Henneberg — Whos Pedo Bear
    Re[62]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 28.04.09 05:22
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Той которую видишь. Зайди на сайт RSDN.ru, открой в дереве слева список форумов, щёлкни на форуме, шёлкни вверху на сообщении в форуме. Сверху будет адрес — rsdn.ru. Это про фреймы. Про AJAX — в GoogleMaps, аналогичная ситуация. Прокручиваешь карту, масштабируешь, а адрес не меняется.
    Рома, сходи на wikimapia.org.

    A>Более предметно, практически все до кого дошёл прогресс ходят с покетами. То есть ты конечно можешь смотреть в окно на красивые, не тронутые человеком, пейзажи Мухосранска, но с покетами сейчас ходят представители практически всех родов деятельности: менеджеры, почтальоны, официанты, полицейские, лекторы, студенты и т.д. Если этого где-то ещё нет, то это вопрос отставания от прогресса, а не отсутствия необходимости.

    И? Какие проблемы с интернетом у пользователей покетов?

    A>ЛОЛ. Вообще-то тут обсуждалась необходимость постоянного соединения, а не локальной реплики. Надо не только писать, но и читать иногда.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[68]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 28.04.09 05:40
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Не говори глупости, если не разбираешься в предметной области.

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


    A>Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11.

    Это каким таким образом себестоимость поменялась задним числом?
    A>После начисления всех скидок конечная цена стала 10.5. Компании выгоднее продать по 11 оформив 0 прибыли, чем продать по 10.5 и заплатить налог за продажу ниже себестоимости.
    Да ладно?
    А по-моему выгоднее подкрутить себестоимость нужным образом в конце отчетного периода.

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

    Потому, Рома, что такого примера в природе не бывает. У тебя всё — прямо фильмы Кустурицы.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[34]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 28.04.09 06:51
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    EC>Зачем выполнять рантайм тест значения на соответствие типу, если тип известен на этапе компиляции?


    Не известен по определению (определению алгебраических типов). Хотя нет, будет известен достоверно, если в алгебраическую группу входит всего 1 тип.

    EC>Вот есть у тебя тип

    EC>
    EC>data Maybe a = Nothing | Just a
    EC>

    EC>в функцию приходит значение этого типа и мы по нему матчимся.
    EC>Мы матчимся по разным значениям одного типа.

    В функцию приходит значение размеченного объединения, которое суть пара: разметка + значение соответсвующего разметке типа. Объекты CLR представлены в куче аналогично, кстати. И насчёт "одного типа"... в случае алгебраических типов мы имеем 2 типа минимум: тип группы и хоть один тип участника группы.

    ------------
    Не хочешь посмотреть на описание размеченных объединений в CORBA IDL и заодно посмотреть, что генерируют компиляторы на эти описания? А потом мы возьмем эти 3 примера: IDL, CLR и Хаскель, и посмотрим, что там происходит в процессе динамического определения типа.
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[35]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 28.04.09 07:25
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    EC>>Мы матчимся по разным значениям одного типа.


    V>В функцию приходит значение размеченного объединения, которое суть пара: разметка + значение соответсвующего разметке типа. Объекты CLR представлены в куче аналогично, кстати. И насчёт "одного типа"... в случае алгебраических типов мы имеем 2 типа минимум: тип группы и хоть один тип участника группы.


    Объясни мне тогда поведение GHCi:

    *Main> :i MyNum
    data MyNum = One | Two
    *Main> :t One
    One :: MyNum
    *Main> :t Two
    Two :: MyNum



    V>Не хочешь посмотреть на описание размеченных объединений в CORBA IDL и заодно посмотреть, что генерируют компиляторы на эти описания? А потом мы возьмем эти 3 примера: IDL, CLR и Хаскель, и посмотрим, что там происходит в процессе динамического определения типа.

    Хочу посмотреть, покажи.
    Re[63]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 28.04.09 09:02
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>Более предметно, практически все до кого дошёл прогресс ходят с покетами. То есть ты конечно можешь смотреть в окно на красивые, не тронутые человеком, пейзажи Мухосранска, но с покетами сейчас ходят представители практически всех родов деятельности: менеджеры, почтальоны, официанты, полицейские, лекторы, студенты и т.д. Если этого где-то ещё нет, то это вопрос отставания от прогресса, а не отсутствия необходимости.

    S>И? Какие проблемы с интернетом у пользователей покетов?

    Нестабильность соединения.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[69]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 28.04.09 09:06
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>Объясняю ещё раз на пальцах. Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11.

    S>Это каким таким образом себестоимость поменялась задним числом?

    В 9:00 агент сделал синхронизацию в офисе и выехал на маршрут, в 10:00 приехала партия товара по более высокой цене, чем раньше , в 11:00 агент входит к клиенту.

    A>>После начисления всех скидок конечная цена стала 10.5. Компании выгоднее продать по 11 оформив 0 прибыли, чем продать по 10.5 и заплатить налог за продажу ниже себестоимости.

    S>А по-моему выгоднее подкрутить себестоимость нужным образом в конце отчетного периода.

    Это называется финансовая махинация.

    S>Потому, Рома, что такого примера в природе не бывает. У тебя всё — прямо фильмы Кустурицы.


    Антон это, во-первых, реальная ситуация, а, во-вторых, она произошла не у меня. Уж как-нибудь смирись с этим.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[70]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 28.04.09 09:28
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>В 9:00 агент сделал синхронизацию в офисе и выехал на маршрут, в 10:00 приехала партия товара по более высокой цене, чем раньше , в 11:00 агент входит к клиенту.

    Ой, как интересно. А вы себестоимость по какой модели учитываете — FIFO, LIFO, средневзвешенной или как?
    Это вопрос номер один.
    Вопрос номер два: сколько раз в день может измениться цена на товар?

    Ну, то есть все конечно понимают, что у вас там есть особенности ценообразования, но вообще говоря всем на них накласть. Если ты по телефону предложил клиенту по 5 за штуку, а через час приехал для подписания и сказал "ой, у нас теперь цена 5.21 за штуку", тебя пошлют на все четыре стороны. Это не биржа. Оффер должен иметь ненулевой validity period.

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

    A>Это называется финансовая махинация.

    Ничего подобного. Это называется "оптимизация налогообложения", и ничего с ней сделать нельзя.

    A>Антон это, во-первых, реальная ситуация, а, во-вторых, она произошла не у меня. Уж как-нибудь смирись с этим.

    Да мне-то всё равно, Рома. Возможно, ситуация и выглядела похожим образом. Но технические выводы ты сделал из нее явно поспешно.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[71]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 28.04.09 09:39
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>В 9:00 агент сделал синхронизацию в офисе и выехал на маршрут, в 10:00 приехала партия товара по более высокой цене, чем раньше , в 11:00 агент входит к клиенту.

    S>Ой, как интересно. А вы себестоимость по какой модели учитываете — FIFO, LIFO, средневзвешенной или как?

    Налоговая требует партионный учёт, так что FIFO ил LIFO. На практике FIFO. Средневзвешенная система тоже используется для анализа.

    S>Вопрос номер два: сколько раз в день может измениться цена на товар?


    Базовая цена меняется редко. Конечная цена на товар для конкретного клиента вполне может поменяться в течение дня.

    S>Ну, то есть все конечно понимают, что у вас там есть особенности ценообразования, но вообще говоря всем на них накласть. Если ты по телефону предложил клиенту по 5 за штуку, а через час приехал для подписания и сказал "ой, у нас теперь цена 5.21 за штуку", тебя пошлют на все четыре стороны. Это не биржа. Оффер должен иметь ненулевой validity period.


    Базовая цена может расти, но её не меняют в середине рабочего дня. Набор скидок применяемых к конкретному клиенту меняют, но агенту не сложно объяснить клиенту почему это произошло. Цена при этом обычно падает.

    S>Еще интереснее, как здесь поможет локальная реплика. В случае тонкого клиента агент отправит заказ через сервер, и тот проапдейтит цены автоматически.


    В данной ветке обсуждалась не реплика.

    A>>Это называется финансовая махинация.

    S>Ничего подобного. Это называется "оптимизация налогообложения", и ничего с ней сделать нельзя.

    Плати штрафы за такую "оптимизацию"
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[72]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 28.04.09 10:20
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Налоговая требует партионный учёт, так что FIFO ил LIFO. На практике FIFO. Средневзвешенная система тоже используется для анализа.

    Ну, мы же не про анализ говорим, а про ценообразование. Так? Далее, если FIFO, то сценарий, о котором ты рассказываешь, произойти никак не может. С утра на складе было 100шт по 10 рублей. Ты приехал продавать 80, тут поступили еще 100 по цене 20 рублей — цена никак не станет 15 рублей. Никакое налогообложение этого не потребует — это бред.

    A>Базовая цена меняется редко. Конечная цена на товар для конкретного клиента вполне может поменяться в течение дня.

    Что такое "базовая цена"? Клиенту всё равно, что у вас там называется "базовой" ценой, а что — сборами аэропорта. Для него важна только конечная цена, и совершенно непонятно, почему он должен разбираться в тонкостях ваших поставок.

    A>Базовая цена может расти, но её не меняют в середине рабочего дня.

    A>Набор скидок применяемых к конкретному клиенту меняют, но агенту не сложно объяснить клиенту почему это произошло. Цена при этом обычно падает.
    Ты сам себе противоречишь. Только что ты рассказывал про то, что

    Агент пришёл к клиенту с покетом продать товар. Утром себестоимость была 10, днём, когда агент пришёл к клиету — 11. После начисления всех скидок конечная цена стала 10.5. Компании выгоднее продать по 11 оформив 0 прибыли, чем продать по 10.5 и заплатить налог за продажу ниже себестоимости.

    Твой пример? Где тут "базовая", и где "конечная"? Где тут "обычно падает"? Зачем знать себестоимость днём?

    A>Плати штрафы за такую "оптимизацию"

    Какие штрафы? За что именно? Рома, ты так загибаешь пальцы про свой опыт в учетных системах, что мне странно читать такие высказывания. Бухгалтерия по природе своей никогда не работает в реальном времени. Она всегда работает задним числом. Есть зарегулированные отрасли, как, к примеру, фармацевтика — и у нас вполне реально купить в аптеке две коробки одного и того же лекарства по разной цене — потому что у них жестко ограничены наценки, и себестоимость полностью определяет цену.
    Но во всех остальных случаях рулит простое ценообразование, где цена является предметом соглашения сторон, а не результатом какой-то формулы.
    Более того, документы оформляются более-менее задним числом, чтобы получить хоть какую-то целостность.
    Потому, в частности, что многие компании торгуют с отсрочкой платежа, и у товара на складе вообще нет себестоимости даже после того, как он продал. Какие нахрен тут формулы, если ты продал товар в июне, а рассчитываешься за него в августе, по цене, которую его хозяин определил только в июле?
    Поэтому бухгалтерская себестоимость возникает только в момент подготовки квартальной отчетности. И тут у бухгалтерии есть масса способов подогнать результаты к требуемым, оставаясь на все 100% в рамках закона.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[37]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 28.04.09 16:27
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>В этом примере One, Two — конструкторы алгебраического типа. Каждый из них конструирует обобщенный тип MyNum, заворачивая в него пустой тупл.

    Какой ещё обобщённый тип? Т.е. там есть ещё и его конкретизации? GHCi считает иначе:

    *Main> :t One
    One :: MyNum
    *Main> :t Two
    Two :: MyNum

    По его мнению One и Two имеют одинаковый тип — MyNum, что можно увидеть парой строк выше.
    Нет там больше никаких других типов.
    V>Случай вырожденный, размеченное объединение для всех своих значений состоит из собс-но кода разметки и ничего более, т.е. такое использование близко к enum из C++ или C#.
    Если добавить аргументов конструкторам значений, то с точки зрения типов ничего не изменится.

    V>Да, алгебраические типы — очень удобная модель как раз для тех задач, где мы сегодня используем динамическое приведение в языках без оного. Внутренний механизм идентичен (даже для Хаскеля), но степень контроля компилятором значительно выше.

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

    Надо бы это обсуждение в ДП снести — может хардкорные функциональщики подтянутся.
    now playing: Gui Boratto — Beluga
    Re[73]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 28.04.09 18:46
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Ну, мы же не про анализ говорим, а про ценообразование. Так? Далее, если FIFO, то сценарий, о котором ты рассказываешь, произойти никак не может. С утра на складе было 100шт по 10 рублей. Ты приехал продавать 80, тут поступили еще 100 по цене 20 рублей — цена никак не станет 15 рублей. Никакое налогообложение этого не потребует — это бред.


    Агент берёт заказ. Товар будет клиенту доставлен самое скорое на следующий день.

    S>Что такое "базовая цена"? Клиенту всё равно, что у вас там называется "базовой" ценой, а что — сборами аэропорта. Для него важна только конечная цена, и совершенно непонятно, почему он должен разбираться в тонкостях ваших поставок.


    Глупости говоришь, конечно должен. Базовая цена — это цена одной штуки если покупать одну штуку. Если покупать много одной марки, то получаешь скидку на позицию. Если покупаешь просто много, то общую скидку. Если покупаешь весь ассортимент на большую сумму, то партнёрскую скидку в следующем месяце. Если платишь наличными или переводом, но сразу, то скидку за отсутствие кредита. Прошлые просроченные кредиты могут полностью или частично всё сказанное отменять.

    A>>Плати штрафы за такую "оптимизацию"

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

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

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


    Цена в данном случае фиксирована. Плавает только себестоимость.

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


    Скажем так, я точно знаю, что отставание бухгалтерии от реальности более, чем на неделю — это очень серьёзная проблема.

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


    У нас происходит резервирование товара. Нельзя продать то, чего нет.

    S>Поэтому бухгалтерская себестоимость возникает только в момент подготовки квартальной отчетности. И тут у бухгалтерии есть масса способов подогнать результаты к требуемым, оставаясь на все 100% в рамках закона.


    Бухгалтерские документы вообще-то надо раз в месяц сдавать У нас, по крайней мере.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[74]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 28.04.09 20:51
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    S>>Ну, мы же не про анализ говорим, а про ценообразование. Так? Далее, если FIFO, то сценарий, о котором ты рассказываешь, произойти никак не может. С утра на складе было 100шт по 10 рублей. Ты приехал продавать 80, тут поступили еще 100 по цене 20 рублей — цена никак не станет 15 рублей. Никакое налогообложение этого не потребует — это бред.


    A>Агент берёт заказ. Товар будет клиенту доставлен самое скорое на следующий день.

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

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

    A>Скажем так, я точно знаю, что отставание бухгалтерии от реальности более, чем на неделю — это очень серьёзная проблема.
    Неправда. Товар может валяться на складе неоприходованным много вермени времени. Вот с налом действительно могут быть проблемы.
    Обычно суетиться все начинают при наступлении конца отчетного периода.

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

    A>У нас происходит резервирование товара. Нельзя продать то, чего нет.
    Резвервирование (как часть складского учета) никак не связано с бухгалтерским учетом.

    S>>Поэтому бухгалтерская себестоимость возникает только в момент подготовки квартальной отчетности. И тут у бухгалтерии есть масса способов подогнать результаты к требуемым, оставаясь на все 100% в рамках закона.


    A>Бухгалтерские документы вообще-то надо раз в месяц сдавать У нас, по крайней мере.
    Re[74]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 29.04.09 04:38
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Глупости говоришь, конечно должен.

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

    A>Я имею дело как раз с зарегулированной областью, но несколько иначе. Плавает себестоимость, цену мы менять не имеем права. Это требование производителя.

    A>Цена в данном случае фиксирована. Плавает только себестоимость.
    Рома, тогда о чём мы вообще говорим? Цена — фиксирована; себестоимость агента совершенно не полнует. Она не нужна для того, чтобы оформить заказ.

    A>У нас происходит резервирование товара. Нельзя продать то, чего нет.

    Дело не в резервировании. А в том, что товар идет на склад к дистрибьютору в счёт будущих оплат. У него нет себестоимости, потому что она определится потом — в тот момент, когда собственно произойдет оплата. А оплата происходит после реализации, т.к. свободных средств у нормального дистрибьютора нет.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[38]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 29.04.09 05:23
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

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


    V>>В этом примере One, Two — конструкторы алгебраического типа. Каждый из них конструирует обобщенный тип MyNum, заворачивая в него пустой тупл.

    EC>Какой ещё обобщённый тип? Т.е. там есть ещё и его конкретизации? GHCi считает иначе:
    EC>

    EC>*Main> :t One
    EC>One :: MyNum
    EC>*Main> :t Two
    EC>Two :: MyNum

    EC>По его мнению One и Two имеют одинаковый тип — MyNum, что можно увидеть парой строк выше.

    Они имеют тип ()->MyEnum. Это тип ф-ии, возвращающей значение MyEnum. Конструкторы — это всегда ф-ии во всех языках.
    Зря ты рассматриваешь вырожденный случай, добавь туда параметр:
    data MyNum a = One | Two | Three a

    И посмотри, что тебе выдаст Three.

    Обобщенный тип для алгебраического типа — это не аналог параметризуемого обобщенного типа из С++, это аналог union из того же С++. Это некий bag, куда заворачиваются другие типы, составляющие группу.

    В общем, типы, входящие в группу, в общем случае не приводимы один к одному, поэтому нужен механизм, чтобы в одном аргументе передавать значения разных типов. Этот механизм — алгебраические типы. Типы заворачиваются в discriminated union.


    EC>Если добавить аргументов конструкторам значений, то с точки зрения типов ничего не изменится.


    Ты бы сначала добавил.

    V>>Да, алгебраические типы — очень удобная модель как раз для тех задач, где мы сегодня используем динамическое приведение в языках без оного. Внутренний механизм идентичен (даже для Хаскеля), но степень контроля компилятором значительно выше.

    EC>Система типов и внутренний механизм её реализующий — это как бы очень разные вещи.

    Фиг там. Есть некая вычислительная модель, напр. модель алгебраических типов. И как она реализуется я показывал на листинге результата компиляции IDL. Вот конкретика не важна, а суть должна соответствовать вычислительной модели.

    EC>Механизм знать полезно, но то, что он реализует важнее.


    В случае алгебраических типов он 1-в-1 реализует "то, что он реализует".

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


    А я не понимаю твоего упорства — всё более чем прозрачно.

    И как раз об абстракции и говорил в первом утверждении, что полиморфизм по алгебраическим типам — это классика динамической типизации. Могу усилить — это наилучший на сегодня способ использования динамической типизации.
    Re[39]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 29.04.09 05:55
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Они имеют тип ()->MyEnum. Это тип ф-ии, возвращающей значение MyEnum.

    Этот тезис неплохо бы подтвердить сессией GHCi или что у тебя там установлено.
    Ничто не подтверждает, что тип ()->MyEnum.

    V>Зря ты рассматриваешь вырожденный случай, добавь туда параметр:

    V>
    V>data MyNum a = One | Two | Three a
    V>

    V>И посмотри, что тебе выдаст Three.
    Смотри ниже.

    EC>>Если добавить аргументов конструкторам значений, то с точки зрения типов ничего не изменится.


    V>Ты бы сначала добавил.

    Так добавил, результат тот же, тип всё равно один:

    *Main> :i MyNum
    data MyNum = One Int | Two String
    *Main> :t One 1
    One 1 :: MyNum
    *Main> :t Two "2"
    Two "2" :: MyNum


    V>>>Да, алгебраические типы — очень удобная модель как раз для тех задач, где мы сегодня используем динамическое приведение в языках без оного. Внутренний механизм идентичен (даже для Хаскеля), но степень контроля компилятором значительно выше.

    EC>>Система типов и внутренний механизм её реализующий — это как бы очень разные вещи.

    V>Фиг там. Есть некая вычислительная модель, напр. модель алгебраических типов. И как она реализуется я показывал на листинге результата компиляции IDL. Вот конкретика не важна, а суть должна соответствовать вычислительной модели.


    EC>>Механизм знать полезно, но то, что он реализует важнее.


    V>В случае алгебраических типов он 1-в-1 реализует "то, что он реализует".


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


    V>А я не понимаю твоего упорства — всё более чем прозрачно.


    V>И как раз об абстракции и говорил в первом утверждении, что полиморфизм по алгебраическим типам — это классика динамической типизации. Могу усилить — это наилучший на сегодня способ использования динамической типизации.

    Давай ты приведёшь хоть какую-то иллюстрацию, только не умозрительную, а вывод интерпретатора или что-то в этом роде из которой будет видно, что в рассматриваемом наме примере участвуют хотя бы 2 хаскельных типа.
    А то тип вроде один, а ты говоришь оприведении. К какому типу мы приводим, если он один?
    Re[75]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 29.04.09 05:59
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Агент берёт заказ. Товар будет клиенту доставлен самое скорое на следующий день.

    G>Приходит к клиенту и называет большую цену, чем оговорено? Угадайте куда он пойдет.
    G>Сколько видел всегда накладные и счета печатались по времени отправки.

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

    G>Товар может валяться на складе неоприходованным много времени.


    Если у тебя товар на складе неоприходован, у тебя проблемы с бизнес-процессами.

    G>Обычно суетиться все начинают при наступлении конца отчетного периода.


    В быдлофирмах может и так. У нас товар оприходуется в день прибытия приямо при разгрузке.

    A>>У нас происходит резервирование товара. Нельзя продать то, чего нет.

    G>Резвервирование (как часть складского учета) никак не связано с бухгалтерским учетом.

    Я просто объяснил почему невозможен описанный тобой сценарий.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[75]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 29.04.09 06:02
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

    S>Это всё правильно. Но заметь — в этом ценообразовании себестоимость никакой роли не играет. И не должна играть, потому что клиенту пофиг, что вы там по чём купили.

    Да, но во время промо-акций цена может упасть ниже себестоимости. Ы?

    A>>Цена в данном случае фиксирована. Плавает только себестоимость.

    S>Рома, тогда о чём мы вообще говорим? Цена — фиксирована; себестоимость агента совершенно не полнует. Она не нужна для того, чтобы оформить заказ.

    Нужна. Нельзя продавать ниже себестоимости, это другие налоги.

    A>>У нас происходит резервирование товара. Нельзя продать то, чего нет.

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

    Это вообще-то обычный кредит и закупочная цена, а значит и себестоимость, хорошо известна заранее. по твоему люди берут товар не зная сколько должны будут за него заплатить?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[76]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 29.04.09 06:22
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Нужна. Нельзя продавать ниже себестоимости, это другие налоги.

    Ну и что? Если это невыгодно — нехрен делать такие промо-акции. В чем проблема-то? Что агент должен сказать "ой, я вас по телефону обманул — не можем дать 20%, только 14%, а то нам налоги платить"? Это проблемы продавца и его ценообразования.

    A>Это вообще-то обычный кредит и закупочная цена, а значит и себестоимость, хорошо известна заранее.

    Ну конечно же неизвестна.
    A>по твоему люди берут товар не зная сколько должны будут за него заплатить?
    Естественно. Добро пожаловать в реальный мир. Ну то есть условия известны, но их в себестоимость не впишешь. Потому, к примеру, что цена рассчитывается от курса евродоллара на день платежа, и есть заранее определенная шкала наценок в зависимости от срока оплаты. А срок оплаты заранее неизвестен — сколько продадим в июне, столько и оплатим в июле. Остальной товар будет лежать на складе и его "себестоимость" волшебным образом увеличится. Ну, или уменьшится, если курс валюты поплывёт.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[40]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 29.04.09 06:28
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    V>>Ты бы сначала добавил.

    EC>Так добавил, результат тот же, тип всё равно один:
    EC>

    EC>*Main> :i MyNum
    EC>data MyNum = One Int | Two String
    EC>*Main> :t One 1
    EC>One 1 :: MyNum
    EC>*Main> :t Two "2"
    EC>Two "2" :: MyNum


    Извини, коллега, но у тебя полная каша в голове — ты же смотришь тип результата, а не тип контруктора. Вот в HUGS:

    Main> :t Three
    Three :: a -> MyNum a


    Короче, добавь еще одну мелочь — это определи ф-ию без параметров mkOne:
    data MyNum a = One | Two | Three a
    mkOne = One

    И найди потом отличия м/у mkOne и One. Как найдешь — скажешь.

    EC>А то тип вроде один, а ты говоришь оприведении. К какому типу мы приводим, если он один?


    Там я тебе ссылку дал в предыдущем сообщении. Не хочешь пройтись по ней?
    Re[77]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 29.04.09 07:16
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Ну и что? Если это невыгодно — нехрен делать такие промо-акции. В чем проблема-то? Что агент должен сказать "ой, я вас по телефону обманул — не можем дать 20%, только 14%, а то нам налоги платить"? Это проблемы продавца и его ценообразования.


    Антон, причём тут телефон? Агент лично приезжает.

    A>>Это вообще-то обычный кредит и закупочная цена, а значит и себестоимость, хорошо известна заранее.

    S>Ну конечно же неизвестна.



    A>>по твоему люди берут товар не зная сколько должны будут за него заплатить?

    S>Естественно. Добро пожаловать в реальный мир. Ну то есть условия известны, но их в себестоимость не впишешь. Потому, к примеру, что цена рассчитывается от курса евродоллара на день платежа, и есть заранее определенная шкала наценок в зависимости от срока оплаты.

    Что мешает считать себестоимость в евродолларах, кроме религии, конечно?

    S>А срок оплаты заранее неизвестен — сколько продадим в июне, столько и оплатим в июле.


    Это так не работает.

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


    Ну прям страна Оз
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[76]: Проблемы организации OR-мапинга
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 29.04.09 07:54
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Нужна. Нельзя продавать ниже себестоимости, это другие налоги.

    Вот интересно, у вас налоговая как отслеживает продажи ниже себестоимости?
    Отслеживает каждую проводку, или же ориентируется на бухгалтерскую отчетнось, где обычно отсутсвуют данные по аналитике.
    Да и просчитать данные они должны по первичным документам, что весьма проблематично.
    Если ты продал небольшую долю экземляров одного класса (тьфу товара) ниже себестоимости, это очень тяжело отследить.
    (хотя брак, или залежалый товар вполне естественно нужно продавать. Кстати на западе вроде как существует понятие рыночной стоимости активов).
    Да и кроме того, наценка должна учитывать издержки, что бы получить общую прибыль. Я это всё к тому, что Просто нужно учитывать и такую состовляющую, как трудоемкость
    отыскания нарушения и цену штрафа за эти нарушения.
    и солнце б утром не вставало, когда бы не было меня
    Re[78]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 29.04.09 08:03
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Антон, причём тут телефон? Агент лично приезжает.
    И как это помогает ему в ситуации, когда промо-акция отменяется из-за того, что в процессе поездки прыгнула себестоимость? Клиент видит табличку с соответствием "объем-скидка", но ему говорят "ой, нет, пятая колонка сегодня не работает"?

    A>Что мешает считать себестоимость в евродолларах, кроме религии, конечно?

    Ты о чём? В бухгалтерском учете никаких евродолларов нет и быть не может. Он же идет в налоговую — поэтому там только рубли.
    Именно поэтому бухгалтерии в бизнесе отведена подчиненная роль. А вопросами реальной себестоимости и ценообразования занимается финансовый учет. И это его задача, чтобы бизнес был прибыльным не на бумаге, а в реальности. Управление себестоимостью — давно освоенная область в бухгалтерии. Ты бы, Рома, вместо того, чтобы хвастаться своим опытом ажно в 1 год, лучше бы послушал тех, кто учетные системы проектировал и внедрял с 1991 года.

    A>Это так не работает.

    Рома, это прекрасно работает. Все основные дистрибуторские сети живут именно так. Никто не работает по предоплате уже много-много лет — конкуренты порвут.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[79]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 29.04.09 08:29
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Клиент видит табличку с соответствием "объем-скидка", но ему говорят "ой, нет, пятая колонка сегодня не работает"?


    Клиент видит её где? По-моему ты вообще не представляешь себе процесса оптовой торговли.

    S>Именно поэтому бухгалтерии в бизнесе отведена подчиненная роль. А вопросами реальной себестоимости и ценообразования занимается финансовый учет. И это его задача, чтобы бизнес был прибыльным не на бумаге, а в реальности. Управление себестоимостью — давно освоенная область в бухгалтерии. Ты бы, Рома, вместо того, чтобы хвастаться своим опытом ажно в 1 год, лучше бы послушал тех, кто учетные системы проектировал и внедрял с 1991 года.


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

    A>>Это так не работает.

    S>Все основные дистрибуторские сети живут именно так. Никто не работает по предоплате уже много-много лет — конкуренты порвут.

    Антон, по моему ты не понимаешь, что если покупаешь в долларах, то курс доллара к местной валюте не влияет на цену.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[80]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 29.04.09 09:21
    Оценка:
    Здравствуйте, adontz, Вы писали:
    A>Клиент видит её где? По-моему ты вообще не представляешь себе процесса оптовой торговли.
    Смотря какая модель. При модели с открытой ценой клиенту дают табличку соответствия цена — скидка. При модели с закрытой ценой клиент отправляет заявку и она динамически прайсится в "чёрном ящике". Первая модель работает и в offline, вторая требует соединения — потому что в общем случае чёрный ящик с собой не утащишь.

    A>Антон, я очень рад за тебя с 1991 года, но достаточно странно видеть, твои теоретические аргументы, на фоне реальных проблем возникающих в реальной жизни.

    Рома, пока что мы говорим не о "проблемах, возникающих в реальной жизни", а о твоём восприятии того, как эти проблемы ложатся на софт. У меня первые годы оно тоже было достаточно далеко от реальности.

    S>>Все основные дистрибуторские сети живут именно так. Никто не работает по предоплате уже много-много лет — конкуренты порвут.


    A>Антон, по моему ты не понимаешь, что если покупаешь в долларах, то курс доллара к местной валюте не влияет на цену.

    Рома, по-моему ты вообще не понимаешь, о чём ты говоришь. У нас в стране торговля разрешена только в локальной валюте очень давно (как и во всех развитых странах). А вот покупать товар часто приходится в иностранной валюте — так получилось, что какой-нибудь Bosch за рубли ничего не продает.
    Даже если прайс-лист у тебя размечен в "у.е.", по документам все платежи проходят исключительно в рублях. И себестоимость перепродаваемого товара определяется, в том числе, и курсом валюты на дату платежа поставщику. Эта дата при отсрочке платежа всегда идет после даты оплаты клиентом. Рома, это азы. Поговори с каким-нибудь главбухом торговой компании.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[42]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 29.04.09 09:30
    Оценка:
    Здравствуйте, EvilChild, Вы писали:


    EC>Объясни мне какое значение имеют сигнатуры конструкторов в контексте нашего обсуждения.


    Ты пытался не верить, что это ф-ии.

    EC>Важны типы значения, которые они конструируют.

    EC>Мой поинт в том, что конструкторы конструируют значения одного типа.
    EC>Ты с этим согласен?

    по кругу: http://www.rsdn.ru/forum/message/3374217.1.aspx
    Автор: vdimas
    Дата: 28.04.09

    или даже на несколько сообщений выше.
    Уже забыл, с чем ты изначально спорил?
    Re[81]: Проблемы организации OR-мапинга
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 29.04.09 09:31
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    A>>Клиент видит её где? По-моему ты вообще не представляешь себе процесса оптовой торговли.

    S>Смотря какая модель. При модели с открытой ценой клиенту дают табличку соответствия цена — скидка.

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

    S>Рома, пока что мы говорим не о "проблемах, возникающих в реальной жизни", а о твоём восприятии того, как эти проблемы ложатся на софт. У меня первые годы оно тоже было достаточно далеко от реальности.


    Увы и ах, восприятие не моё.

    A>>Антон, по моему ты не понимаешь, что если покупаешь в долларах, то курс доллара к местной валюте не влияет на цену.

    S>Рома, по-моему ты вообще не понимаешь, о чём ты говоришь. У нас в стране торговля разрешена только в локальной валюте очень давно (как и во всех развитых странах). А вот покупать товар часто приходится в иностранной валюте — так получилось, что какой-нибудь Bosch за рубли ничего не продает.

    Когда товар приезжает ко мне, я точно знаю сколько он мне обошёлся в долларах, потому что за перевозку и растаможку заплачено, а других расходов нет (расходы на хранение не привязываются к конкретному товару). Эта цена в долларах не меняется. Как я продаю товар не важно, его себестоимость в долларах не меняется. Меняется только оборот и, соответственно, прибыль в долларах.

    S>Даже если прайс-лист у тебя размечен в "у.е.", по документам все платежи проходят исключительно в рублях. И себестоимость перепродаваемого товара определяется, в том числе, и курсом валюты на дату платежа поставщику. Эта дата при отсрочке платежа всегда идет после даты оплаты клиентом. Рома, это азы. Поговори с каким-нибудь главбухом торговой компании.


    Это если всё считать в рублях, то есть считать рубль валютой, к которой надо всё приводить. Смени систему координат
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[82]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 29.04.09 09:56
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Когда товар приезжает ко мне, я точно знаю сколько он мне обошёлся в долларах, потому что за перевозку и растаможку заплачено, а других расходов нет (расходы на хранение не привязываются к конкретному товару). Эта цена в долларах не меняется. Как я продаю товар не важно, его себестоимость в долларах не меняется. Меняется только оборот и, соответственно, прибыль в долларах.

    Правда что ли? А ничего, что товар тебе привезли бесплатно — ты еще не заплатил поставщику. Заплатишь ты только тогда, когда товар будет реализован.
    И только в этот момент у товара появится себестоимость. В долларах ее, как и прибыли, быть не может — я тебе уже трижды повторил, что учёт разрешен исключительно в рублях. Рубли будут определены из курса доллара на дату конвертации, а также из цены поставщика, которая зависит от разницы между датой поставки и датой оплаты.

    A>Это если всё считать в рублях, то есть считать рубль валютой, к которой надо всё приводить. Смени систему координат

    Даже если нет конверсии валют, то при отсрочке платежа себестоимость зависит от даты оплаты.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[82]: Проблемы организации OR-мапинга
    От: gandjustas Россия http://blog.gandjustas.ru/
    Дата: 29.04.09 10:24
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Это если всё считать в рублях, то есть считать рубль валютой, к которой надо всё приводить. Смени систему координат


    Это вообще-то правило бухгалтерского учета. В России так, во многих других странах учет ведется в национальной валюте.
    Re[43]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 29.04.09 13:02
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    EC>>Важны типы значения, которые они конструируют.

    EC>>Мой поинт в том, что конструкторы конструируют значения одного типа.
    EC>>Ты с этим согласен?

    V>по кругу: http://www.rsdn.ru/forum/message/3374217.1.aspx
    Автор: vdimas
    Дата: 28.04.09

    V>или даже на несколько сообщений выше.
    V>Уже забыл, с чем ты изначально спорил?
    В сообщении по ссылке написано что-то дикое — какие-то пары с разметками.
    Мы наверное о разных хаскелях говорим.

    Ты можешь внятно ответить конструкторы в одном АлгТД конструируют значения одного типа или нет?
    Re[43]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 29.04.09 13:08
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    EC>>Объясни мне какое значение имеют сигнатуры конструкторов в контексте нашего обсуждения.


    V>Ты пытался не верить, что это ф-ии.


    Я там тебя недопонял и прогнал.
    Так какое это имеет отношение к ПМ?
    Re[44]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 30.04.09 12:42
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    EC>В сообщении по ссылке написано что-то дикое — какие-то пары с разметками.

    EC>Мы наверное о разных хаскелях говорим.

    EC>Ты можешь внятно ответить конструкторы в одном АлгТД конструируют значения одного типа или нет?


    Давай уже ставить точку, ок? Я еще раз напомню в одном посте то, что говорил ранее и закончим, ибо же 5-й пост ничего нового не озвучено.

    Конструкторы алгебраического типа конструируют экземпляры этого же алгебраического типа (и разумеется одного, что за нелепый вопрос). Но сам алгебраический тип придуман как обёртка для других типов, с тем, чтобы одна переменная (алгебраического типа) могла хранить значения различных целевых типов. Сам по себе алгебраический тип используется только в том самом вырожденном случае, когда он используется в качестве перечисления. Во всех остальных случаях — это обёртка для других типов.

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

    Динамическое приведение типов в CLR (не преобразование, а именно приведение без изменения значения) — суть рантайм-тест этой "разметки", матч по алгебраическим типам в хаскеле — аналогично.
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[45]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 04.05.09 11:31
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Конструкторы алгебраического типа конструируют экземпляры этого же алгебраического типа (и разумеется одного, что за нелепый вопрос). Но сам алгебраический тип придуман как обёртка для других типов,

    С этим согласен полностью.
    V>с тем, чтобы одна переменная (алгебраического типа) могла хранить значения различных целевых типов.
    Это неверно. Переменная имеет один и тот же тип, независимо от того с помощью какого конструктора ты создал значение.
    Да, ты можешь упаковать значения разных типов, но в результате упаковки получаются значения одного типа, что и подтвержается GHCi.

    V>Сам по себе алгебраический тип используется только в том самом вырожденном случае, когда он используется в качестве перечисления. Во всех остальных случаях — это обёртка для других типов.

    Продемонстрируй эти другие типы с помощью Hugs.

    V>Насчёт разметки — это не дикое, это сущность размеченных объединений, я лишь проводил аналогию с объектами CLR, которые тоже содержат эту "разметку" в виде хендла типа.

    Это всё верно, но деталь реализации.

    V>Динамическое приведение типов в CLR (не преобразование, а именно приведение без изменения значения) — суть рантайм-тест этой "разметки", матч по алгебраическим типам в хаскеле — аналогично.

    С этим никто и не спорит.

    Вообще согласен, дискуссию пора сворачивать, не удаётся мне донести разницу между абстракцией и одной из возможных её реализаций.
    Re[46]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 07.05.09 08:33
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Ага. Вот только к динамической типизации это отношения не имеет. Ведь все типы известны во время компиляции.


    Какие еще все? Все, входящие в алг. тип? Дык их несколько в общем случае, а конкретный мы определяем в рантайм.

    VD>Никто же не называет С++ динамически-типизированным только из того факта, что в нем поддерживаются виртуальные методы которые пиводят к тому, что реальный тип объекта становится известным только во время выполнения?


    В случае виртуальных методов, если я правильно понял о чем ты, мы и не должны динамически определять тип реального объекта, такой подход — следствие правила Лисков.

    Тут ведь различие очевидное: при динамическом приведении типа мы должны привести к некоему типу (неважно, матчингом или оператором динамического приведения типа) ДО выполнения операций над типом. В условиях открытой группы типов (так можно назвать все доступные типы) — это признанно плохим тоном в программировании. К сожалению, безопасность такого преобразования в CLR провоцирует подобный подход. С другой стороны, на динамическом приведении типов гораздо проще решаются многие задачи (та же обработка AST), т.к. в этих случаях нам доступен более подходящий данной задаче способ декомпозиции функциональности, в сравнении с размазыванием оной по виртуальным ф-иям многих классов. Отсюда я и считаю, что для тех задач, где сегодня мы используем динамическое приведение типов (даже если оно безопасное с т.з. возможной неверной интерпретации памяти), алгебраические типы будут более удобны, и более безопасны, но уже на уровень выше — в алгоритмическом плане, преодолевая то самое правило Лисков в ввиду закрытости группы (но опять же, только в случае контроля компилятором полноты матчинга, иначе та самая "дыра" остаётся в первозданном виде).
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[45]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 07.05.09 18:24
    Оценка:
    В качестве резюме дискуссии, если её ещё кто-то читает:
    идём читать The Haskell 98 Report по ссылке и находим 3.13 Case-выражения,
    чуть дальше читаем

    Case-выражение должно иметь по крайней мере одну альтернативу, и каждая альтернатива должна иметь по крайней мере одно тело.
    Каждое тело должно иметь один и тот же тип, и все выражение должно быть того же типа.

    Если сомнения ещё остались, то можно прочесть 3.17 Сопоставление с образцом:

    Образцы появляются в лямбда-абстракциях, определениях функций, связываниях с образцом, описаниях списков, do-выражениях и case-выражениях. Тем не менее, первые пять из них в конечном счете транслируются в case-выражения, поэтому достаточно ограничиться определением семантики сопоставления с образцом для case-выражений.

    now playing: Dubfire — I Feel Speed (Alternative Mix)
    Re[46]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 07.05.09 20:50
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    EC>В качестве резюме дискуссии, если её ещё кто-то читает:

    EC>идём читать The Haskell 98 Report по ссылке и находим 3.13 Case-выражения,
    EC>чуть дальше читаем
    EC>

    EC>Case-выражение должно иметь по крайней мере одну альтернативу, и каждая альтернатива должна иметь по крайней мере одно тело.
    EC>Каждое тело должно иметь один и тот же тип, и все выражение должно быть того же типа.


    Опять у кого-то кое-где каша.
    Каждое тело должно иметь один и тот же тип, т.к. это будет тип всего case-выражения, но этот тип может быть произвольным, не связанным с аргументом case.

    Так что не вижу тут никакого резюме, даже не вижу связи с обсуждаемым.
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[39]: Проблемы организации OR-мапинга
    От: artelk  
    Дата: 08.05.09 08:32
    Оценка:
    Здравствуйте, vdimas, Вы писали:

    V>Обобщенный тип для алгебраического типа — это не аналог параметризуемого обобщенного типа из С++, это аналог union из того же С++. Это некий bag, куда заворачиваются другие типы, составляющие группу.


    V>В общем, типы, входящие в группу, в общем случае не приводимы один к одному, поэтому нужен механизм, чтобы в одном аргументе передавать значения разных типов. Этот механизм — алгебраические типы. Типы заворачиваются в discriminated union.


    EC>>Если добавить аргументов конструкторам значений, то с точки зрения типов ничего не изменится.


    V>Ты бы сначала добавил.


    <...>

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


    V>А я не понимаю твоего упорства — всё более чем прозрачно.


    V>И как раз об абстракции и говорил в первом утверждении, что полиморфизм по алгебраическим типам — это классика динамической типизации. Могу усилить — это наилучший на сегодня способ использования динамической типизации.


    Совсем не обязательно реализовывать алгебраические типы через группировку других типов и т.п.
    //data AAA  = X Int Int | Y Int Int Int
    public class AAA
    {
        private readonly int[] data;
    
        private enum Discr { X, Y }
        private readonly Discr discr;
    
        private AAA(Discr discr, int[] data)
        {
            this.data = data;
            this.discr = discr;
        }
    
        public static AAA CreateX(int a1, int a2)
        {
            return new AAA(Discr.X, new[] { a1, a2 });
        }
    
        public static AAA CreateY(int a1, int a2, int a3)
        {
            return new AAA(Discr.Y, new[] { a1, a2, a3 });
        }
    
        private MatchResult<T> matchX<T>(Func<int, int, T> f)
        {
            if (discr != Discr.X)
                return MatchResult<T>.NotMatch;
    
            return new MatchResult<T>(f(data[0], data[1]));
        }
    
        private MatchResult<T> matchY<T>(Func<int, int, int, T> f)
        {
            if (discr != Discr.Y)
                return MatchResult<T>.NotMatch;
    
            return new MatchResult<T>(f(data[0], data[1], data[2]));
        }
    
        //Принимает параметрами функции для всех возможных вариантов
        public T Match<T>(Func<int, int, T> f_X, Func<int, int, int, T> f_Y)
        {
            var result = matchX(f_X);
            if (result != MatchResult<T>.NotMatch)
                return result.Result;
            return matchY(f_Y).Result;
        }
    }
    
    public class MatchResult<T>
    {
        public readonly bool IsMatch;
        public readonly T Result;
    
        public MatchResult(T result)
        {
            IsMatch = true;
            Result = result;
        }
    
        private MatchResult(){IsMatch = false;}
    
        public static readonly MatchResult<T> NotMatch = new MatchResult<T>();
    }
    
    //case myAAA of
    //    | X x y -> x + y
    //    | Y a b c -> a + b + c
    var myAAA = AAA.CreateY(1, 2, 3);
    var res = myAAA.Match((x, y) => x + y,
                          (a, b, c) => a + b + c);
    Re[48]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 08.05.09 08:42
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    V>>Так что не вижу тут никакого резюме, даже не вижу связи с обсуждаемым.


    EC>Ок, ваш слив засчитан.



    Похоже, ты не понимаешь, почему в ФЯ выражение должно обязательно иметь тип, и почему для тел case этот тип должен быть одинаков, при этом вовсе не обязан быть алгебраическим.
    bool2int Bool a = case a of
      True -> 1
      False -> 0
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[40]: Проблемы организации OR-мапинга
    От: vdimas Россия  
    Дата: 08.05.09 09:12
    Оценка:
    Здравствуйте, artelk, Вы писали:

    A>Совсем не обязательно реализовывать алгебраические типы через группировку других типов и т.п.


    ...

    В этом примере ты всего лишь разместил по одному адресу значения для случаев X и Y, потому как это оказалось возможным с т.з. системы типов CLR (тип массива не зависит от последней размерности). Если бы зависело, как в С++, то так просто не вышло бы. А в рассматриваемых мною исходниках Хаскеля по одному адресу размещаются значения вообще различных типов, сразу после дискриминатора, такое размещение аналогично union из С/С++. Но в отличии от последнего, язык не предоставляет ср-ва для потенциально неверной реинтерпретации памяти.

    Кстати, не столь важный, но все же существующий на сегодня момент ты подметил — оно неплохо смотрится для всяких PDU, мы поступаем аналогично при проектировании прикладных протоколов. Вернее, не совсем так же, но в общем случае стараемся переиспользовать поля такой самописной алгебраической структуры для различных значений дискриминатора (всё-равно ручками пока что долбим эти вещи).

    По остальному:
    — приватный конструктор и вмеcто него "статические конструкторы" — абсолютно правильно, однако мы часто делаем их как value type, когда по сценарию их множества хранятся, что оставляет некую "дырочку" в виде конструктора по-умолчанию.
    — матч перемудрил, там просто case по дискриминатору надо сделать, безо всяких MatchResult, matchX и matchY.
    ... << RSDN@Home 1.2.0 alpha rev. 786>>
    Re[49]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 08.05.09 11:05
    Оценка:
    Здравствуйте, vdimas, Вы писали:


    V>Похоже, ты не понимаешь, почему в ФЯ выражение должно обязательно иметь тип, и почему для тел case этот тип должен быть одинаков, при этом вовсе не обязан быть алгебраическим.

    V>
    V>bool2int Bool a = case a of
    V>  True -> 1
    V>  False -> 0 
    V>


    Я не понимаю какое отношение то, что ты пишешь имеет к обоснованию динамической типизации паттерн матчинга в хаскеле.
    Ты можешь дать ссылку на место в The Haskell 98 report подтверждающее твои слова?
    А то надоело слушать отвлечённые рассуждения о том как что-то можно сделать в C++ или поверх CLR.
    Re[23]: Проблемы организации OR-мапинга
    От: dimgel Россия https://github.com/dimgel
    Дата: 18.05.09 13:11
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Но такая фича не поддерживается в дотнете. По этому даже ФЯ реализованные на дотнете не поддерживают записей (по крайней мере в полной мере).


    В скале эта фича есть, скала может компилироваться в .NET. Проблема выруливается на этапе компиляции преобразованием (1, "1") в new Tuple2<Int,String> (1, "1"). На данный момент поддерживаются до Tuple22.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[11]: Проблемы организации OR-мапинга
    От: dimgel Россия https://github.com/dimgel
    Дата: 18.05.09 14:14
    Оценка:
    Здравствуйте, gandjustas, Вы писали:

    A>>Анонимные типы, очень хорошая аналогия, только пользы от них в данном случае никакой нет. Надо уметь возвращать вполне конкретные типы, а какие именно автоматически не вывести.

    G>Это решется с помощью метаданных. Причем метаданные могут быть выведены автоматически (следующая версия EF это будет уметь)

    Имеется в виду что-то типа следующего?

    $ scala
    Welcome to Scala version 2.7.4.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_13).
    Type in expressions to have them evaluated.
    Type :help for more information.
    
    scala> case class User(id: Int, firstName: String, lastName: String) {
         | def fullName = firstName + " " + lastName
         | }
    defined class User
    
    scala> val tuple = (1, "John", "Brown")
    tuple: (Int, java.lang.String, java.lang.String) = (1,John,Brown)
    
    scala> implicit def tuple2user(t: Tuple3[Int, String, String]) = new User(t._1, t._2, t._3)
    tuple2user: ((Int, String, String))User
    
    scala> tuple.fullName
    res0: java.lang.String = John Brown


    Здесь преобразование выполняется не совсем автоматически: явно заданным implicit-методом (вполне, впрочем, простым).
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re: 2IT & VladD2 & gandjustas & MozgC & others
    От: Tom Россия http://www.RSDN.ru
    Дата: 25.05.09 06:53
    Оценка:
    Предлагаю продолжить тут http://rsdn.ru/forum/philosophy/3400215.1.aspx
    Автор: Tom
    Дата: 22.05.09


    Очень интересно Ваше мнение на тему сабсоника.
    Народная мудрось
    всем все никому ничего(с).
    Re[2]: 2IT & VladD2 & gandjustas & MozgC & others
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.05.09 11:59
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Предлагаю продолжить тут http://rsdn.ru/forum/philosophy/3400215.1.aspx
    Автор: Tom
    Дата: 22.05.09


    Tom>Очень интересно Ваше мнение на тему сабсоника.


    Какое может быть мнение?
    Я этим не пользовался, так что ничего особо сказать не могу.

    На первый взгляд выглядит фигней, так как то и дело встречаются строковые константы (стало быть о проверке типов во время компиляции и интеллисенсе речи идти не может).
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[3]: 2IT & VladD2 & gandjustas & MozgC & others
    От: Tom Россия http://www.RSDN.ru
    Дата: 26.05.09 12:19
    Оценка:
    Здравствуйте, VladD2, Вы писали:

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


    Tom>>Предлагаю продолжить тут http://rsdn.ru/forum/philosophy/3400215.1.aspx
    Автор: Tom
    Дата: 22.05.09


    Tom>>Очень интересно Ваше мнение на тему сабсоника.


    VD>Какое может быть мнение?

    VD>Я этим не пользовался, так что ничего особо сказать не могу.

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

    Строковые константы там только для того что бы показать что и так можно. Более того, если есть строка (... SET A = 'B'), то сабсоник распарсит такую конструкцию и в итоге передаст 'B' как параметр.
    Предлагаю обсуждать в том топике, этот уже нездорово большой
    Народная мудрось
    всем все никому ничего(с).
    Re[4]: 2IT & VladD2 & gandjustas & MozgC & others
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 26.05.09 12:49
    Оценка:
    Здравствуйте, Tom, Вы писали:

    Tom>Более того, если есть строка (... SET A = 'B'), то сабсоник распарсит такую конструкцию и в итоге передаст 'B' как параметр.

    Tom>Предлагаю обсуждать в том топике, этот уже нездорово большой

    Когда распарсит?

    Из примеров я вижу, что все откладывается на рантайм.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[6]: Проблемы организации OR-мапинга
    От: ili Россия  
    Дата: 02.06.09 12:10
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Кстати, забыл про SQL отдельно от кода. Иногда приложение можно существенно оптимизировать, генерируя и оптимизируя код SQL на клиенте. За примером далеко ходить не надо — это наш сайт и конкретно MainList.aspx. Переписывание кода со статического SQL на Linq2SQL решило проблему, над которой мы бились несколько лет, пытаясь тщетно подкрутить монстрообразный запрос индексами и хинтами.


    покажите в образовательных целях что было и что стало, а то пример проскакивает неоднократно, но ненаглядно.
    Re[8]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 04.06.09 04:46
    Оценка:
    Здравствуйте, IT, Вы писали:

    Два вопроса...

    1. Зачем нужен result.ToList()?
    2. Что дальше делается с анонимным типом возвращаемым в коллекции?
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[9]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 04.06.09 13:16
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>1. Зачем нужен result.ToList()?


    Если мне правильно подсказывает мой склероз, то дальше по ходу дела нужен Count, так что преобразовывать в список всё равно надо. Да это и не очень накладно для 20-40 записей.

    VD>2. Что дальше делается с анонимным типом возвращаемым в коллекции?


    Баиндится на грид.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[8]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 04.06.09 13:22
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>В 95% работают следующие оптимизации:


    IT>- allowed.Contains устраняется,

    IT>- пейджинг превращается в TOP,
    IT>- проверка AnswerCount не делается.

    И ещё забыл — skip тоже уходит в ноль.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[10]: Проблемы организации OR-мапинга
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 04.06.09 14:33
    Оценка:
    Здравствуйте, IT, Вы писали:

    VD>>1. Зачем нужен result.ToList()?


    IT>Если мне правильно подсказывает мой склероз, то дальше по ходу дела нужен Count, так что преобразовывать в список всё равно надо. Да это и не очень накладно для 20-40 записей.


    Как-то странно это делать в методе, а не там где надо.
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[11]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 04.06.09 14:42
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Как-то странно это делать в методе, а не там где надо.


    Там using стоит вокруг RsdnDataContext, неизвестно чем закончится возврат енумератора из этого метода.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[12]: Проблемы организации OR-мапинга
    От: EvilChild Ниоткуда  
    Дата: 12.06.09 16:48
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Там using стоит вокруг RsdnDataContext, неизвестно чем закончится возврат енумератора из этого метода.

    Под возвратом енумератора понимается возврат значения переменной results?
    Если по нему foreach'ем пройтись с yield'ом, то всё должно быть путём — ничего раньше времени не задиспозится.
    now playing: Oliver Huntemann — Radio
    Re[13]: Проблемы организации OR-мапинга
    От: IT Россия linq2db.com
    Дата: 15.06.09 13:37
    Оценка:
    Здравствуйте, EvilChild, Вы писали:

    IT>>Там using стоит вокруг RsdnDataContext, неизвестно чем закончится возврат енумератора из этого метода.

    EC>Под возвратом енумератора понимается возврат значения переменной results?
    EC>Если по нему foreach'ем пройтись с yield'ом, то всё должно быть путём — ничего раньше времени не задиспозится.

    Может быть, не проверял. Но если return IEnumerable, который подвязан к контексту, который в свою очередь будет разрушен при выходе из метода, тем не менее будет работать, то выглядеть это будет как минимум странно.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[14]: Проблемы организации OR-мапинга
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 23.06.09 06:56
    Оценка:
    Здравствуйте, IT, Вы писали:
    IT>Может быть, не проверял. Но если return IEnumerable, который подвязан к контексту, который в свою очередь будет разрушен при выходе из метода, тем не менее будет работать, то выглядеть это будет как минимум странно.
    Это кагбэ не должно работать. До первого обращения к итератору не выполняется вообще никакой его код. Даже тот, что мог бы попытаться предотвратить закрытие соединения в finally. Поэтому твой код совершенно корректен: декларативность и ленивость хороши до поры. Но потом настаёт время сказать "всё, вот тут мы должны закончить всюработу, и гарантировать возврат соединения в пул".
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.