Статическая?Хранилища MVC3, EF4.2 (Code First) - PullRequest
0 голосов
/ 18 ноября 2011

Я новичок в MVC, EF и т. Д., Поэтому я последовал руководству по MVC3 на http://www.asp.net/mvc и настроил приложение (хотя еще не закончил со всем).

Вот "архитектура" моего приложения до сих пор

  • GenericRepository
  • PropertyRepository наследует GenericRepository для объекта "Property"
  • HomeController который имеет PropertyRepository в качестве члена.

Пример:

public class HomeController
{
    private readonly PropertyRepository _propertyRepository 
          = new PropertyRepository(new ConfigurationDbContext());
}

Теперь давайте рассмотрим следующее:

У меня есть метод в моем GenericRepository, который занимает довольно много времени, вызывая 6 запросов, которые должны быть в одной транзакции для поддержания целостности. Мои результаты поиска в Google показывают, что SaveChanges () рассматривается как одна транзакция - поэтому, если я внесу несколько изменений в свой контекст, а затем вызову SaveChanges (), я могу быть «уверен», что эти изменения «атомарны» на SQL Server , Правильно? Неправильно?

Кроме того, есть метод действия, который вызывает _propertyRepository.InvokeLongAndComplex() Метод. Я только что узнал: MVC создает новый контроллер для каждого запроса. Таким образом, я получаю несколько PropertyRepositories, которые портят мою целостность базы данных. (Я должен поддерживать связанный список моих свойств в базе данных, и если пользователь перемещает свойство, ему нужно 6 шагов, чтобы соответствующим образом изменить список, но таким образом я избегаю циклического прохождения всех сущностей при наличии тысяч ...)

Я думаю о том, чтобы сделать GenericRepository и PropertyRepository статичными, поэтому каждый HomeController использует один и тот же репозиторий и синхронизирует метод InvokeLongAndComplex, чтобы убедиться, что только один поток вносит изменения в БД одновременно .

У меня есть подозрение, что эта идея не является хорошим решением, но я не могу найти подходящее решение для этой проблемы - некоторые ребята говорят, что нормально иметь статические репозитории (хотя что происходит с контекстом?). Некоторые другие ребята говорят, что используют IOC / DI (?), Что походит на большую работу по настройке (даже не уверен, решит ли это мою проблему ...), но кажется, что я мог бы «сказать» контейнеру всегда «вводить» «тот же объект контекста, тот же репозиторий, и тогда будет достаточно синхронизировать метод InvokeLongAndComplex(), чтобы не допустить, чтобы несколько потоков испортили целостность.

Почему хранилища данных не статичны? Ответ 2:

2) Вы часто хотите иметь 1 экземпляр репозитория на запрос, чтобы упростить гарантию того, что незафиксированные изменения от одного пользователя не испортят ситуацию для другого пользователя.

почему экземпляр хранилища для каждого запроса не портит мой связанный список?

Может ли кто-нибудь дать мне совет или поделиться лучшей практикой, которой я могу следовать?

1 Ответ

1 голос
/ 18 ноября 2011

Нет! У вас должен быть новый контекст для каждого запроса , поэтому даже если вы сделаете ваши репозитории статичными, вам придется передавать текущий экземпляр контекста каждому его методу вместо того, чтобы поддерживать один контекст внутри репозитория.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...