Я строю стандартное приложение с тремя уровнями.Ninject в трехуровневой заявке
1 приложение для консоли переднего конца
2 слоя бизнес-логики
3 слоя данных
Основная цель состоит в том, чтобы отображать некоторые данные о клиенте из таблицы базы данных.
Я стараюсь следовать указаниям в книге «Инъекция зависимостей в .NET», не имея ссылки с консоли на уровень данных, и ни один из уровня бизнес-уровня на уровень данных. Позволяет легко обменивать переднюю часть и слои данных, если это необходимо.
Скажем, у меня есть обслуживание в бизнес-слой, называемый CustomerService и имеет метод GetCustomers()
конструктор CustomerService
принимает ICustomerRepository
как и
public class CustomerService
{
ICustomerRepository repository;
public CustomerService(ICustomerRepository repository)
{
this.repository = repository;
}
public ICollection<Customer> GetCustomers()
{
return repository.GetCustomers();
}
}
На уровне данных у меня есть
public class CustomerRepository : BLL.ICustomerRepository
{
public ICollection<Customer> GetCustomers()
{
// get the customers from the db
return customers;
}
}
В консольном приложении я хочу вызвать создание объекта CustomerService с помощью Ninj ect для выполнения зависимостей ICustomerRepository.
class DIModule : NinjectModule
{
public override void Load()
{
Bind<>(ICustomerRepository).To<??????????????>()
}
}
Как я могу привязать к слоям данных класс CustomerRepository? Мне нужно добавить ссылку из консольного приложения на слой данных, чтобы это работало? Что я делаю неправильно?
Не будет ли требовать, чтобы мое консольное приложение ссылалось на мой уровень данных? Я хочу этого избежать. – tom
@tom: IoC - это просто слой абстракции. При регистрации зависимостей вам нужна ссылка как для контракта (интерфейса), так и для службы (реализации), поэтому необходимо ссылаться на сборку, содержащую оба. Тогда вы никогда не будете использовать конкретный тип класса в любом месте по дороге. – abatishchev
Похоже на подобные чувства в http://stackoverflow.com/questions/12994507/dependency-injection-does-it-violate-separation-of-concerns Все еще привыкание к DI. Благодарю. – tom