Инжекция конструктора и перегрузки по умолчанию

я не предоставил бы тому конструктору. Выполнение так делает слишком легким назвать новый TimeStamped и получить экземпляр с новым SystemTimestampProvider (), когда Ваш МОК может быть настроен для использования OtherTimestampProvider ().

Конец дня, который Вы закончите с одним адским временем, пытаясь отладить, почему Вы получаете неправильную метку времени.

Если Вы только предоставляете первому конструктору, можно сделать простую находку использования SystemTimestampProvider для обнаружения, кто (неправильно) использует того поставщика вместо настроенного Поставщика МОК.

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

Если Вы говорите о приложении-контейнере МОК, otoh, необходимо быть осторожны относительно вмешательства в то, что параметры конфигурации говорят контейнеру делать способом, что это не ясно...

   public class EventsLogic
   { 
       private readonly IEventDAL ievtDal;
       public IEventDAL IEventDAL { get { return ievtDal; } }

       public EventsLogic(): this(null) {}
       public EventsLogic(IIEEWSDAL wsDal, IEventDAL evtDal)
       {
          ievtDal = evtDal ?? new EventDAL();
       }
    }

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

Потребность во введенных объектах значения по умолчанию значительно уменьшается при помощи контейнера внедрения зависимости (я использую StructureMap) справляться со всем этим проводным соединением - контейнер DI удостоверяется, что Вы всегда получаете конкретный экземпляр, который можно использовать.

Единственное место, где я все еще испытываю желание использовать конструктора, Вы предлагаете, находится в моих модульных тестах, но недавно я вытаскивал намного большее значение из использования фальшивки или дразнил объекты.

Существуют места, где наличие подчиненных объектов по умолчанию является корректным и полезным дизайном, но в целом я сказал бы, что Вы просто представляете плотное соединение, которое не добавляет много значения.

Это не полезно и не вредно. Это создает эстетическую проблему в этом, Вы ограничиваете свой DI инжекцией конструктора только, когда Ваш дизайн может допускать инжекцию метода set свойства.

Другая опция состояла бы в том, чтобы реализовать метод считывания, который возвращает реализацию по умолчанию:

public DateTime Timestamp
{
    get { return _timestampProvider??new SystemTimestampProvider(); }
    set { _timestampProvider = value; }
}

Поочередно, можно реализовать вышеупомянутое использование одиночного элемента, если Вы волнуетесь по поводу создания слишком многих объектов в "куче".

Моя команда имеет большой успех с помощью этого метода. Я рекомендую одно изменение:
Сделайте _timestampProvider только для чтения. Это вынуждает поставщика быть детерминированным в конструкции и устранит ошибки.

public class Timestamped
{
    private readonly ITimestampProvider _timestampProvider;

    public Timestamped(ITimestampProvider timestampProvider)
    {
        _timestampProvider = timestampProvider;
    }

    public Timestamped(): this(new SystemTimestampProvider())
    { }
}

Тем не менее мы всегда смотрим на новые технологии, включая платформы DI. Если мы когда-нибудь отказываемся от этой техники для чего-то значительно лучше, что я сообщу.