Не знаете, как использовать Dependency Injection + Repository Pattern + Unit of Work Pattern с приложением WinForm
(извинения за стену текста...:))
Резюме
Использование 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, и каждый репозиторий также требует
один.., который означает, что новый создается для каждого из них.
Я уверен, что я не правильно структурировал это...
Любые предложения были бы искренне благодарны!
Ответы
Ответ 1
В этой статье Айенде вы можете получить представление о том, как управлять своим подразделением в настольном приложении (общая идея состоит в том, чтобы использовать "сеанс для ведущего" ): http://msdn.microsoft.com/en-us/magazine/ee819139.aspx