Понимание свойств TDD и интерфейса - PullRequest
1 голос
/ 23 марта 2012

Я пытаюсь понять TDD больше, и все примеры, которые я видел относительно DI, были классами / интерфейсами, в которых есть только методы, например.

public interface IUserRepository
{
   User GetByID(int ID);
}

public class UserRepo : IUserRepository
{
   private IUserRepository Repo;

   public UserRepo(IUserRepository repo)
   {
      this.Repo. = repo;
   }
   public User GetByID(int ID) {}
}

.....

private void SetupDI()
{
   container.Register<IUserRepository>.With(UserRepository);
}

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

Имеет ли свойства в интерфейсах ОК с точки зрения DI?Это хороший дизайн?

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

private void SetupDI()
{
   var myStringProp = GetPropValue("MyStringProp");
   var myIntProp = GetPropValue("MyIntProp");

   container.Register<IUserRepository>.With
             (
               new UserRepository() {
                 StringProperty = myStringProp;
                 IntProperty = myIntProp;
               }
             );
}

ИЛИ

Вы бы передали все необходимые свойства в конструкторе:

private void SetupDI()
{
   var myStringProp = GetPropValue("MyStringProp");
   var myIntProp = GetPropValue("MyIntProp");

   container.Register<IUserRepository>.With
             (
               new UserRepository(myStringProp,myIntProp)
             );
}

Ответы [ 2 ]

1 голос
/ 23 марта 2012

Совершенно нормально использовать свойства в интерфейсах, но ваш вопрос на самом деле касается в основном конструктора и внедрения свойств, а не столько об использовании свойств в интерфейсах.

Первый (внедрение конструктора) явно предпочтительнее, посколькузависимости класса должны быть переданы во время создания, чтобы они были четко видны и не были «скрыты».Лично я стремлюсь всегда использовать внедрение конструктора и внедрение свойства только в качестве крайней меры, например, когда существует циклическая зависимость, которая иначе не может быть разрешена (в то время, вероятно, лучше переосмыслить проект).

0 голосов
/ 23 марта 2012

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

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