Bằng cách này, tôi đang viết mã này có thể kiểm tra được, nhưng tôi có thiếu sót gì không?

Tôi có một giao diện được gọi là IContext. Đối với mục đích này, nó thực sự không quan trọng những gì nó làm ngoại trừ những điều sau đây:

T GetService<T>();

Phương pháp này làm là nhìn vào thùng chứa DI hiện tại của ứng dụng và cố gắng giải quyết sự phụ thuộc. Tôi nghĩ là khá chuẩn.

Trong ứng dụng ASP.NET MVC của tôi, hàm tạo của tôi trông như thế này.

protected MyControllerBase(IContext ctx)
{
    TheContext = ctx;
    SomeService = ctx.GetService<ISomeService>();
    AnotherService = ctx.GetService<IAnotherService>();
}

Vì vậy, thay vì thêm nhiều tham số trong hàm tạo cho mỗi dịch vụ (vì điều này sẽ thực sự gây phiền nhiễu và tốn thời gian cho các nhà phát triển mở rộng ứng dụng) Tôi đang sử dụng phương pháp này để nhận dịch vụ.

Bây giờ, nó cảm thấy sai . Tuy nhiên, cách mà tôi hiện đang biện minh nó trong đầu là thế này - tôi có thể chế giễu nó .

Tôi có thể. Sẽ không khó để giả lập IContextđể kiểm tra Bộ điều khiển. Dù sao tôi cũng phải:

public class MyMockContext : IContext
{
    public T GetService<T>()
    {
        if (typeof(T) == typeof(ISomeService))
        {
            // return another mock, or concrete etc etc
        }

        // etc etc
    }
}

Nhưng như tôi đã nói, nó cảm thấy sai. Bất kỳ suy nghĩ / lạm dụng hoan nghênh.

Có một thay vì nhiều tham số trong hàm tạo không phải là phần có vấn đề trong thiết kế này . Miễn là IContextlớp học của bạn không là gì ngoài mặt tiền dịch vụ , cụ thể là cung cấp các phụ thuộc được sử dụng MyControllerBasevà không phải là công cụ định vị dịch vụ chung được sử dụng trong toàn bộ mã của bạn, một phần mã của bạn là IMHO ok.

Ví dụ đầu tiên của bạn có thể được thay đổi thành

protected MyControllerBase(IContext ctx)
{
    TheContext = ctx;
    SomeService = ctx.GetSomeService();
    AnotherService = ctx.GetAnotherService();
}

đó sẽ không phải là một sự thay đổi thiết kế đáng kể của MyControllerBase . Nếu thiết kế này tốt hay xấu chỉ phụ thuộc vào thực tế nếu bạn muốn

• chắc chắn TheContext, SomeServicevà AnotherServiceluôn tất cả khởi tạo với các đối tượng giả, hoặc tất cả trong số họ với các đối tượng thực
• hoặc, để cho phép khởi tạo chúng với các kết hợp khác nhau của 3 đối tượng (có nghĩa là, trong trường hợp này, bạn sẽ cần phải truyền các tham số riêng lẻ)

Vì vậy, chỉ sử dụng một tham số thay vì 3 trong hàm tạo có thể hoàn toàn hợp lý.

Điều có vấn đề là IContextphơi bày GetServicephương pháp ở nơi công cộng. IMHO bạn nên tránh điều này, thay vào đó hãy giữ rõ ràng "phương pháp nhà máy". Vì vậy, nó có ổn không khi thực hiện GetSomeServicevà GetAnotherServicecác phương thức từ ví dụ của tôi bằng cách sử dụng trình định vị dịch vụ? IMHO mà phụ thuộc. Miễn là IContextlớp tiếp tục duy trì một nhà máy trừu tượng đơn giản cho mục đích cụ thể là cung cấp một danh sách rõ ràng các đối tượng dịch vụ, đó là IMHO có thể chấp nhận được. Các nhà máy trừu tượng thường chỉ là mã "keo", không phải tự kiểm tra đơn vị. Tuy nhiên, bạn nên tự hỏi mình trong bối cảnh của các phương pháp nhưGetSomeService , nếu bạn thực sự cần một trình định vị dịch vụ, hoặc nếu một lệnh gọi hàm tạo rõ ràng sẽ không đơn giản hơn.

Vì vậy, hãy cẩn thận, khi bạn tuân theo một thiết kế trong đó việc IContexttriển khai chỉ là một trình bao bọc xung quanh một GetServicephương thức chung, chung , cho phép giải quyết bất kỳ sự thiếu hụt tùy ý nào bằng các lớp tùy ý, thì mọi thứ đều áp dụng những gì @BenjaminHodgson đã viết trong câu trả lời của anh ấy.

Thiết kế này được gọi là Trình định vị dịch vụ * và tôi không thích nó. Có rất nhiều tranh luận chống lại nó:

