2011-08-19 39 views
5

Bạn có nên xem xét việc sử dụng Properties.Settings.Default trong một lớp làm phụ thuộc không và do đó hãy tiêm nó?Sử dụng tiêm phụ thuộc cho Properties.Settings.Default?

ví dụ .:

public class Foo 
{ 
    private _settings; 
    private bool _myBool; 

    public Foo(Settings settings) 
    { 
     this._settings = settings; 
     this._myBool = this._settings.MyBool; 
    } 
} 

.
.

hoặc bạn có xem xét việc sử dụng Settings làm ứng dụng toàn cầu là thực tiễn tốt không?

ví dụ .:

public class Foo 
{ 
    private bool _myBool; 

    public Foo() 
    { 
     this._myBool = Properties.Settings.Default.MyBool; 
    } 
} 

Trả lời

2

Bạn có thể muốn đóng gói Cài đặt trong một lớp học và có giao diện cho chúng. Bằng cách này, nơi cài đặt của bạn đến từ có thể được thay đổi cho những thứ như kiểm tra đơn vị. Nếu bạn cũng đang sử dụng một container IoC, thì bằng mọi cách, hãy đăng ký các thiết lập với vùng chứa.

Tôi làm điều này cho ConfigurationManagerWebConfigurationManager để tôi có thể chèn cài đặt cho thử nghiệm. Nathan Gloyn has wrapped the adapters and interface up already in a project mà bạn có thể sử dụng nếu bạn cũng muốn làm điều này.

+0

Tôi thích ý tưởng về giao diện nhưng tôi không chắc chắn cách thực hiện điều đó. Bạn có nghĩa là có một giao diện có các thuộc tính trực tiếp ánh xạ tới các thuộc tính trong Cài đặt, hoặc sử dụng Trình Quản lý Cấu hình, giống như cách mà mã bạn liên kết làm không? Không sử dụng ConfigurationManager trước đây, vì vậy không quá chắc chắn phải làm gì ở đây. Một di chuyển theo hướng đúng sẽ được đánh giá cao. :) – Andy

+0

'IConfigurationManager' chỉ là một ví dụ về nơi cài đặt bên ngoài có thể nằm trong ứng dụng và bạn muốn chúng được xử lý bởi vùng chứa và được đưa vào lớp. Đối với lớp 'Settings', tôi sẽ có khuynh hướng tạo giao diện' ISettings' phù hợp nhất với các thành viên của 'Settings'; vì vậy nếu bạn có thuộc tính 'ConnectionString' trên' Cài đặt' thì hãy đặt thuộc tính này trên giao diện, v.v. –

+0

Cảm ơn bạn đã làm rõ, điều đó có ý nghĩa. – Andy

2

Họ nên được thông qua tại như một sự phụ thuộc. Hãy tưởng tượng kịch bản khi bạn muốn thay đổi tập hợp các thiết lập đó thông qua Kiểm thử Đơn vị trong ví dụ # 2 của bạn - bạn sẽ phải có một loại logic chuyển đổi phức tạp trong trình thu thập thuộc tính tĩnh để tính toán điều đó.

Nhiều vùng chứa IoC thậm chí có thể cung cấp triển khai đơn lẻ khi tiêm các lớp như vậy để hỗ trợ bạn.

4

tôi sẽ chọn "không có ở trên" và tiêm các giá trị boolean trực tiếp:

public class Foo 
{ 
    private readonly bool _myBool; 

    public Foo(bool myBool) 
    { 
     _myBool = myBool; 
    } 
} 

này tách riêng Foo từ kiến ​​thức của bất kỳ cơ sở hạ tầng hỗ trợ việc thu hồi các giá trị boolean. Foo không có lý do để giới thiệu tính phức tạp bằng cách tùy thuộc vào đối tượng cài đặt, đặc biệt nếu nó chứa các giá trị không liên quan khác.

+0

+1, nhưng lưu ý đây là một khó khăn lớn hơn để cấu hình với các DI container. Tuy nhiên có lẽ là ý tưởng hay nhất. – Domenic

+0

@Domenic: Cần lưu ý rằng một số vùng chứa DI có thể không cho phép điều này dễ dàng như những người khác. Tôi sử dụng Autofac, hỗ trợ các biểu thức lambda để đăng ký và do đó có thể dễ dàng chèn các giá trị nguyên thủy. –

+0

@Bryan: Tôi đồng ý, nhưng đoạn mã của tôi ở trên đã được giả mạo như một ví dụ quá đơn giản cho các mục đích của câu hỏi. Tuy nhiên, những gì bạn nói là đúng, vì vậy cảm ơn câu trả lời của bạn. – Andy

Các vấn đề liên quan