2013-04-12 2 views
0

Проект, над которым я работаю, имеет множество шаблонов для передачи объектов репозитория. Родительский объект создает репозиторий, передает его любым методам утилиты/помощника для выполнения определенной работы, а затем в конце родительский объект вызывает фиксацию или сохранение в репозитории. И много раз эти утилиты/вспомогательные методы вызывают другие методы, которые также требуют репозитория. Во-первых, мы определенно используем шаблон репозитория неправильно, поскольку многие из этих вспомогательных методов действительно используют репозитории как DAO или даже просто соединение с БД, запускают быстрый запрос и выполняются с ним. Мой вопрос заключается в том, что лучший способ избежать передачи этих репозиториев?Правильный (лучший) способ регистрации и извлечения репозиториев в C#

Самый примитивный способ - создать хранилища в этих вспомогательных методах, затем уничтожить их (используя клаузулы), и есть очевидные недостатки, и это против DRY.

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

Учитывайте безопасность резьбы.

Каковы мнения экспертов по этому вопросу? Любой пример будет высоко оценен.

PS. Я старший парень Java, но почти начальный уровень на C#, поэтому любое сравнение, связанное с Java, тоже было бы замечательным.

+1

У Роба Кониера был хороший пример IRepository, из которого я обманул. Когда вы его используете, вам все равно придется называть {IRepository} .CommitChanges(); или что-то еще, но оно работает хорошо. В Интернете вы будете регистрировать время жизни IRepository как InRequestContext() [из Ninject] или аналогично, но в WinForms вы будете управлять этим вручную, самостоятельно. –

+0

А, это именно то, о чем мне было интересно. У .NET есть довольно много интересных механизмов для создания репозиториев для сценария для каждого запроса, но я вроде бы надеялся, что вы можете сделать то же самое с WinForms, по крайней мере, для случаев, когда Repo используется как DAO, в статике, подобной путь. Я буду продолжать охоту ... Thx – BZapper

+0

Если пример репозитория - это тот, который из видеороликов Rob (теперь довольно старый), то это пример BAD, главным образом потому, что он был просто простой оболочкой над Entity Framework, подвергая IQueryable – MikeSW

ответ

2

«правильный» способ регистрации и получение Хранилища с DI контейнером (я рекомендую Autofac

builder.RegisterType<MyRepository>().AsImplementedInterfaces().InstancePerLifetimeScope(); 

InstancePerLifeTimeScope означает, что это нить области видимости, так только один экземпляр для каждого потока. Каждый объект нуждается в хранилище будет имеют интерфейс репозитория как зависимость конструктора. Для некоторых служб репозиторий может быть аргументом метода.

Репозиторий будет использовать (микро) ORM для «разговора» с базой данных. В некоторых случаях вам нужны данные или даже некоторые cts, которые могут быть получены непосредственно из db. В этом случае у вас есть служба, а не репозиторий, хотя обе реализации (а не интерфейсы) принадлежат DAL.

Я предполагаю, что все службы и репозитории передаются как абстракции, поэтому каждый объект, нуждающийся в обслуживании или репозитории, будет знать только об IService или IRepository. Контейнер DI будет вводить конкретные типы, объекты клиента не должны знать об этом.

+0

попытке этого, спасибо заранее! – BZapper

Смежные вопросы