Dịch vụ định vị kết nối bạn với container của bạn . Sử dụng phép nội xạ phụ thuộc thường xuyên (trong đó hàm tạo sẽ loại bỏ các phụ thuộc một cách rõ ràng), bạn có thể thay thế đơn giản bộ chứa của mình bằng một bộ khác hoặc quay lại new-expression. Với IContextđiều đó là không thực sự có thể.

Dịch vụ định vị ẩn phụ thuộc . Là một khách hàng, rất khó để nói những gì bạn cần để xây dựng một thể hiện của một lớp. Bạn cần một số loại IContext, nhưng bạn cũng cần thiết lập bối cảnh để trả về các đối tượng chính xác để thực hiện MyControllerBasecông việc. Điều này hoàn toàn không rõ ràng từ chữ ký của nhà xây dựng. Với DI thông thường, trình biên dịch sẽ cho bạn biết chính xác những gì bạn cần. Nếu lớp học của bạn có nhiều phụ thuộc, bạn sẽ cảm thấy đau đớn vì nó sẽ thúc đẩy bạn tái cấu trúc. Dịch vụ định vị che giấu các vấn đề với thiết kế xấu.

Dịch vụ định vị gây ra lỗi thời gian chạy . Nếu bạn gọi GetServicevới một tham số loại xấu, bạn sẽ nhận được một ngoại lệ. Nói cách khác, GetServicechức năng của bạn không phải là một chức năng tổng thể. (Tổng số hàm là một ý tưởng từ thế giới FP, nhưng về cơ bản, điều đó có nghĩa là các hàm phải luôn trả về một giá trị.) Tốt hơn là để trình biên dịch trợ giúp và cho bạn biết khi bạn gặp lỗi phụ thuộc.

Dịch vụ định vị vi phạm Nguyên tắc thay thế Liskov . Vì hành vi của nó thay đổi dựa trên đối số loại, Trình định vị dịch vụ có thể được xem như thể nó thực sự có vô số phương thức trên giao diện! Lập luận này được đánh vần chi tiết ở đây .

Dịch vụ định vị là khó để kiểm tra . Bạn đã đưa ra một ví dụ về giả mạo IContextđể kiểm tra, điều này tốt, nhưng chắc chắn tốt hơn là không phải viết mã đó ngay từ đầu. Chỉ cần tiêm trực tiếp phụ thuộc giả của bạn, mà không cần thông qua công cụ định vị dịch vụ của bạn.

Nói tóm lại, đừng làm điều đó . Nó có vẻ như là một giải pháp quyến rũ cho vấn đề của các lớp học với rất nhiều sự phụ thuộc, nhưng về lâu dài bạn sẽ làm cho cuộc sống của bạn trở nên khốn khổ.

_{* Tôi đang xác định Bộ định vị dịch vụ là một đối tượng với một Resolve<T>phương thức chung có khả năng giải quyết các phụ thuộc tùy ý và được sử dụng trong toàn bộ cơ sở mã (không chỉ tại Root gốc). Điều này không giống với Mặt tiền dịch vụ (một đối tượng kết hợp một số nhóm phụ thuộc nhỏ đã biết) hoặc Tóm tắt Factory (một đối tượng tạo các thể hiện của một loại duy nhất - loại của một Nhà máy trừu tượng có thể chung chung nhưng phương thức thì không) .}

Những lý lẽ tốt nhất chống lại mô hình chống định vị dịch vụ được Mark Seemann nêu rõ ràng vì vậy tôi sẽ không đi sâu vào lý do tại sao đây là một ý tưởng tồi - đó là một hành trình học hỏi mà bạn phải dành thời gian để tự hiểu (Tôi cũng đề nghị cuốn sách của Mark ).

OK để trả lời câu hỏi - hãy nêu lại vấn đề thực tế của bạn :

Vì vậy, thay vì thêm nhiều tham số trong hàm tạo cho mỗi dịch vụ (vì điều này sẽ thực sự gây phiền nhiễu và tốn thời gian cho các nhà phát triển mở rộng ứng dụng) Tôi đang sử dụng phương pháp này để nhận dịch vụ.

Có một câu hỏi giải quyết vấn đề này trên StackOverflow . Như đã đề cập trong một trong những ý kiến ​​đó:

Nhận xét tốt nhất: "Một trong những lợi ích tuyệt vời của Con Contortor tiêm là nó làm cho việc vi phạm Nguyên tắc Trách nhiệm Đơn lẻ trở nên rõ ràng."

Bạn đang tìm sai chỗ cho giải pháp cho vấn đề của bạn. Điều quan trọng là phải biết khi một lớp học đang làm quá nhiều. Trong trường hợp của bạn, tôi nghi ngờ rằng không cần "Bộ điều khiển cơ sở". Trên thực tế, trong OOP hầu như không cần phải thừa kế chút nào . Sự khác biệt trong hành vi và chức năng được chia sẻ hoàn toàn có thể đạt được thông qua việc sử dụng các giao diện phù hợp, điều này thường dẫn đến mã được đóng gói và đóng gói tốt hơn - và không cần phải chuyển phụ thuộc vào các nhà xây dựng siêu lớp.

