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

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

C>>Естественно никаких причин держать все эти методы в базовом классе, кроме убеждения, что раз ООП — значит весь функционал для работы с объектом надо запихнуть в базовый класс.

_FR>Вредное, безграмотное и частое, замечу, убеждение

Не сыпте соль на рану. Сами мучаемся, по требованию заказчика с CSLA .

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

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

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

VD>Ну, и какая разница будет ли эта хранимая процедура или функция на C# 3.0 или другом совместимом с ЛИНК-ом языке? T-SQL убог. Современные ЯП куда гибче и существенно быстрее. Понятно, что в основном там будут запросы к БД и скорость тут не очень важна, но все же куда приятнее чувствовать под копотом мощьный движок, а не дряглый и малосильный. T-SQL максимум что позволяет, это поместить все запросы в СУБД. Но обычно это не является критичным. Ведь выборка делается в бизнес-уровне который соеденен с СУБД широким и не латентным каналом связи. В прочем, уверен, что ЛИНК можно применять из из того же MS SQL Swrver, так что вообще не ясно в чем проблема.

VD>Лично я не задумываясь променяют T-SQL на ЛИНК.

Зря зря батеьнка.

T-SQL надежен универсален и отлажен, 20 годами реляционной теории и мелкософтом

А Linq — пока неизвестно что, а именно:
версиями в обьектах не управляет.
генерит запросы плохо. так что все недовольны.
не заменишь поведение.

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

В общем недостаток на недостатке.

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

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

A>В тему, по поводу качества генерируемых запросов Outsmarted by LINQ-to-SQL



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

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

В общем недостаток на недостатке.

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

V>А Linq — пока неизвестно что, а именно:
V>версиями в обьектах не управляет.
А T-SQL управляет?

V>генерит запросы плохо. так что все недовольны.
Нормально генерит. Для неочень сложной базы вообще отлично генерит.

V>Запрос, Линк который нормальный, зато испоняется "при необходимости",
V>т.е. при запросе к каждой строке обьекта он делает запрос к базе данных,
V>и чтобы переплюнуть это надо сильно извратиться.
Неправда. Один запрос получет список объектов.

V>В общем недостаток на недостатке.
А может вы просто не умеете его использовать?

А что делать тем кто не знает в совершенстве SQL?

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

V>А Linq — пока неизвестно что, а именно:
V>версиями в обьектах не управляет.
V>генерит запросы плохо. так что все недовольны.
пример в студию, пока что все мои запросы вполне нормальные
V>не заменишь поведение.
поведение чего?

V>Запрос, Линк который нормальный, зато испоняется "при необходимости",
V>т.е. при запросе к каждой строке обьекта он делает запрос к базе данных,
на TSQL тоже можно вызывать подзапросы из курсоров, разве это говорит плохо о языке?

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


V>В общем недостаток на недостатке.

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

V>Linq — пока неизвестно что по качеству системы, а именно:
V>версиями в обьектах не управляет.
V>генерит запросы плохо. так что все недовольны.
V>не заменишь поведение.

V>Запрос, Линк который нормальный, зато испоняется "при необходимости",
V>т.е. при запросе к каждой строке обьекта он делает запрос к базе данных,
V>и чтобы переплюнуть это надо сильно извратиться.

V>В общем недостаток на недостатке.

где-то я это уже видел
там же и ответил

Здравствуйте, Аноним, Вы писали:

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

V>>А Linq — пока неизвестно что, а именно:
V>>версиями в обьектах не управляет.
V>>генерит запросы плохо. так что все недовольны.
А>пример в студию, пока что все мои запросы вполне нормальные

var query =
from b in db.GroupCountTests
group
new { b.Code, b.Catalog }
by b.Code into g
where g.Distinct().Count() > 1
select g;

