Я не совсем уверен, в чем проблема, которую вы пытаетесь решить, но я не думаю, что ваш дизайн будет работать в долгосрочной перспективе. Однако для меня ясно, что у вас большой домен, и вы хотите иметь возможность внедрять IRepository<T>
экземпляры в классы обслуживания, но хотите воспользоваться преимуществами регистрации пакетов и генератора кода Entity Framework, чтобы вы не могли необходимость поддерживать много кода, что является замечательной целью.
Однако вы пытаетесь внедрить IRepository<T>
экземпляров в службы. Хотя репозиторий является распространенным шаблоном проектирования, внедрение репозиториев непосредственно в сервисы никогда не работало для меня и кажется странным в контексте Entity Framework, который использует шаблон единицы работы (ObjectContext
) для централизации операций между приложением и базой данных. Внедрение репозиториев означает, что под каждым репозиторием должно быть указано ObjectContext
, и вы, вероятно, хотите иметь одинаковые ObjectContext
во всех экземплярах репозитория, которые вы внедряете в одной службе, потому что ваши операции, вероятно, должны быть атомарными.
IMO, было бы лучше не внедрять IRepository<T>
экземпляров в ваши сервисы, а внедрять UnitOfWork
или даже лучше: IUnitOfWorkFactory
. IUnitOfWorkFactory
может затем создать новый экземпляр UnitOfWork
(который служба должна утилизировать после завершения), а UnitOfWork
будет содержать список IRepository<T>
экземпляров и содержать метод SubmitChanges
.
Внедрив метод IRepository<T> GetRepository<T>()
в UnitOfWork
, вы можете эффективно получить конкретный репозиторий без необходимости какой-либо регистрации пакета, как обычно, чтобы подключить ваши 100 репозиториев. Это можно сделать внутри реализации IUnitOfWork
.
С точки зрения приложения было бы еще лучше, если бы UnitOfWork
содержал свойства для конкретных реализаций IRepository<T>
, таких как public IRepository<Customer> Customers { get; set; }
, но это означает, что вам нужно будет добавлять новые свойства, когда новые сущности добавляются в система, которая, вероятно, не то, что вам нравится. Однако, по моему опыту, это не сильно влияет на удобство сопровождения, хотя значительно улучшает читабельность вашего кода.
Этот дизайн может показаться вам немного надуманным, но на самом деле у меня есть аналогичный дизайн, работающий уже более полугода, и он отлично работает. Я писал об этом в блоге (см. Подделка вашего поставщика LINQ ), и другие успешно применили этот подход в своих приложениях. Кажется, это работает и для других. Возможно, вам это интересно, или, по крайней мере, он может дать вам некоторые идеи, как эффективно это сделать. Я использую внедрение зависимостей, и с учетом данного дизайна мне просто нужно настроить несколько типов, чтобы запустить его.
Надеюсь, это поможет.