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

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

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

L>Нет, этот вариант хуже линка, уверяю вас. Маппинг придется реализовывать в ручную. Хотя кому-то это очень нравится (DuШes).
:-D по-моему, вы уж както совсем пререходите на личности...и где я об этом говорил, что вручную? я говорил о том, что проще написать под свои цели свой dal нежели применять linqtosql + напильник в сценариях с применением хранимок...

и вообще само понятие "маппинг вручную" — что вы под этим понимаете? чем так сильно отличается использование атрибутов хотя бы отклассической модели datareader, уж даже не рассматриваем свои orm с применением свой кастомной декларативности в виде использования атрибутов?

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

S>Я таки понял что мне напоминает этот тред — http://ru.thedailywtf.com/Articles/SQL-Predlozheniya.aspx

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

S>По сабжу. Ado.NET Team продолжает традиции МС в разработке фреймворков для доступа к данным: вместо того, чтобы довести хоть одну технологию до ума, они вечно бросаются из крайности в крайность — то у нас рулит disconnected approach и датасеты, то нифига, бизнесь не выживет без ормапперов с поддержкой наследования и статически верифицируемых запросов к СУБД.

EF вроде как поддерживает то ли disconnected entities, то ли контекст, так что тут все-таки не "бросаются из крайности в крайность", а довольно-таки поседовательнл.

S>Если не секрет, о каких типах приложений вы спорите? И EF, И Linq2Sql неудобны для написания data-driven desktop clients по куче причин. Во-первых отсутствие disconnected-режима (только давайте не будем говорить про Sql Compact и репликацию с главным сервером — это разные сценарии).

EF поддерживает, вроде.

S>Во-вторых — грабли с биндингом, загрузкой графа объектов и регистрацией их в контексте (особенно через хранимки).

А что с этим не так? Я просто не совсем в курсе.

S>В третьих — невозможность глобальной валидации на уровне контекста. Либо работаем исключительно через воспомогательные методы (биндинг идёт лесом), либо смиряемся с тем, что некорректные данные обнаруживаются только сервером при submit changes. Я говорю не о тривиальных проверках, которые вполне осуществимы через геттеры/сеттеры, а о проверках, которые необходимо делать при изменении контекста (эдакий аналог событий RowChanging у DataTable).

У Linq2Sql-овских сущностей точно есть аналог RowChanging, даже что-то с валидацией есть.

S>Плохие они все

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

Tom>В упор непонимаю почему запросы SQL тяжелее писать чем LINQ. Как раз SQL (TSQL) обладает всей мощью для работы с БД, в отличии от линка.

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

Tom>Ну и второй аргумент вообще непонятен. зачем целевую БД модифицировать, почему, непонятно....

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

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


L>P.S. В своем предыдущем сообщении я попросил привести ссылки на мои сообщения, где я якобы: предлагал вручную менять сгенерированный код и реализовывать трекинг вручную. Не могли бы вы потрудиться и все-таки найти сообщения, где я все это предлагал? Спасибо.

вы что в упор не видите? еще раз, мы говорим о процедурах или о чем?

Никто никуда не кричит. Тот, кто изменяет схему, обязан изменить и соответствующие entity. Самый простой способ — это внести это изменение вручную в dbml.

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

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

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

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

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

L>>Нет, этот вариант хуже линка, уверяю вас. Маппинг придется реализовывать в ручную. Хотя кому-то это очень нравится (DuШes).
DШ>:-D по-моему, вы уж както совсем пререходите на личности...

А вам разве это не нравится? Зачем вы тогда это делаете?

DШ>и где я об этом говорил, что вручную? я говорил о том, что проще написать под свои цели свой dal нежели применять linqtosql + напильник в сценариях с применением хранимок...

Для меня это и есть вручную. Вручную педалить кучу кода, когда уже есть готовые фреймворки.

DШ>и вообще само понятие "маппинг вручную" — что вы под этим понимаете? чем так сильно отличается использование атрибутов хотя бы отклассической модели datareader, уж даже не рассматриваем свои orm с применением свой кастомной декларативности в виде использования атрибутов?

Ответьте себе на вопрос "зачем" для начала.

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

DШ>Здравствуйте, Lloyd, Вы писали:


L>>P.S. В своем предыдущем сообщении я попросил привести ссылки на мои сообщения, где я якобы: предлагал вручную менять сгенерированный код и реализовывать трекинг вручную. Не могли бы вы потрудиться и все-таки найти сообщения, где я все это предлагал? Спасибо.

DШ>вы что в упор не видите? еще раз, мы говорим о процедурах или о чем?

Да, я в упор не вижу, где я предлагаю вручную "менять сгенерированный код" и "реализовывать трекинг вручную". Можно конкретный цитаты по первому и по второму отдельно.

DШ>

DШ>Никто никуда не кричит. Тот, кто изменяет схему, обязан изменить и соответствующие entity. Самый простой способ — это внести это изменение вручную в dbml.

