EF 4.1 N Уровень ASP. Чистая путаница

Question

Я надеюсь, что вы можете помочь мне с любым советом, он будет очень признателен.

Я уже некоторое время пользуюсь EF 4.0, используя следующую технику управления контекстом объекта http://dotnetslackers.com/articles/ado_net/Managing-Entity-Framework-ObjectContext-lifespan-and-scope-in-n-layered-ASP-NET-applications.aspxУ меня довольно простая настройка с веб-проектом, подключенным к BLL, подключенному к DAL.Сеть и BLL ссылаются на объекты DAL.Он работал нормально, но, кажется, очень медленно.Это приложение ASP .NET Webforms, которое использует существующую модель базы данных (т. Е. Сначала не код) и указывает на БД SQL Server 2005.

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

Сайт представляет собой серию страниц с цитатами по страхованию автомобилей.Теперь я надеюсь создать соответствующие объекты в сеансе, т. Е. На странице 1 создать объект цитаты, заполнить поля, на странице 2, добавить X дополнительных драйверов, на странице 3 добавить претензии / осуждения, а затем сохранить объекты в базе данных.Пользователи смогут сохранять и выходить в любой момент процесса цитаты, поэтому сохранение не всегда будет в конце.Нам также необходимо иметь возможность загружать информацию страницы 1 и обновлять ее в памяти, когда они нажимают кнопку Далее, и, наконец, обновлять базу данных, когда они готовы завершить кавычку.

В данный момент мы выполняемвосстановить и сохранить на той же странице.Как бы вы посоветовали нам перейти к сохранению в сеансе / финальном коммите?

Я пробежался по разным страницам msdn, и у меня возникли проблемы с объединением всего этого в последнюю «лучшую практику» для 4.1 для этогодовольно простое приложение.Я посмотрел видео Джули Лерман, но ее n'tier сделал только простое извлечение и «Добавить», подозрительно пропуская раздел «Обновление», так как подозреваю, что это не так просто.Как вы думаете, я должен использовать Self Tracking Entities (я читал, что у людей есть несколько проблем с этим, но, возможно, их архитектура более сложна?) Или каким-то другим способом хранения объектов EF в сеансе и внесения изменений

Любая помощь / идеи с благодарностью.

Answer 1

Хранение данных в сеансе может быть эффективным методом минимизации ввода-вывода, но это не простое решение.Вам не следует помещать большие объемы данных в состояние сеанса, и мы не можем определить из вашего описания, о каком объеме данных вы говорите, или о количестве одновременных активных сеансов.

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

Если вы используете веб-ферму, вам придется использовать общее состояние сеанса, возможно, с использованием поставщика состояния сеанса SQL Server, так что вы будете в конечном итоге выполнять чтение и запись в базу данных при каждом взаимодействии, что может быть хуже.

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

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