(извинения за стену текста...:))
Резюме
Использование Dependency Injection с моим приложением Winfor создает большое количество Контекстов репозитория. Я не уверен, правильно ли я это использую, или что такое обычная практика.
Подробнее
За последние 6 месяцев я делал приложения ASP.NET MVC, которые влияют на шаблон Unit O FWork с шаблоном репозитория. Кроме того, я с успехом использовал Injection Dependency для всех этих веб-приложений.
Итак, это пример того, как я подключаю свой репозиторий.
public EntityFrameworkRepositoryRegistry()
{
For<IUnitOfWork>()
.HybridHttpOrThreadLocalScoped() // Lifecycle of the object.
.Use<SqlServerContext>() // My EF Context.
.Ctor<string>("connectionString").Is("name=SqlServer_EF")
.Ctor<string>("defaultContainerName").Is("Entities");
// Ayende EFProf application :)
EntityFrameworkProfiler.Initialize();
Scan(x =>
{
x.TheCallingAssembly();
x.ExcludeNamespaceContainingType<Fake.FakeContext>();
x.WithDefaultConventions();
}
);
}
Хорошо - отлично работает. Главное здесь отметить, что
- Я предполагаю, что жизненный цикл является правильным для веб-сценария.
- Контекст будет существовать только один раз, по запросу, который попадает в веб сервер.
Kewl.
Теперь, для моего приложения WinForm, я изначально создал сингл Объект "Единица работы" (пока еще нет инъекции зависимостей) и продолжал передавать этого ребенка вокруг все сервисы (а затем в хранилища).
Для этого приложения win он попадает в БД, чтобы узнать весь текст файлы, которые необходимо проанализировать. (например, 25 файлов). Затем для каждого файла это создает новый Parser, читает каждую строку и забивает проанализированные данные в таблица db. Хорошо.
Проблема заключалась в том, что этот текст был разделен среди ВСЕХ Парсеров, что серьезно всплывал ошибок по всему магазину.
Итак, я добавил некоторые инъекции зависимостей и использовал этот код реестра выше. Сорта же - много серьезных ошибок. Это связано с тем, что для одного потока → winform снова создан один контекст.
Итак, теперь я изменил реестр контекста следующим образом: -
public EntityFrameworkRepositoryRegistry(bool isForTheWeb)
{
if (isForTheWeb)
{
For<IUnitOfWork>()
.HybridHttpOrThreadLocalScoped()
.Use<SqlServerContext>()
.Ctor<string>("connectionString").Is("name=SqlServer_EF")
.Ctor<string>("defaultContainerName").Is("Entities");
}
else
{
For<IUnitOfWork>()
.Use<SqlServerContext>()
.Ctor<string>("connectionString").Is("name=SqlServer_EF")
.Ctor<string>("defaultContainerName").Is("Entities");
}
EntityFrameworkProfiler.Initialize();
Scan(x =>
{
x.TheCallingAssembly();
x.ExcludeNamespaceContainingType<Fake.FakeContext>();
x.WithDefaultConventions();
});
}
Итак, для приложения WinForm он не устанавливает Lifecycle. Эта а затем создал около 160 или около того контекста, я думаю! (Но это на самом деле не ошибка).
Итак, я не уверен, что это правильный способ сделать что-то.
Итак, у моего приложения, по сути, есть 25 разных таймеров, чтобы проверить файл каждый.. сказать.. 10 секунд. Если есть новые данные, он анализирует его. В противном случае вернитесь через 10 секунд.
Если каждый из этих файлов обрабатывается, будь то собственный поток? а затем создать контекст для потока? (что я чувствую, похоже на веб-сценарий). Или это прекрасно? Я знаю это много контекста, но каждый контекст не означает живое соединение с db.. и с пул соединений, это не должно быть проблемой.
Причина, по которой он имеет множество контекстов, заключается в следующем: кода... (и это отдельные конструкторы для некоторых из Классы репозитория...)
public SqlServerContext(string, string);
public GameFileRepository (IUnitOfWork);
public LogEntryRepository(IUnitOfWork);
public AlertRepository(IUnitOfWork);
... etc..
и для основной службы...
public PunkBusterParser(IUnitOfWork, IGameFileRepositry,
ILogEntryRepository, ILoggingService);
поэтому для службы требуется UoW, и каждый репозиторий также требует один.., который означает, что новый создается для каждого из них.
Я уверен, что я не правильно структурировал это...
Любые предложения были бы искренне благодарны!