Sử dụng Func thay vì giao diện cho IoC

Bối cảnh: Tôi đang sử dụng C #

Tôi đã thiết kế một lớp, và để cô lập nó, và làm cho việc kiểm tra đơn vị dễ dàng hơn, tôi chuyển qua tất cả các phụ thuộc của nó; nó không có đối tượng khởi tạo trong nội bộ. Tuy nhiên, thay vì tham chiếu các giao diện để lấy dữ liệu cần thiết, tôi có tham chiếu mục đích chung Funcs trả về dữ liệu / hành vi mà nó yêu cầu. Khi tôi tiêm các phụ thuộc của nó, tôi chỉ có thể làm như vậy với các biểu thức lambda.

Đối với tôi, đây có vẻ là một cách tiếp cận tốt hơn bởi vì tôi không phải thực hiện bất kỳ sự chế nhạo tẻ nhạt nào trong quá trình thử nghiệm đơn vị. Ngoài ra, nếu việc thực hiện xung quanh có những thay đổi cơ bản, tôi sẽ chỉ cần thay đổi lớp nhà máy; không có thay đổi trong lớp chứa logic sẽ là cần thiết.

Tuy nhiên, tôi chưa bao giờ thấy IoC được thực hiện theo cách này trước đây, điều này khiến tôi nghĩ rằng có một số cạm bẫy tiềm năng mà tôi có thể đang thiếu. Điều duy nhất tôi có thể nghĩ đến là sự không tương thích nhỏ với phiên bản C # trước đó không xác định Func và đây không phải là vấn đề trong trường hợp của tôi.

Có bất kỳ vấn đề nào với việc sử dụng các đại biểu chung / các hàm bậc cao hơn như Func cho IoC, trái ngược với các giao diện cụ thể hơn không?

Nếu một giao diện chỉ chứa một chức năng, không nhiều hơn và không có lý do thuyết phục nào để giới thiệu hai tên (tên giao diện và tên chức năng bên trong giao diện), sử dụng Functhay thế có thể tránh mã nồi hơi không cần thiết và trong hầu hết các trường hợp thích hợp hơn - giống như khi bạn bắt đầu thiết kế DTO và nhận ra nó chỉ cần một thuộc tính thành viên.

