Выбор дизайна: Entity Framework против Raw SQL

Question

Я пишу приложение Silverlight для обработки миллионов записей.Поскольку нагрузка на сервер может быть довольно большой, я намерен перенести часть обработки на клиентскую сторону.Например, если мне нужно показать полную информацию о книге и ее авторе, я бы хотел присоединиться к таблице книг и таблице авторов, используя AuthorID в качестве общего ключа.Вместо того, чтобы выполнять JOIN на стороне сервера, я бы извлекал таблицу Author отдельно и таблицу Book отдельно и соединял их на стороне клиента с помощью кода C # и отображал их в DataGrid.

Клиенты находятся в контролируемой средетак что есть минимальная гарантия их выполнения.Поскольку существует так много записей и поскольку в DataGrids на стороне клиента не происходит никаких обновлений, я бы выбрал Raw SQL вместо Entity Framework.Однако существует проблема создания соединения на стороне клиента.Мой вопрос заключается в том, поможет ли Entity Framework облегчить присоединение на стороне клиента?Считайте, что время разработки здесь не является существенным фактором.

Answer 1

Я не знаю, что такое Entity Framework и Raw SQL, но рассматривали ли вы вопрос об использовании Microsoft Cache Application Block с кэшем резервного хранилища ?

Это будет кешироватьданные локально - что-то вроде того, что вы вы ищете.

Answer 2

Я бы лично согласился с вашим выбором для использования необработанного SQL в этом случае, по крайней мере, исходя из того, что я прочитал в вашем посте.Вам нужен как можно более «быстрый» доступ и быстрое достижение цели, очень зависит от вашего приложения.Таким образом, вы можете настроить именно то, что вы хотите в месте, где вы хотите.

Я говорю даже о стороне клиента, где вы хотите выполнять объединения, учитывая, что вы написали: «Время разработки здесь не является существенным фактором».

Так что я личноголосовать за Raw SQL.

С уважением.

Answer 3

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

Что касается Raw SQL против Entity Framework - если вы решите фильтровать данные на сервере и вам необходимо выполнить специальную оптимизацию - переходите к необработанному SQL, так как это оченьменее ограничен.В противном случае перейдите с Entity Framework.

Answer 4

Мой вопрос: поможет ли Entity Framework облегчить присоединение на стороне клиента?

Вопрос в том, кто разрабатывает приложение.Использование структуры сущности определенно имеет свои преимущества.Он дает разработчикам возможность писать «похожий» синтаксис T-SQL в C # или другой среде .NET, но он обладает той же эффективностью выполнения SQL через библиотеки SQL, которые уже существуют в .NET.

Полегче?Может быть.Более эффективным?Я сомневаюсь.Обычно вы хотите выполнять JOINS и тому подобное в хранимых процедурах на стороне сервера, только потому, что база данных обычно хранится на другом компьютере, так почему один компьютер обслуживает веб-сайт И выполняет необходимые вам манипуляции с данными?

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