2015-12-14 15 views
5

Nhiều ứng dụng web mà tôi đã đóng góp (chủ yếu là ASP.NET), cần xử lý nhiều loại người dùng khác nhau.Xử lý các loại người dùng khác nhau trong một ứng dụng

Giả sử bạn có cổng thông tin trường học, cả học sinh và giáo viên đều sử dụng hàng ngày. Trên trang đầu của ứng dụng, người dùng được gặp hầu như cùng một GUI ngoại trừ một số liên kết đến một số công cụ mà chỉ các giáo viên có quyền truy cập. Giả sử đây là một công cụ nhắn tin. Giáo viên có thể có các vai trò khác nhau để xác định ai là giáo viên có thể gửi.

Ví dụ:

  • Một giáo viên với vai trò Publisher được phép gửi cho mọi người trong trường.
  • Giáo viên không có vai trò phụ chỉ được phép gửi cho mọi người trong lớp học của mình.
  • Trong tương lai, phụ huynh cũng sẽ có thể truy cập vào cổng thông tin này và xem thông tin chi tiết về con cái của họ.

Vấn đề tôi luôn gặp phải là mã của tôi luôn bị lộn xộn với các câu hỏi if khi xử lý các loại người dùng khác nhau trên ứng dụng. Không chỉ vì các loại người dùng khác nhau, mà còn bởi các quy tắc kinh doanh khác nhau. Tôi cảm thấy tôi không thể tìm thấy bất kỳ cách nào để xử lý đúng các loại người dùng khác nhau.

Tôi đoán khái niệm về vai trò trong loại ASP.NET giải quyết vấn đề này, nhưng bạn vẫn sẽ kết thúc với if -báo cáo xung quanh ứng dụng.

Câu hỏi của tôi là: Có cách nào thực hành tốt nhất về cách xử lý người dùng/loại người dùng khác nhau trong một ứng dụng mà không lây nhiễm mã bằng if -báo cáo không?

Trả lời

2

Bạn nên chia các trách nhiệm này (ví dụ như khả năng gửi của giáo viên). Bạn có thể làm điều này bằng cách sử dụng mẫu chiến lược.

Vì vậy, giáo viên có thêm thuộc tính Xuất bản, hoạt động dưới dạng giao diện. Việc triển khai có thể có nhiều lần thực hiện (ví dụ: NoPublishing cho giáo viên không có chức năng xuất bản hoặc DefaultPublishing). Mỗi giáo viên có thể có thuộc tính Publishing được thiết lập là NoPublishing hoặc DefaultPublishing. Nó thậm chí có thể được thay đổi thời gian chạy nếu cần thiết.

Một ví dụ:

public class Teacher 
{ 
    public IPublishing Publishing { get; } 
} 

interface IPublishing 
{ 
    void Send(); 
} 

public NoPublishing : IPublishing 
{ 
    public void Send() 
    { 
    // Implementatation 
    } 
} 

public PublishDefault : IPublishing 
{ 
    public void Send() 
    { 
    // Send a message the default way 
    } 
} 

Tạo một giáo viên:

var teacher = new Teacher(); 

Tạo một chiến lược xuất bản.

var defaultStrategy = new PublishDefault(); 

Kết nối chúng

teacher.Publishing = defaultStrategy; 

Bây giờ bạn có thể gửi tin nhắn theo:

teacher.Publishing.Send(); 

Tùy thuộc vào chiến lược xuất bản đã được kết nối với nó, hoặc sẽ gửi gì hoặc gửi một cái gì đó một cách mặc định .

Bạn chỉ cần khởi tạo từng chiến lược xuất bản đã sử dụng một lần và sử dụng lại nó cho mỗi giáo viên (hoặc thậm chí các lớp khác cần có khả năng gửi).

Khi bạn cần chức năng xuất bản khác, chỉ cần thêm một chiến lược mới (ví dụ: SmsPublishing, LetterPublishing etc).

Bạn thậm chí có thể thay đổi chiến lược khi đang di chuyển nếu cần (bằng cách chỉ định lại thuộc tính Xuất bản).

Tại sao không triển khai giao diện không trực tiếp trong Giáo viên?

  • Tách nguyên tắc quan tâm: IPublish chứa trách nhiệm cụ thể và khác biệt.
  • Có thể IPublish chứa chức năng có thể được sử dụng sau này trong các lớp khác nhau hoặc thậm chí các dự án khác, do đó, nó có thể tái sử dụng được nhiều hơn.
  • Thử nghiệm dễ dàng hơn vì IPublish không cần bất kỳ kiến ​​thức nào về Giáo viên.
  • Khả năng thời gian thực thay đổi hành vi xuất bản trong Giáo viên.

(lưu ý: Tôi không có trình biên dịch ở đây, vì vậy mã chỉ dành cho mục đích giải thích).

+0

Nếu bạn có các lớp khác nhau cho từng loại người dùng, bạn sẽ 'trang trí' lớp học với các hành vi (được thực hiện bằng giao diện?) Sẽ cung cấp cho họ các thuộc tính xuất bản, v.v ...? –

+0

Tôi e rằng tôi không hiểu chính xác câu hỏi của bạn. –

+0

Câu hỏi của tôi là: Bạn sẽ thực hiện điều này như thế nào? Giả sử bạn có các lớp C# khác nhau cho từng loại người dùng. Điều gì sẽ cung cấp cho họ hành vi này của ví dụ: Xuất bản? Tôi đoán điều này được trả lời bằng cách nhìn vào mô hình Chiến lược, nhưng nó sẽ thực sự ngọt ngào nếu bạn có thể phác họa mã trông như thế nào. –

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