DШ>не маппер для процедур невозможен, а невозможна генерация типизированного резалтсета для таких процедур.
DШ>тем не менее для таких процедур можно вполне успешно использовать маппер, смотри доку по IMultipleResults

DШ>Этот недостаток имеется, но при должной дисциплине разработки с ним можно жить. Лучше бы его не было, но что делать.

DШ>вообщем, как я понимаю, ваш linqtosql дизайнер, именно ваш,

Он не мой, он микрософта.

DШ>потому что мой не умеет, настолько умный, что понимает логику в хранимых процедурах

Ссылку, где я такое говорил.

DШ>и за вас генерирует классы-врапперы над результати работы хранимки...

Ссылку, где я такое говорил.

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

S>Если бы я все это умел У нас есть человек специальный для этого. Он полностью занимается БД на стороне SQL сервера. Может даже оптимизирует что-то там. Но вряд ли.
S>Спасибо за совет. Попробую все это рассказать шефу.

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

Советую действовать по такой схеме (все сказаное относится к MS SQL, я так понял вы его используете):

По поводу гипотезы с тормозным запросом:
— открой sql profiler, зацепись к своей базе. Погоняй свое приложение под ним, может быть какой-то определенный запрос занимает много времени. Просто смотри колонки с метриками на предмет аномально больших значений.
— если такой запрос есть — выцепляй его прямо из профайлера в management studio и смотри план запроса — включи в меню query/include actual execution plan, выполни запрос и план выведется. В плане запроса нет никакого матана: смотреть нужно прежде всего какие операции занимают больше всего времени и примерно прикидывать зачем это действие делает база. Например всякие "... scan(99%)" часто говорят о том, что просто индекса какого-нибудь не хватает и субд вынуждена делать перебор.

По поводу гипотезы с блокировками:
— почитай про блокировки и уровни изоляции в books online, или где-нибудь еще. Именно касательно sql-сервера.
— для освоения материала открываешь на какой-нибудь своей базе два окошка, запускаешь в них транзакции с различными уровнями изоляции, наблюдаешь блокировки в activity monitor. Как разберешься хотя бы как увидеть в activity monitor какой процесс что ждет и что заблокировал, может приступать к практике.
— нагружаешь свою систему и смотришь какой процесс подвисает, на каком запросе, какая блокировка ему мешает, кто ее поставил.

Могут еще быть причины, но это — две основные. Если дело действительно в базе.

Здравствуйте, Lloyd, Вы писали:
[...]
объективности похоже ждать не приходится, особенно когда на вопрос тебе приходит встречный вопрос

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

не поможет, уверяю тебя.
Чего-чего? Еще раз и помедленнее.
А чего тогда было не него наезжать-то?
Нет, рано заканчивать. Мне надо убедиться, что вы в достаточной мере знаете возможности linq2sql-а (а не только его дизайнера). А там уже и закончим.
Только потому что дизайнер что-то не поддерживает, вы пишите все руками? Времени своего не жалко что-ли?

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

L>>Конечно, у меня не возникало таких проблем. У нас на проекте есть сложившаяся процедура внесения изменений в схему базы, благодаря которой нет необходимости "убивать всю схему и генерировать снова". Это экономит кучу времени. Рекомендую вам с коллегами сесть как-нить вечерком с пивком и решить раз и навсегда, как по-правильному вносить изменения.
Tom>О, а можно пару слов, про процедуру внесения изменений в схему?

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

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

DШ>объективности похоже ждать не приходится, особенно когда на вопрос тебе приходит встречный вопрос

Все, сдаюсь. В который раз пытаюсь уловить ход твоих мыслей, связать их как-то воедино. Не получается.
Удачи

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

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

Никто никуда не кричит. Тот, кто изменяет схему, обязан изменить и соответствующие entity. Самый простой способ — это внести это изменение вручную в dbml.
не маппер для процедур невозможен, а невозможна генерация типизированного резалтсета для таких процедур.
тем не менее для таких процедур можно вполне успешно использовать маппер, смотри доку по IMultipleResults
Этот недостаток имеется, но при должной дисциплине разработки с ним можно жить. Лучше бы его не было, но что делать.

дизайнером или не дизайнером суть не меняется — это и есть вручную


L>Ссылку, где я такое говорил.
L>Ссылку, где я такое говорил.

вы каждое слово будете вырывать из контекста?

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

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

ps: не подумайте плохо, ведь реально просто интересно, может быть действительно говорю за себя я не умею его готовить?

Здравствуйте, Lloyd!

А киньте плиз пруфлинкой про поддерживание disconnected entities, потому как Бен-Ами придерживается другого мнения: (http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/172ae667-d20a-4dbf-9e98-39b90387b4f4/).

Там же — про проблемы с биндингом.

OakLeaf тоже не верит в disconnected EF: http://oakleafblog.blogspot.com/2008/11/entity-framework-team-abandons-unified.html.


L>У Linq2Sql-овских сущностей точно есть аналог RowChanging, даже что-то с валидацией есть.

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

Спасибо!

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

