- 1
- 2
- 3
- 4
- 5
str_sql = " select convert(varchar(6),e.id) as equipment_id,e.name as name,1 as is_check " +
" ,(select count(t2.id) from equipment t2 where t2.parent_id=e.id) count_child" +
" from equipment e " +
" where isnull(e.parent_id,0)=" + e.Node.Value +
" and id in (select cod from f_DisplayEqipmentContract_nodes_2(" + str_contract + "))";
С собачкой (@)? То же самое. (Ну, правда, str_sql получится в несколько строк).
2) нет защиты от sql-injection
Нет. Абсолютно одинаковый IL-код на выходе.
просто желаение везде юзать linq2sql в 80% случаев связано с нежеланием аффтара изучать SQL, и со святой верой что linq2sql сгенерит самый лучший запрос.
обычно это кончается тормозящими приложениями
Зато он позволяет оперировать более высокоуровневыми вещами, нежели сам SQL. И мапит результаты в объекты автоматически.
В данном случае у нас есть запрос. Все, что нужно сделать, это переделать его на биндинг через ADO.NET (что бы избежать sql injection например) и заменить подзапросы на внутренние джойны.
Позиция "с базой всегда работаем через linq2sql" кажется мне не верной. Слишком уж много я видел веб-приложений, ставящих сервера раком из за того, что один заход на сайт вызывает до тридцати запросов с поздзапросами.
Linq2SQL плох еще тем, что провоцирует программиста не выделять этот код в DAO.
Linq запросы кажутся программисту чем-то высокоуровневым, и потому их часто можно встретить в контроллере MVC.NET например.
Это делает код нетестируемым.
Кстати, а у Вас есть примеры хороших приложений, работающих на linq2sql?
В простых случиях, запрос типа "var a = from u in da.Users order by u.name select a" будет что с linq, что без него выглядеть совершенно одинаково. Но создавать отдельную процедуру я не вижу смысла, как и писать открытый SQL-код в проекте.
Тогда зачем усложнять его переделкой на linq, когда запрос уже готов?
ситуация, когда часть запросов хранится ввиде linq, а другая часть ввиде хранимок -- ужасна.
Попробую объяснить. В программировании есть такое понятие -- "cohesion". Смысл его в том, что определенного типа знания должны быть рядышком. Например если у Вас есть логика вычисления длины хвоста страуса -- то она должна быть в одном классе.
Если она тонко размазана по всему проекту, то это очень плохо. Во-первых ее тяжело протестировать. Во-вторых ее тяжело изменить.
Потому обычно шаблоны стараются держать в одном месте, логику -- в другом, доступ к БД -- в третьем.
В Вашем случае запросы частично лежат в хранимках, частично генерятся на лету, причем наверняка из разных мест (скажите честно -- у Вас есть интерфейс типа DAO?).
Это и кажется мне не очень красивым решениесм
Кроме того SQL код уж точно не выйдет за пределы DAO.
В идеальном варианте конечно хранимки на стороне бд, но это , увы, не всегда возможно.
Но представьте себе два совершенно одинаковых запроса, различающихся типом джойна (внешним и внутренним). Хранимки тут вызовут копипаст.
Кстати, как бы Вы порешали это в linq?
1) TypedDataSet
2) Linq2SQL
3) Entity Framework
тогда начерта Вам linq?