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

EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

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

VC>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

А вы продолжайте вручную выпиливать "select * from ...", склеивать строки и заниматься "... and (@p is null or foo.Bar = @p) ...".

Здравствуйте, Нахлобуч, Вы писали:

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

VC>>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

Н>А вы продолжайте вручную выпиливать "select * from ...", склеивать строки и заниматься "... and (@p is null or foo.Bar = @p) ...".

Linq2DB достаточен для работы с БД.

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

С>Здравствуйте, Нахлобуч, Вы писали:

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

VC>>>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

Н>>А вы продолжайте вручную выпиливать "select * from ...", склеивать строки и заниматься "... and (@p is null or foo.Bar = @p) ...".

С>Linq2DB достаточен для работы с БД.

Редкая штучка. Кроме google.com ее даже нигде не видно.

Здравствуйте, Нахлобуч, Вы писали:

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

VC>>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

Н>А вы продолжайте вручную выпиливать "select * from ...", склеивать строки и заниматься "... and (@p is null or foo.Bar = @p) ...".

Select если он красивый как обычно и понятный, то не вычищаю. Кто не понимает sql есть книжки 15-ти летней давности.

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

VC>Весь критический по требованиям производительности тормозам код приходится переписывать выкидывать с помощью Dapper.

VC>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

Покажи код чтоли.

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

С>Linq2DB достаточен для работы с БД.

Прекрасно, конечно, но речь тут про EF.

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

VC>Select если он красивый как обычно и понятный, то не вычищаю. Кто не понимает sql есть книжки 15-ти летней давности.

Вот это -- это красивый SQL?

select * from Employee e
where
  (@lastName is null or e.LastName = @lastName)
  and (@firstName is null or e.FirstName = @lastName)
  and (@employmentDateFrom is null or e.EmploymentDate >= @employmentDateFrom)
  and (@employmentDateTo is null or e.EmploymentDate <= @employmentDateTo)

И тут есть ошибка; возможно, что и не одна.

А что вы делаете с "некрасивым и непонятным"?

Здравствуйте, Нахлобуч, Вы писали:

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

VC>>Select если он красивый как обычно и понятный, то не вычищаю. Кто не понимает sql есть книжки 15-ти летней давности.

Н>Вот это -- это красивый SQL?

Н>

Н>select * from Employee e
Н>where
Н>  (@lastName is null or e.LastName = @lastName)
Н>  and (@firstName is null or e.FirstName = @lastName)
Н>  and (@employmentDateFrom is null or e.EmploymentDate >= @employmentDateFrom)
Н>  and (@employmentDateTo is null or e.EmploymentDate <= @employmentDateTo)
Н>

Н>И тут есть ошибка; возможно, что и не одна.

Н>А что вы делаете с "некрасивым и непонятным"?

тут две ошибки.
1. or e.FirstName = @lastName
2. архитектурная ошибка или не знание бизнеса: обычно имплаии мало и все они вмещаются в память. надо * from Employee грузить в кэш и фильтровать в памяти. Но не в БД. На трехзвенке — гарантирую 100%.

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

VC>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.
Открыл для себя, что серебряной пули нет? Поздравляю. У каждой технологии есть свои границы применимости.

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

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

VC>Весь критический по требованиям производительности тормозам код приходится переписывать выкидывать с помощью Dapper.

VC>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

.NET не нужен

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

VC>тут две ошибки.
VC>1. or e.FirstName = @lastName
VC>2. архитектурная ошибка или не знание бизнеса: обычно имплаии мало и все они вмещаются в память. надо * from Employee грузить в кэш и фильтровать в памяти. Но не в БД. На трехзвенке — гарантирую 100%.

Как вы потом этот кэш будете обновлять?

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

VC>Весь критический по требованиям производительности тормозам код приходится переписывать выкидывать с помощью Dapper.

VC>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

Не первый раз слышу такие заявления. А в чём причина этого? Неэффективный SQL генерируется? Маппинг SQL <-> Object медленный?

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

VC>2. архитектурная ошибка или не знание бизнеса: обычно имплаии мало и все они вмещаются в память. надо * from Employee грузить в кэш и фильтровать в памяти. Но не в БД. На трехзвенке — гарантирую 100%.

Ну приехали. БД с кэшированием (в том числе и с поддержанием его актуальности) справится в разы лучше, чем всё самописное. Плюс, даже если допустить, что мы что-то там кэшируем, где критерии определения "мало-много"? 100 сотрудников? 1 000? 100 000?

И вы так и не ответили, был ли это красивый SQL и что делать с некрасивым.

Здравствуйте, Нахлобуч, Вы писали:

Н>Прекрасно, конечно, но речь тут про EF.

Ну так выкидываем EF и переходим на linq2db.

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

VC>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

Верно. Поэтому ведущие собаководы используют linq2db.

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

Н>>И тут есть ошибка; возможно, что и не одна.

VC>тут две ошибки.
VC>1. or e.FirstName = @lastName
А select * и неустойчивый план это нормально?

VC>2. архитектурная ошибка или не знание бизнеса: обычно имплаии мало и все они вмещаются в память. надо * from Employee грузить в кэш и фильтровать в памяти. Но не в БД. На трехзвенке — гарантирую 100%.
Ну и бред...

Тебе рановато EF ругать.

Здравствуйте, Ночной Смотрящий, Вы писали:

VC>>EntityFramework не нужен. Кто будет спорить тот или нехорошо себя ведёт, или sql-код писАть не умеет.

НС>Верно. Поэтому ведущие собаководы используют linq2db.

Я маленько отстал от жизни, сейчас BLToolkit уже неактуален, морфировал в linq2db?

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

ARK>Я маленько отстал от жизни, сейчас BLToolkit уже неактуален, морфировал в linq2db?

Yep. Хотя если ты старые сопли из blt использовал типа аксессоров и всяких ExecuteXxx, то в l2db их нет. По идеологическим мотивам.

Здравствуйте, Ночной Смотрящий, Вы писали:

ARK>>Я маленько отстал от жизни, сейчас BLToolkit уже неактуален, морфировал в linq2db?

НС>Yep. Хотя если ты старые сопли из blt использовал типа аксессоров и всяких ExecuteXxx, то в l2db их нет. По идеологическим мотивам.

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