Entity Framework в корпоративном решении - PullRequest
Новая
       61

Entity Framework в корпоративном решении

2 голосов
/ 26 августа 2011

Сегодня я предоставил свои услуги нашему правлению. У них были некоторые опасения по поводу Entity Framework (особенно руководителя группы данных).

Это были две основные проблемы:

  1. Поскольку EF генерирует SQL на лету, он открыт для атак SQL-инъекций (при использовании через службы WCF и службы данных WCF).
  2. Будет ли EF масштабироваться для поддержки ситуаций высокой нагрузки, не становясь "медленным пятном" на пути?

Я вполне уверен в # 1. ) Если бы EF был открыт для атак с использованием SQL-инъекций, думаю, я бы об этом услышал.) Но мне бы понравилось что-то от MS, которое говорит, что входные данные из Data Contracts sanitized . (Вроде как хранимая процедура (которая не использует динамический SQL в sproc).)

Что касается # 2, я не уверен. Когда я начну получать большое количество обращений к моим сервисам на основе EF, будет ли EF вызывать у меня горе?

Ответы [ 4 ]

4 голосов
/ 26 августа 2011
  1. Вероятность внедрения SQL с EF меньше, чем с написанным вручную SQL.
  2. Простого ответа на этот вопрос нет.«Ситуации с высокой нагрузкой» слишком расплывчаты, чтобы кратко ответить.В общем, чем больше масштаб, тем меньше любое решение «один размер подходит всем».Как всегда, отмерь дважды, отрежь один раз.
3 голосов
/ 26 августа 2011

Просто запустите профилировщик и проверьте, какие запросы выдает EF.Вы увидите параметризованные запросы, которые являются основной защитой от внедрения SQL.Таким образом, ни один EF не открыт для инъекционных атак, но если вы используете EntitySQL и объединяете строки вручную, вы можете проводить инъекционные атаки на более высоком уровне.

Конечно, EF снижает производительность.Это компромисс между простой и быстрой разработкой, когда разработчикам не нужно иметь слишком много знаний о внутренних процессах / технологиях для создания приложения (в случае многих инструментов MS, обезьянка может создать приложение, но производительность и другие измерения качества будутбыть адекватным).

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

В случае DataServices это может быть более сложным.Клиент может запустить сложный запрос, который просто займет много времени, и вы не можете контролировать этот запрос.Некоторой защитой от этого является ограничение количества возвращаемых / запрашиваемых записей на уровне обслуживания.Если пользователь хочет больше записей, он должен указать более подробные критерии поиска.

3 голосов
/ 26 августа 2011

Я согласен с Крейгом.Они доверяют рукописному SQL больше, чем SQL, сгенерированному таким большим инструментом от Microsoft?Честно говоря, если в EF нет странной ошибки, внедрение SQL невозможно, потому что EF всегда генерирует параметризованные запросы.Другими словами, их аргумент - просто волы.

И для # 2 EF не будет медленной точкой, это всегда будет ваша база данных, потому что вы можете масштабировать свой веб-сервис с EF на несколькихсерверы, без особых проблем большую часть времени.Однако масштабирование вашей базы данных - совершенно другая игра с мячом.Однако я должен сказать, что O / RM могут легко генерировать «неоптимальные» SQL-запросы, которые иногда сложно настроить.Администраторы не всегда будут довольны этим.Однако, по моему опыту, почти всегда можно настроить эти запросы SQL (переписав запросы LINQ).Я сделал это много за последние несколько месяцев, и иногда это может быть довольно сложно.В том редком случае, когда вы не можете оптимизировать на стороне .NET достаточно, вы всегда можете вернуться к индексированному представлению, хранимой процедуре или ручному SQL, но это должно быть редко.

1 голос
/ 26 августа 2011

Для # 2 всякий раз, когда вводится абстракция, это будет компромиссом с производительностью.Является ли это важным для вас или нет, может быть определено только тестированием производительности и профилированием в вашей ситуации.Прочтите этот пост о том, почему для SO, чтобы дать вам идею, потребовался пользовательский ORM Dapper .У Dapper также есть набор тестов производительности , который вы можете использовать для определения степени влияния EF на ваши типичные запросы.

Существует также # 3.Некоторые функции SQL по-прежнему не поддерживаются EF, и это может ограничить ваш дизайн.например, Ограничения уникального ключа пока не поддерживаются.

EF все еще развивается и следите за блогом команды ADO.Net.

...