Linq2Sql, ООП, DependencyInjection проблема

Question

Я все еще немного борюсь с концепциями ООП и внедрением зависимостей, так что терпите меня.

Я сгенерировал свою модель Linq2Sql с таблицей User, и теперь я хотел бы иметь возможность отправить электронное письмо с подтверждением этому пользователю, поэтому я создал частичный файл класса для своего объекта User, и я чувствовал, что было естественно добавить SendConfirmationEmail () к классу User. Этот метод будет использовать MailService для отправки фактического электронного письма, и я хотел бы использовать внедрение зависимостей для передачи в службу, поэтому я создал перегрузку конструктора для объекта User, например,

public User(IMailService service) : this()
{
    _service = service;
}

Метод SendConfirmationEmail будет выглядеть следующим образом

public void SendConfirmationEmail()
{
    _service.SendMail(params...);
}

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

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

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

Answer 1

Я бы лично изменил некоторые вещи в вашей архитектуре:

• Я не думаю, что SendConfirmationEmail должен быть методом для вашего объекта User. Но должен быть метод для другого объекта с пользователем в качестве параметра. (это также лучше отделяет ваш Dal от другой логики.

• Второй в этом методе использовать что-то вроде этого:

  Services.Get (). SendMail (params ...);

Вы можете внедрить Сервисы в качестве примера (просто пример):

public class Services
{
    protected static Dictionary<Type, object> services = new Dictionary<Type, object>();

    private Services() 
    {
    }

    static Services()
    {
        // hard coded implementations...
        services.Add(typeof(IMailService), new DefaultMailServiceImplementation());
    }

    public static T Get<T>() where T : class
    {
        Type requestedType = typeof(T);
        return services[requestedType] as T;
    }
}

Используя класс «Services» (или назовите его как хотите), вы добавляете дополнительный слой между IOC-каркасом и вашим кодом, который облегчает изменение IOC-каркаса. Просто измените реализацию в методе Get, чтобы использовать ее. Вы также можете использовать жестко закодированное временное решение (пока вы не используете IOC-каркас) в статическом конструкторе (как я делал в приведенном выше примере).

Answer 2

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

1. Создайте интерфейс для вашего пользователя объект. Вы должны сделать это, потому что не делать это будет означать, что все, что потребляет это бизнес-объект должен будет ссылаться на dll LINQ т.к.
2. Переместите инъекцию зависимости от конструктор в собственность. Вы делаете это, потому что конструктор инъекция имеет тенденцию ограничивать ваши способность динамически создавать свои объект. Делая это, хотя ставит проблема, так как вам придется реализовать много нулевой проверки код для _service. Вы можете это исправить создавая "пустой" внедрение IMailService и сделать его значением по умолчанию для _service.

Answer 3

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

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