Entity Framework 5: Использование ленивых загрузок или ускоренная загрузка

Question

Прошу прощения, если мой вопрос нормальный. Но я встречаю эту проблему, когда я разработка ASP.NET MVC моего 4.0 приложения с использованием Entity Framework 5.

Если я выбираю жадную загрузку, я просто упростить с помощью:

public Problem getProblemById(int id) { 
using(DBEntity ctx = new DBEntity()) 
      { 
       return (Problem) ctx.Posts.Find(id); 
      } 
} 

Но если я использую жадную загрузку, я столкнутся с проблемой: когда я хочу перемещаться по всем ее атрибутам, таким как комментарии (проблемы), User (of Problem) ... Я должен вручную использовать Include, чтобы включить эти свойства. и иногда, если я не использую эти свойства, я потеряю производительность, и, возможно, я потерял силу Entity Framework.

Если я использую Lazy Loading. Существует два способа использования объекта DBContext. Первый способ использует объект DbContext локально:

public Problem getProblemById(int id) { 
DBEntity ctx = new DBEntity(); 
return (Problem) ctx.Posts.Find(id); 
} 

Используя это, я думаю, что будет соответствовать утечка памяти, потому что CTX никогда не выбрасывайте снова.

Второй способ сделать DbContext объект статический и использовать его во всем мире:

static DBEntity ctx = new DBEntity(); 
public Problem getProblemById(int id) { 
return (Problem) ctx.Posts.Find(id); 
} 

Я читал некоторые блог, они говорят, что, если я использую этот путь, я должен контролировать доступ параллелизмом (поскольку мульти запрос отправляет на сервер) сам, OMG. Например, эта ссылка:

Entity Framework DBContext Usage

Итак, как спроектировать мое приложение, пожалуйста, помогите мне разобраться.

Спасибо :)

Answer 1

Не используйте статический DBContext объект. См. c# working with Entity Framework in a multi threaded server

Простое правило для ASP.Net MVC: используйте экземпляр DBContext для каждого запроса пользователя.

Что касается использования отложенной загрузки или нет, я бы сказал, это зависит , но лично я бы отключить отложенную загрузку. IMO это сломанный особенность, потому что существуют фундаментальные проблемы, связанные с ней:

• слишком трудно обрабатывать исключения, потому что запрос SQL может не в любом месте в коде (а не только в DAL потому что один разработчик может получить доступ к навигационному собственности в любой кусок кода)
• плохие выступления, если не хорошо использовать
• слишком легко писать сломанный код, который производит тысячи SQL запросов