2013-06-04 31 views
6

Tôi thấy rằng trong nhiều trường hợp, có vẻ như (ít nhất là bề ngoài) có ý nghĩa khi sử dụng các lớp Singletons hoặc Static cho các mô hình trong các ứng dụng WPF-MVVM của tôi. Chủ yếu, điều này là bởi vì hầu hết các mô hình của tôi cần phải được truy cập trong suốt ứng dụng. Làm cho mô hình của tôi static tạo ra một cách đơn giản để đáp ứng yêu cầu này.Có cách nào tốt hơn là sử dụng các lớp tĩnh hoặc đơn cho MVVM không?

Tuy nhiên, tôi mâu thuẫn với nhau vì mọi người trên hành tinh dường như ghét những người độc thân. Vì vậy, tôi tự hỏi tôi không có cách nào tốt hơn, hoặc nếu tôi đang làm điều gì đó rõ ràng là sai?

+3

Đặt "MODELS" tĩnh ?? Không thật sự lắm. Một chút cũng không. Thậm chí còn tồi tệ hơn [phân tích HTML với RegEx] (http://stackoverflow.com/a/1732454/643085) –

+0

Heh. Không thể cưỡng lại được. – sircodesalot

+0

Nếu sử dụng DI, thay vì làm cho nó tĩnh, hãy đăng ký nó trong vùng chứa với ContainerControlledLifetimeManager. Với tĩnh, bạn có nhiều vấn đề với an toàn luồng. –

Trả lời

5

Có một vài vấn đề với Singletons. Tôi sẽ phác thảo chúng bên dưới, và sau đó đề xuất một số giải pháp thay thế. Tôi không phải là một "Không bao giờ sử dụng một singleton, hoặc bạn là một coder crap" loại người như tôi tin rằng họ có sử dụng của họ. Nhưng việc sử dụng đó rất hiếm.

  1. An toàn chủ đề. Nếu bạn có một Singleton toàn cầu tĩnh, thì nó phải là chủ đề an toàn bởi vì bất cứ thứ gì có thể truy cập nó bất cứ lúc nào. Đây là phí bổ sung.

  2. Kiểm tra đơn vị khó hơn với Singletons.

  3. Đó là một thay thế giá rẻ cho các biến toàn cầu (ý tôi là, đó là những gì một singleton là vào cuối ngày, mặc dù nó có thể có phương pháp và những thứ ưa thích khác).

Xem, nó không phải là Singleton là "gớm ghiếc khủng" cho mỗi gia nhập, nhưng rằng đó là mẫu thiết kế đầu tiên nhiều người lập trình mới có được để đối phó với và nó tiện hoang mang của nó cạm bẫy (Chỉ cần dính vào một số bánh răng trên nó và gọi nó là hơi nước-punk).

Trong trường hợp của bạn, bạn đang đề cập đến Mô hình và đây luôn là "các trường hợp" khi chúng phản ánh một cách tự nhiên dữ liệu. Có lẽ bạn đang lo lắng về chi phí của việc có được những trường hợp này. Tin tôi đi, họ sẽ không đáng kể (xuống thiết kế truy cập dữ liệu, rõ ràng).

Vì vậy, lựa chọn thay thế? Chuyển mô hình đến những nơi yêu cầu. Điều này làm cho việc kiểm tra đơn vị dễ dàng hơn và cho phép bạn trao đổi các nguyên tắc cơ bản của mô hình đó trong nhịp tim. Điều này cũng có nghĩa là bạn có thể muốn xem giao diện - đây là một giao ước. Sau đó, bạn có thể tạo các đối tượng cụ thể để triển khai các giao diện này và thì đấy - mã của bạn có thể dễ dàng kiểm tra đơn vị và có thể sửa đổi được.

Trong thế giới đơn lẻ, một thay đổi duy nhất đối với singleton đó về cơ bản có thể phá vỡ mọi thứ trong cơ sở mã. Không phải là một điều tốt.

+0

Rất đẹp. Tôi thậm chí sẽ nói: không bao giờ sử dụng singleton trừ khi bạn không có lựa chọn nào khác. –

2

Tôi nghĩ rằng giải pháp được chấp nhận cho vấn đề này là sử dụng tiêm phụ thuộc. Với việc tiêm phụ thuộc, bạn có thể định nghĩa các mô hình của mình là các lớp thông thường, không tĩnh và sau đó có đảo ngược vùng chứa kiểm soát "tiêm" một cá thể của mô hình của bạn khi bạn muốn nó.

Có một hướng dẫn tốt đẹp tại wpftutorial.net cho thấy làm thế nào để làm dependency injection trong WPF: http://wpftutorial.net/ReferenceArchitecture.html

+0

Thú vị. Tôi bắt đầu học DI vài tuần trước. Có vẻ như tôi sẽ chọn nó sao lưu. Cảm ơn. – sircodesalot

2

Lớp tĩnh duy nhất tôi sử dụng là một MessageBroker vì tôi cần cùng một phiên bản thông qua ứng dụng.

Nhưng ngay cả khi đó, rất có thể sử dụng Unity (hoặc một Dependency Injection/Container) khác để quản lý các phiên bản của các lớp mà bạn chỉ cần một.

Điều này cho phép bạn chèn các phiên bản khác nhau khi cần thiết (ví dụ:trong các thử nghiệm đơn vị)

BTW: tĩnh không giống như singleton. Nhưng tôi không đi vào đó. Chỉ cần tìm kiếm stackoverflow cho các câu hỏi thú vị hơn về điều đó :)

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