дает
SELECT [t1].[Code] AS [Key]
FROM (
SELECT [t0].[Code]
FROM [dbo].[GroupCountTest] AS [t0]
GROUP BY [t0].[Code]
) AS [t1]
WHERE ((
SELECT COUNT(*)
FROM (
SELECT DISTINCT [t2].[Code], [t2].[Catalog]
FROM [dbo].[GroupCountTest] AS [t2]
WHERE (([t1].[Code] IS NULL) AND ([t2].[Code] IS NULL)) OR (([t1].[Code] IS NOT NULL) AND ([t2].[Code] IS NOT NULL) AND ([t1].[Code] = [t2].[Code]))
) AS [t3]


вместо чего-то вроде

SELECT SomeDayID, DayValue
FROM SomeDays
WHERE DayValue in
(
SELECT DayValue
FROM SomeDays
GROUP BY DayValue
HAVING COUNT(*) > 1
)


V>>не заменишь поведение.
А>поведение чего?

поведение генерации запросов
например Deffered Execution при вышеуказанном запросе,
ВСЕГДА будет выполняться запросы для каждой группы, если не менять сам запрос,
никакие опции не помогут!

V>>Запрос, Линк который нормальный, зато испоняется "при необходимости",
V>>т.е. при запросе к каждой строке обьекта он делает запрос к базе данных,
А>на TSQL тоже можно вызывать подзапросы из курсоров, разве это говорит плохо о языке?

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

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

а кто-то хочет (ВЫ)назвать все что относится к LInq заведомо нормальным,
а все что к другим языкам "проблемными усложнениями для чего и вводился Linq"...
таким фразам верить нельзя, они зхвалят то что выбрали, хотя именно ругаются они хорошо.


В общем недостаток на недостатке.

А еще проблема-
вы никогда не передадите разные данные через уровень, в SQL serverу примеру
не меняя сервиса — т.е.
не добавля метода с другой сигнатурой и кода для обработки...

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

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


V> var query =
V> from b in db.GroupCountTests
V> group
V> new { b.Code, b.Catalog }
V> by b.Code into g
V> where g.Distinct().Count() > 1
V> select g;

дайте, пожалуйста, описание таблицы и если не сложно опишите задачу

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

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


V>>генерит запросы плохо. так что все недовольны.
G>Нормально генерит. Для неочень сложной базы вообще отлично генерит.

Как вы сделали заключение что отлично?

брали кучу запросов и анализировали планы исполнения SQL?

V>>Запрос, Линк который нормальный, зато испоняется "при необходимости",
V>>т.е. при запросе к каждой строке обьекта он делает запрос к базе данных,
V>>и чтобы переплюнуть это надо сильно извратиться.
G>Неправда. Один запрос получет список объектов.

Но без обьектов на которые ссылается по группировке.

V>>В общем недостаток на недостатке.
G>А может вы просто не умеете его использовать?

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

а часть проблем — если предложенный способ генерации не оптимален ,
то как вы это обойдете?

Ведь оптимизация происходит в SQL Servere,
и есть технологии для этого, и по мету выполнения,
и реально весьма эффективные
а для LINQ нет ничего,

G>А что делать тем кто не знает в совершенстве SQL?

из предыдущего поста видно что SQL надо знать.

C>>Естественно никаких причин держать все эти методы в базовом классе, кроме убеждения, что раз ООП — значит весь функционал для работы с объектом надо запихнуть в базовый класс.

_FR>Вредное, безграмотное и частое, замечу, убеждение

Предложите другой вариант, как сделать версионность данных ? Undo..

которые прибиндены к UI контролам..

А>дайте, пожалуйста, описание таблицы и если не сложно опишите задачу

в таблице из двух полей: код и каталог

найти записи, где для одного кода больше одного разного каталога

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

_FR>>Вредное, безграмотное и частое, замечу, убеждение

V>Предложите другой вариант, как сделать версионность данных ? Undo..

V>которые прибиндены к UI контролам..

Можно использовать БО через DynamicProxy в котором перехватывать все изменения свойтв и запоминать их.
От БО требуется только чтобы изменяемые свойства были виртуальными и совершенно необязательно запихивать этот функционал в базовый класс.

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

А>>дайте, пожалуйста, описание таблицы и если не сложно опишите задачу
V>в таблице из двух полей: код и каталог
V>найти записи, где для одного кода больше одного разного каталога
В чем проблема? Пишите stored prcedure и вызывайте её.

G>В чем проблема? Пишите stored prcedure и вызывайте её.

проблемы нет.
Просто этот случай типичный,
т.е. на многие типичные случаи вы предлагаете писать usp?
Зачем же тогда Linq ?

Часть премуществ по устранению излишнего кодирования пропадает далеко.

C>Можно использовать БО через DynamicProxy в котором перехватывать все изменения свойтв и запоминать их.
C>От БО требуется только чтобы изменяемые свойства были виртуальными и совершенно необязательно запихивать этот функционал в базовый класс.

Я имел ввиду любую неусложненную имплементацию, которая устраняет массовое кодирование "каждый раз",
мне придется все сгенеренные свойства вручную переписывать как виртуальные?
или
БО с DynamicProxy — это что придется их генерить через Reflection.Emit ?

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

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

что мешает делать сразу виртуальными, если вы их генерируете? Как раз один раз написаный interceptor для DynamicProxy решает проблемы undo для любого объекта (даже если он уже наследуется от какого-то базового класса, в котором нет нужного функционала).

V>или
V>БО с DynamicProxy — это что придется их генерить через Reflection.Emit ?

Всё уже сделали за нас — вызываете конструктор DynamicProxy передаёте ему тип вашего объекта и список нужных интерсепторов (валидации, undo etc) и все.
Любая возможная реализация undo в базовом классе, всё равно будет использовать Reflection.

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

C>что мешает делать сразу виртуальными, если вы их генерируете? Как раз один раз написаный interceptor для DynamicProxy решает проблемы undo для любого объекта (даже если он уже наследуется от какого-то базового класса, в котором нет нужного функционала).

Их генерирует SQLMetal Linq, а не я, поэтому контроля не имею.

V>>или
V>>БО с DynamicProxy — это что придется их генерить через Reflection.Emit ?

C>Всё уже сделали за нас — вызываете конструктор DynamicProxy передаёте ему тип вашего объекта и список нужных интерсепторов (валидации, undo etc) и все.

покажите на хорошую реализуацию ?
я не знал про это, но
но читал о чем -то что неприятное:
http://www.theserverside.net/news/thread.tss?thread_id=23933
As far as I know, there are two ways to do this:
— Using the magical RealProxy class that monkeys with the context (whatever that means). This requires that the object that is being proxied must extend ContextBound.
— Using Reflection.Emit to generate a new class at runtime that overrides/implements the necessary methods and dispatches invocations to a generic handler. This can implement an interface or override any virtual method."


C>Любая возможная реализация undo в базовом классе, всё равно будет использовать Reflection.
но может сделали хорошую? покажите ?

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

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

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

C>>что мешает делать сразу виртуальными, если вы их генерируете? Как раз один раз написаный interceptor для DynamicProxy решает проблемы undo для любого объекта (даже если он уже наследуется от какого-то базового класса, в котором нет нужного функционала).

V>Их генерирует SQLMetal Linq, а не я, поэтому контроля не имею.

Тогда речь о использовании базового класса для реализации undo вообще быть не может.

Зато есть не очень сложный способ сделать свойство виртуальным даже в классе, сгенерированном SQLMetal Linq:

допустим есть сгенерированный класс:

    [Table(Name="dbo.PERSONNELS")]
    public partial class PERSONNEL : INotifyPropertyChanging, INotifyPropertyChanged
    {
        ....
    }

c свойством int PERSONNEL_ID.

создаём класс:

        interface IPersonnel
    {
        int PERSONNEL_ID { get; set; }
    }

    public partial class PERSONNEL : IPersonnel
    {        
    }

и свойство автоматически становится виртуальным. Интерфейсы можно генерировать по "dbml" файлу. Не совсем красиво конечно.


C>>Всё уже сделали за нас — вызываете конструктор DynamicProxy передаёте ему тип вашего объекта и список нужных интерсепторов (валидации, undo etc) и все.

V>покажите на хорошую реализуацию ?
V>я не знал про это, но
V>но читал о чем -то что неприятное:
V>http://www.theserverside.net/news/thread.tss?thread_id=23933
V>As far as I know, there are two ways to do this:
V>- Using the magical RealProxy class that monkeys with the context (whatever that means). This requires that the object that is being proxied must extend ContextBound.
V>- Using Reflection.Emit to generate a new class at runtime that overrides/implements the necessary methods and dispatches invocations to a generic handler. This can implement an interface or override any virtual method."

Castle DynamicProxy

С примерами и документацией некоторые проблеммы, но сходу нашёл:
http://thom.org.uk/blog/FutureValuesWithCastlesDynamicProxy.aspx
http://weblogs.shockbyte.com.ar/rodolfof/archive/2006/02/12/4660.aspx

В кратце пользоваться можно так:

ProxyGenerator generator = new ProxyGenerator();
return (T)generator.CreateProxy(typeof(T), new AsyncProxy(), target);

где Т — тип нашего объекта.
Насколько я знаю, этот прокси используется в NHibernate и Spring.NET.

C>>Любая возможная реализация undo в базовом классе, всё равно будет использовать Reflection.
V>но может сделали хорошую? покажите ?

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

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

TK>Если вам кажется, что слоев слишком много — скорее всего, вы просто используете инструмент не по назначению.
не слоев и даже не сериализации/десериализации а мапперов. Ну согласись ведь бред дважды "перемапливать" объект только для того чтобы получить его state на стороне сервис.