Tôi đoán nhiều người đã quen với việc sử dụng hơn interfaces, bởi vì tại thời điểm khi tiêm phụ thuộc và IoC đang trở nên phổ biến, không có lớp nào thực sự tương đương với Funclớp trong Java hoặc C ++ (Tôi thậm chí không chắc Funclà có sẵn tại thời điểm đó trong C # không ). Vì vậy, rất nhiều hướng dẫn, ví dụ hoặc sách giáo khoa vẫn thích interfacehình thức, ngay cả khi sử dụng Funcsẽ thanh lịch hơn.

Bạn có thể xem xét câu trả lời trước đây của tôi về nguyên tắc phân tách giao diện và phương pháp Thiết kế dòng chảy của Ralf Hampal. Nghịch lý này thực hiện DI với Funccác tham số dành riêng , với lý do chính xác giống như lý do bạn đã đề cập một mình (và một số chi tiết khác). Vì vậy, như bạn thấy, ý tưởng của bạn không phải là một ý tưởng thực sự mới, hoàn toàn ngược lại.

Và vâng, tôi đã sử dụng phương pháp này một mình, cho mã sản xuất, cho các chương trình cần xử lý dữ liệu dưới dạng một đường ống với một số bước trung gian, bao gồm các thử nghiệm đơn vị cho từng bước. Vì vậy, từ đó tôi có thể cung cấp cho bạn kinh nghiệm đầu tay rằng nó có thể hoạt động rất tốt.

Một trong những lợi thế chính mà tôi tìm thấy với IoC là nó sẽ cho phép tôi đặt tên cho tất cả các phụ thuộc của mình thông qua việc đặt tên giao diện của chúng và container sẽ biết nên cung cấp cái nào cho nhà xây dựng bằng cách khớp tên loại. Điều này là thuận tiện và nó cho phép nhiều tên mô tả phụ thuộc hơn Func<string, string>.

Tôi cũng thường thấy rằng ngay cả với một phụ thuộc đơn giản, đôi khi nó cần có nhiều hơn một chức năng - một giao diện cho phép bạn nhóm các chức năng này lại với nhau theo cách tự ghi lại tài liệu, so với việc có nhiều tham số mà tất cả đều đọc Func<string, string>, Func<string, int>.

Chắc chắn có những lúc thật hữu ích khi chỉ cần có một đại biểu được thông qua như một sự phụ thuộc. Đó là một cuộc gọi phán xét khi bạn sử dụng một đại biểu và có một giao diện với rất ít thành viên. Trừ khi nó thực sự rõ ràng mục đích của cuộc tranh luận là gì, tôi thường sẽ sai ở khía cạnh sản xuất mã tự viết; I E. viết một giao diện.

Có bất kỳ vấn đề nào với việc sử dụng các đại biểu chung / các hàm bậc cao hơn như Func cho IoC, trái ngược với các giao diện cụ thể hơn không?

Không hẳn vậy. Một Func là loại giao diện riêng của nó (theo nghĩa tiếng Anh, không phải nghĩa C #). "Tham số này là thứ cung cấp X khi được hỏi." Func thậm chí còn có lợi ích là chỉ cung cấp thông tin một cách lười biếng khi cần thiết. Tôi làm điều này một chút và đề nghị nó trong chừng mực.

Đối với nhược điểm:

• Các container IoC thường thực hiện một số phép thuật để kết nối các phụ thuộc theo cách xếp tầng và có thể sẽ không chơi tốt khi một số thứ Tvà một số thứ Func<T>.
• Funcs có một số lỗi, do đó có thể khó hơn một chút để lý do và gỡ lỗi.
• Funcs trì hoãn khởi tạo, có nghĩa là lỗi thời gian chạy có thể xuất hiện vào những thời điểm kỳ lạ hoặc hoàn toàn không trong quá trình thử nghiệm. Nó cũng có thể làm tăng cơ hội đặt hàng các vấn đề hoạt động và tùy thuộc vào việc sử dụng của bạn, các bế tắc trong thứ tự khởi tạo.
• Những gì bạn chuyển vào Func có thể là một sự đóng cửa, với chi phí thấp và các biến chứng đòi hỏi.
• Gọi Func chậm hơn một chút so với truy cập trực tiếp vào đối tượng. (Không đủ để bạn nhận thấy trong bất kỳ chương trình không tầm thường nào, nhưng nó ở đó)

Hãy lấy một ví dụ đơn giản-- có lẽ bạn đang tiêm một phương tiện đăng nhập.

Tiêm một lớp

class Worker: IWorker
{
    ILogger _logger;

    Worker(ILogger logger)
    {
        _logger = logger;
    }
    void SomeMethod()
    {
        _logger.Debug("This is a debug log statement.");
    }
}        

Tôi nghĩ rằng đó là khá rõ ràng những gì đang xảy ra. Hơn nữa, nếu bạn đang sử dụng bộ chứa IoC, bạn thậm chí không cần tiêm bất cứ thứ gì một cách rõ ràng, bạn chỉ cần thêm vào gốc thành phần của mình:

container.RegisterType<ILogger, ConcreteLogger>();
container.RegisterType<IWorker, Worker>();
....
var worker = container.Resolve<IWorker>();

Khi gỡ lỗi Worker, nhà phát triển chỉ cần tham khảo gốc thành phần để xác định lớp cụ thể nào đang được sử dụng.

Nếu một nhà phát triển cần logic phức tạp hơn, anh ta có toàn bộ giao diện để làm việc với:

    void SomeMethod()
    { 
       if (_logger.IsDebugEnabled) {
           _logger.Debug("This is a debug log statement.");
       }
    }

Tiêm một phương pháp

class Worker
{
    Action<string> _methodThatLogs;

    Worker(Action<string> methodThatLogs)
    {
        _methodThatLogs = methodThatLogs;
    }
    void SomeMethod()
    {
        _methodThatLogs("This is a logging statement");
    }
}        

Đầu tiên, lưu ý rằng tham số constructor có tên dài hơn bây giờ , methodThatLogs. Điều này là cần thiết bởi vì bạn không thể nói những gì Action<string>cần phải làm. Với giao diện, nó đã hoàn toàn rõ ràng, nhưng ở đây chúng ta phải dùng đến việc dựa vào việc đặt tên tham số. Điều này dường như ít đáng tin cậy và khó thực thi hơn trong quá trình xây dựng.

Bây giờ, làm thế nào để chúng ta tiêm phương pháp này? Chà, container IoC sẽ không làm điều đó cho bạn. Vì vậy, bạn còn lại tiêm nó một cách rõ ràng khi bạn khởi tạo Worker. Điều này đặt ra một số vấn đề:

1. Đó là nhiều công việc để khởi tạo một Worker
2. Các nhà phát triển cố gắng gỡ lỗi Workersẽ thấy khó khăn hơn để tìm ra trường hợp cụ thể nào được gọi. Họ không thể chỉ tham khảo các gốc thành phần; họ sẽ phải theo dõi thông qua mã.

Nếu chúng ta cần logic phức tạp hơn thì sao? Kỹ thuật của bạn chỉ phơi bày một phương pháp. Bây giờ tôi cho rằng bạn có thể nướng những thứ phức tạp vào lambda:

var worker = new Worker((s) => { if (log.IsDebugEnabled) log.Debug(s) } );

nhưng khi bạn đang viết bài kiểm tra đơn vị của mình, làm thế nào để bạn kiểm tra biểu thức lambda đó? Nó ẩn danh, vì vậy khung kiểm tra đơn vị của bạn không thể khởi tạo trực tiếp. Có thể bạn có thể tìm ra một số cách thông minh để làm điều đó, nhưng nó có thể sẽ là một PITA lớn hơn so với sử dụng giao diện.

Tóm tắt về sự khác biệt:

1. Chỉ tiêm một phương pháp làm cho việc suy luận mục đích trở nên khó khăn hơn, trong khi một giao diện truyền đạt rõ ràng mục đích.
2. Chỉ tiêm một phương thức làm lộ ít chức năng hơn đối với lớp nhận tiêm. Ngay cả khi bạn không cần nó ngày hôm nay, bạn có thể cần nó vào ngày mai.
3. Bạn không thể tự động chỉ tiêm một phương thức bằng cách sử dụng bộ chứa IoC.
4. Bạn không thể biết từ gốc thành phần mà lớp cụ thể đang làm việc trong một trường hợp cụ thể.
5. Đó là một vấn đề để đơn vị kiểm tra chính biểu thức lambda.

Nếu bạn ổn với tất cả những điều trên, thì bạn chỉ nên tiêm phương pháp. Nếu không, tôi khuyên bạn nên gắn bó với truyền thống và tiêm giao diện.

Hãy xem xét đoạn mã sau tôi đã viết từ lâu:

public interface IPhysicalPathMapper
{
    /// <summary>
    /// Gets the physical path represented by the relative URL.
    /// </summary>
    /// <param name="relativeURL"></param>
    /// <returns></returns>
    String GetPhysicalPath(String relativeURL);
}

public class EmailBuilder : IEmailBuilder
{
    public IPhysicalPathMapper PhysicalPathMapper { get; set; }
    public ITextFileLoader TextFileLoader { get; set; }
    public IEmailTemplateParser EmailTemplateParser { get; set; }
    public IEmaiBodyRenderer EmailBodyRenderer { get; set; }

    public String FromAddress { get; set; }

    public MailMessage BuildMailMessage(String templateRelativeURL, Object model, IEnumerable<String> toAddresses)
    {
        String templateText = this.TextFileLoader.LoadTextFromFile(this.PhysicalPathMapper.GetPhysicalPath(templateRelativeURL));

        EmailTemplate template = this.EmailTemplateParser.Parse(templateText);

        MailMessage email = new MailMessage()
        {
            From = new MailAddress(this.FromAddress),
            Subject = template.Subject,
            IsBodyHtml = true,
            Body = this.EmailBodyRenderer.RenderBodyToHtml(template.BodyTemplate, model)
        };

        foreach (MailAddress recipient in toAddresses.Select<String, MailAddress>(toAddress => new MailAddress(toAddress)))
        {
            email.To.Add(recipient);
        }

        return email;
    }
}

Nó lấy một vị trí tương đối vào một tệp mẫu, tải nó vào bộ nhớ, kết xuất nội dung thư và lắp ráp đối tượng e-mail.

Bạn có thể nhìn IPhysicalPathMappervà nghĩ, "Chỉ có một chức năng. Đó có thể là một Func." Nhưng thật ra, vấn đề ở đây là IPhysicalPathMapperthậm chí không tồn tại. Một giải pháp tốt hơn nhiều là chỉ cần tham số hóa đường dẫn :

public class EmailBuilder : IEmailBuilder
{
    public ITextFileLoader TextFileLoader { get; set; }
    public IEmailTemplateParser EmailTemplateParser { get; set; }
    public IEmaiBodyRenderer EmailBodyRenderer { get; set; }

    public String FromAddress { get; set; }

    public MailMessage BuildMailMessage(String templatePath, Object model, IEnumerable<String> toAddresses)
    {
        String templateText = this.TextFileLoader.LoadTextFromFile(templatePath);

        EmailTemplate template = this.EmailTemplateParser.Parse(templateText);

        MailMessage email = new MailMessage()
        {
            From = new MailAddress(this.FromAddress),
            Subject = template.Subject,
            IsBodyHtml = true,
            Body = this.EmailBodyRenderer.RenderBodyToHtml(template.BodyTemplate, model)
        };

        foreach (MailAddress recipient in toAddresses.Select<String, MailAddress>(toAddress => new MailAddress(toAddress)))
        {
            email.To.Add(recipient);
        }

        return email;
    }
}

Điều này đặt ra một loạt các câu hỏi khác để cải thiện mã này. Ví dụ, có lẽ nó chỉ nên chấp nhận một EmailTemplate, và sau đó có lẽ nó nên chấp nhận một mẫu được kết xuất sẵn, và sau đó có lẽ nó chỉ nên được xếp hàng.

Đây là lý do tại sao tôi không thích đảo ngược kiểm soát như một mô hình phổ biến. Nó thường được coi là giải pháp giống như thần này để soạn thảo tất cả mã của bạn. Nhưng trong thực tế, nếu bạn sử dụng nó một cách phổ biến (trái ngược với một cách tiết kiệm), nó làm cho mã của bạn tệ hơn nhiều bằng cách khuyến khích bạn giới thiệu nhiều giao diện không cần thiết được sử dụng hoàn toàn ngược. (Ngược lại theo nghĩa là người gọi phải thực sự chịu trách nhiệm đánh giá các phụ thuộc đó và chuyển kết quả vào chứ không phải chính lớp gọi cuộc gọi.)

Các giao diện nên được sử dụng một cách tiết kiệm, và đảo ngược kiểm soát và tiêm phụ thuộc cũng nên được sử dụng một cách tiết kiệm. Nếu bạn có số lượng lớn trong số chúng, mã của bạn trở nên khó giải mã hơn nhiều.