Trong tất cả các dự án tôi đã làm việc ở nơi có Bộ điều khiển cơ sở, nó được thực hiện hoàn toàn cho mục đích chia sẻ các thuộc tính và phương thức thuận tiện, chẳng hạn như IsUserLoggedIn()và GetCurrentUserId(). DỪNG . Đây là sự lạm dụng khủng khiếp của thừa kế. Thay vào đó, hãy tạo một thành phần phơi bày các phương thức này và phụ thuộc vào nó ở nơi bạn cần. Bằng cách này, các thành phần của bạn sẽ vẫn có thể kiểm tra được và sự phụ thuộc của chúng sẽ rõ ràng.

Ngoài bất cứ điều gì khác, khi sử dụng mẫu MVC tôi luôn khuyên dùng các bộ điều khiển mỏng . Bạn có thể đọc thêm về điều này ở đây nhưng bản chất của mẫu rất đơn giản, rằng các bộ điều khiển trong MVC chỉ nên làm một việc: xử lý các đối số được truyền bởi khung MVC, ủy thác các mối quan tâm khác cho một số thành phần khác. Đây một lần nữa là Nguyên tắc Trách nhiệm duy nhất trong công việc.

Nó thực sự sẽ giúp biết trường hợp sử dụng của bạn để đưa ra phán đoán chính xác hơn, nhưng thực lòng tôi không thể nghĩ ra bất kỳ kịch bản nào trong đó một lớp cơ sở thích hợp hơn với các phụ thuộc được bao bọc kỹ lưỡng.

Tôi đang thêm một câu trả lời cho điều này dựa trên sự đóng góp của mọi người khác. Cảm ơn mọi người rất nhiều. Đầu tiên đây là câu trả lời của tôi: "Không, không có gì sai với nó".

Câu trả lời "Mặt tiền dịch vụ" của Doc Brown Tôi đã chấp nhận câu trả lời này bởi vì điều tôi đang tìm kiếm (nếu câu trả lời là "không") là một số ví dụ hoặc một số mở rộng dựa trên những gì tôi đang làm. Ông đã cung cấp điều này khi đề xuất rằng A) nó có tên và B) có lẽ có nhiều cách tốt hơn để làm điều này.

Câu trả lời "Trình định vị dịch vụ" của Benjamin Hodgson Nhiều như tôi đánh giá cao những kiến ​​thức tôi có được ở đây, những gì tôi có không phải là "Trình định vị dịch vụ". Đó là một "Mặt tiền dịch vụ". Tất cả mọi thứ trong câu trả lời này là chính xác nhưng không phải cho hoàn cảnh của tôi.

Câu trả lời của USR

Tôi sẽ giải quyết vấn đề này chi tiết hơn:

Bạn đang từ bỏ rất nhiều thông tin tĩnh theo cách này. Bạn đang trì hoãn các quyết định về thời gian chạy như nhiều ngôn ngữ động khác. Bằng cách đó, bạn mất khả năng xác minh tĩnh (an toàn), hỗ trợ tài liệu và công cụ (tự động hoàn tất, tái cấu trúc, tìm công dụng, luồng dữ liệu).

Tôi không mất bất kỳ dụng cụ nào và tôi sẽ không mất bất kỳ kiểu gõ "tĩnh" nào. Mặt tiền dịch vụ sẽ trả về những gì tôi đã cấu hình trong thùng chứa DI, hoặc default(T). Và những gì nó trả về là "đánh máy". Sự phản ánh được gói gọn.

Tôi không thấy lý do tại sao việc thêm các dịch vụ bổ sung làm đối số của nhà xây dựng là một gánh nặng lớn.

Nó chắc chắn không phải là "hiếm". Vì tôi đang sử dụng bộ điều khiển cơ sở , mỗi lần tôi cần thay đổi hàm tạo, tôi có thể phải thay đổi 10, 100, 1000 bộ điều khiển khác.

Nếu bạn sử dụng khung tiêm phụ thuộc, bạn thậm chí sẽ không phải truyền thủ công các giá trị tham số. Sau đó, một lần nữa bạn mất một số lợi thế tĩnh nhưng không nhiều.

Tôi đang sử dụng tiêm phụ thuộc. Đó là điểm.

Và cuối cùng, nhận xét của Jules về câu trả lời của Benjamin Tôi không mất đi sự linh hoạt. Đó là mặt tiền dịch vụ của tôi . Tôi có thể thêm bao nhiêu tham số GetService<T>mà tôi muốn phân biệt giữa các cài đặt khác nhau, giống như cách thực hiện khi định cấu hình bộ chứa DI. Vì vậy, ví dụ, tôi có thể thay đổi GetService<T>()để GetService<T>(string extraInfo = null)giải quyết "vấn đề tiềm năng" này.

Dù sao, một lần nữa cảm ơn mọi người. Nó thực sự hữu ích. Chúc mừng.