Здравствуйте, Tom, Вы писали:
G>>Есть большая проблема в примерах архитектуреных решений. Маленькие примеры непоказательны, а в больших трудно разобраться, да и многие преимущества и недостатки неочевидны. Tom>А розового слоника в вакууме трогать нельзя, а то забанят. без примеров подобные топики сваливаются после третьего сообщения в маразм. Tom>Я думаю идеальным было бы маааленькое приложение как пример. Tom>С разбором, можно так, можно так. Тут такие плюсы минусы. тут такие...
Я писал такое "маленькое" приложение для целей презентации, когда дошло до 1000 строк забил. Решил просто основные фрагменты на слайдах показать с надеждой что мне на слово поверят.
Здравствуйте, gandjustas, Вы писали:
Tom>>Я думаю идеальным было бы маааленькое приложение как пример. Tom>>С разбором, можно так, можно так. Тут такие плюсы минусы. тут такие... G>Я писал такое "маленькое" приложение для целей презентации, когда дошло до 1000 строк забил.
Очень жаль
Здравствуйте, 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 в БД, а из клиентского кода работать как с таблицами
Здравствуйте, 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)
Здравствуйте, vdimas, Вы писали:
V>Да, хаскелисты тоже так считают. Хотя, полиморфизм по алгебраическим типам — это опять же и снова классика динамической типизации.
Это в каком месте полиморфизм по алгебраическим типам динамически типизирован?
Здравствуйте, 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 теряется.
Здравствуйте, IT, Вы писали:
IT>Это назвается строить логику на исключениях, практика, за которую нужно не просто отбивать пальцы линейкой, а лучше даже что-нибудь отрезать.
Здравствуйте, 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 и изменения схемы.
Здравствуйте, MozgC, Вы писали:
IT>>Это назвается строить логику на исключениях, практика, за которую нужно не просто отбивать пальцы линейкой, а лучше даже что-нибудь отрезать.
MC>Скажи, а как ты объяснишь это: MC>http://rsdn.ru/forum/message/1072811.aspx
(смотреть на выброс исключений в методе Validate())
Нормально смотрю. Если происходит операция сохранения объекта где-то в глубинах бизнес логики и валидация говорит, что объект невалиден, то программа не может далее продолжить своё выполнение. Исключительная ситуация. К тому же в том же булките есть возможность спросить (без исключения) валиден ли объект и даже не весь объект, а одно из его полей. Я так, например, красные рамки вокруг полей ввода рисую. Но если уже вызвана процедура сохранения объекта, то тут уже делать нечего, программу нужно прерывать.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, 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 и изменения схемы.
Посмотри выше по ветке. Там вроде все достаточно прозрачно.
Здравствуйте, 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.
Для пар "ключ-значение" уже есть классы.
Вообще не надо выдумывать, я уже давно таким подходом пользуюсь, пачек классов нету вообще.
Здравствуйте, 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>Вообще не надо выдумывать, я уже давно таким подходом пользуюсь, пачек классов нету вообще.
Если бы такого не было, я бы не спрашивал, наверное.
Здравствуйте, 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>В случае функции бизнес-код будет содержать информацию о том, как данные хранятся, а такому коду, имхо, не место в бизнесе.
Что значит как? Они хранятся в таблицах БД. И в знании этой "сокровенной тайны" нет ничего страшного.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, VladD2, Вы писали: VD>>То и значит. Нет полей. Нет "структуры". S>Поля не нужны. Достаточно readonly-пропертей.
Для записей важны такие характеристики как идетничность по содержимому и возможность копирования в структурно-совместимые записи и кортежи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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. Поэтому мой мозг пасует перед сложностью задачи.
Потому что ты исходишь из неверных предпосылок. Нужно не заплаты придумывать, а ошибки исправлять.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
S>>1. Есть анонимные типы. В них удобно то, что компоненты — именованные. Это крайне здорово, т.к. позволяет делать меньше ошибок. S>>2. В них неудобно то, что их нельзя возвращать. S>>3. Причем понятно, почему нельзя — они же строго локальны.
VD>Это догмы введенные дизайнирами дотнета.
Насколько я помню рассказ Хейльсберга (?) о rationale текущей реализации, для поддержки возвращения анонимных типов требуются некоторые достаточно существенные изменения/добавления в IL. Чего в 3.5, по понятным причинам, делать не хотелось. В дальнейшем же нет никаких особых проблем расширить функциональность в этом направлении.
Здравствуйте, drol, Вы писали:
D>Насколько я помню рассказ Хейльсберга (?) о rationale текущей реализации, для поддержки возвращения анонимных типов требуются некоторые достаточно существенные изменения/добавления в IL. Чего в 3.5, по понятным причинам, делать не хотелось. В дальнейшем же нет никаких особых проблем расширить функциональность в этом направлении.
IL менять не надо. Менять надо рантайм. Ту его часть, что отвечает за сравнение типов.
Проблем "расширить функциональность в этом направлении" действительно нет. Но и расширения похоже не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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-колонке, совместно с другими полями?
без примеров подобные топики сваливаются после третьего сообщения в маразм.
Если нам не помогут, то мы тоже никого не пощадим.