L>Нет, этот вариант хуже линка, уверяю вас. Маппинг придется реализовывать в ручную. Хотя кому-то это очень нравится (DuШes).
Я предпологал, что тул так же генерирует набор классов, на которые мапятся вызовы стор. Или у вас это не так?

Ещё раз всем спасибо! Тема я смотрю актуальная
Из всего вышеизложенного я понял, что хранимки вместо LINQ не решат проблемы, так как сейчас в текущей системе, которая "неотвечает" используется Reader, а он по сути самый быстрый способ достучаться до БД. Проблема в архитектуре. Индексов, как я понял у нас вообще нет %)
В общем будем вызывать специалиста. Кстати, нет никого желающего? Мы находимся в Миссиссаге, Онтарио, Канада.

S>В общем будем вызывать специалиста. Кстати, нет никого желающего? Мы находимся в Миссиссаге, Онтарио, Канада.
А климат у вас какой? Влажно? И летом/замой какая температура?

Если индексов нет то конечно всё будет тупить. Просто вам нужен человек более менее имебщий опыт разработки приложений связанных с БД.

Здравствуйте, Tom, Вы писали:
Tom>А климат у вас какой? Влажно? И летом/замой какая температура?

Климат сухой. Зима была зимой. До -20. Сейчас от +15 до -5. Летом обещают тепло.

Tom>Если индексов нет то конечно всё будет тупить. Просто вам нужен человек более менее имебщий опыт разработки приложений связанных с БД.

Нужен. Шеф у нас такой Но он уже не разрабатывает, он зарабатывает

S>Нужен. Шеф у нас такой Но он уже не разрабатывает, он зарабатывает
Давай в оффлайн, у тебя есть icq/skype/msn? Отпиши на tom@rsdn.ru

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

IB>Если есть DAL, то где конкретно находятся запросы для квалифицированного разработчика — фиолетово. Для стажеров — жестко, только хранимки.

Надеюсь, вы пошутили

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

DШ>Здравствуйте, Lloyd, Вы писали:

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

DШ>

DШ>Никто никуда не кричит. Тот, кто изменяет схему, обязан изменить и соответствующие entity. Самый простой способ — это внести это изменение вручную в dbml.
DШ>не маппер для процедур невозможен, а невозможна генерация типизированного резалтсета для таких процедур.
DШ>тем не менее для таких процедур можно вполне успешно использовать маппер, смотри доку по IMultipleResults
DШ>Этот недостаток имеется, но при должной дисциплине разработки с ним можно жить. Лучше бы его не было, но что делать.

DШ>дизайнером или не дизайнером суть не меняется — это и есть вручную

Так вот, что вы имели в виду. Вы оказывается, dbml называете кодом, а автоматической генерацией называете процедуру перетаскивания всех таблиц в дизайнер или то, что получается при первоначальном создании dbml-я по базе. Я вас правильно понял?

Теперь что по поводу "реализовывать трекинг вручную"?

L>>Ссылку, где я такое говорил.
L>>Ссылку, где я такое говорил.

DШ>вы каждое слово будете вырывать из контекста?

Для начала, если оставляете цитату собеседника, оставляйте достаточное кол-во текста, чтобы читающему можно было понять, о чем идет речь. Ок?
Во-вторых, цитату, где я говорил про то, что "мой" дизайнер "понимает логику в хранимых процедурах" и "генерирует классы-врапперы над результати работы хранимки", я хотел бы все-таки увидеть.

DШ>вопрос был:
DШ>вообщем, как я понимаю, ваш linqtosql дизайнер, именно ваш, потому что мой не умеет, настолько умный, что понимает логику в хранимых процедурах и за вас генерирует классы-врапперы над результати работы хранимки...или как?

DШ>просто поделитесь опытом ну как вы работаете с хранимками, пока только слова в защиту того, какой маппер хороший и какие есть возможности в linqtosql, просто из контекста я понял, что у вас все так хорошо, что вы и дизайнер используете и маппинг из процедуры на классы и их автогенерацию...

Объявляешь вот такой метод:

[Function(Name = "dbo.CustOrderHistTwice")]
[ResultType(typeof(CustOrderHistResultEntry))]
public IMultipleResults CustOrderHistTwice([Parameter(Name = "CustomerID", DbType = "NChar(5)")] string customerID)
{
    IExecuteResult result = ExecuteMethodCall(this, (MethodInfo)MethodInfo.GetCurrentMethod(), customerID);
    return (IMultipleResults)result.ReturnValue;
}

Здесь процедура CustOrderHistTwice возвращает 2 резалтсета.

Использовать во так:

DataClasses1DataContext ctx = new DataClasses1DataContext();
var result = ctx.CustOrderHistTwice("CACTU");
foreach (var hist in result.GetResult<CustOrderHistResultEntry>())
{
    Console.WriteLine(new { hist.ProductName, hist.Total });
}
Console.WriteLine("==============");
foreach (var hist in result.GetResult<CustOrderHistResultEntry>())
{
    Console.WriteLine(new { hist.ProductName, hist.Total });
}

И все.

Как видишь, никакой магии и правки руками. Только стандартный функционал.