10 DESIGN PATTERNS DEV CẦN BIẾT
Bạn đã bao giờ tưởng tượng ra hệ thống của những doanh nghiệp lớn được thiết kế như thế nào chưa?
Trước khi phát triển các phần mềm lớn, chúng ta cần lựa chọn được kiến trúc phù hợp có khả năng cung cấp những chức năng và thuộc tính mong muốn. Do đó, chúng ta nên có kiến thức về các kiến trúc khác nhau trước khi áp dụng chúng vào thiết kế.
Bài viết này giải thích ngắn gọn về 10 mẫu kiến trúc phổ biến với cách sử dụng kèm ưu và nhược điểm của chúng.
Layered pattern
Client-server pattern
Master-slave pattern
Pipe-filter pattern
Broker pattern
Peer-to-peer pattern
Event-bus pattern
Model-view-controller pattern
Blackboard pattern
Interpreter pattern
1. Layer Pattern
Kiến trúc này được sử dụng để cấu trúc các chương trình có khả năng phân tách thành các nhóm nhiệm vụ, mỗi nhóm đều ở một mức độ trừu tượng cụ thể. Mỗi layer này sẽ cung cấp dịch vụ cho layer cao hơn tiếp theo.
4 layer thường thấy nhất của một hệ thống thông tin chung gồm:
- Presentation layer (tên khác là UI layer)
- Application layer (tên khác là service layer)
- Business logic layer (tên khác là domain layer)
- Data access layer (tên khác là persistence layer)
Sử dụng:
- Các ứng dụng máy tính để bàn nói chung.
- Ứng dụng web thương mại điện tử.
2. Client-server pattern
Kiến trúc này bao gồm hai thành phần: một server và nhiều clients. Server sẽ cung cấp dịch vụ cho nhiều clients. Ngược lại, các client gửi request tới server để xử lý và trả các service tương ứng cho phía client đó. Song song đó, máy chủ vẫn luôn tiếp tục tiếp nhận requests từ clients
Sử dụng:
- Các ứng dụng trực tuyến như email, chia sẻ tài liệu và ngân hàng.
3. Master-slave pattern
Pattern này bao gồm master và nhiều slaves. Thành phần master phân phối công việc giống nhau giữa các thành phần slaves và thu thập kết quả cuối cùng bằng cách tổng hợp kết quả các slaves trả về.
Sử dụng:
- Trong sao chép cơ sở dữ liệu, cơ sở dữ liệu chủ được coi là nguồn có thẩm quyền và cơ sở dữ liệu nô lệ được đồng bộ hóa với nó.
- Thiết bị ngoại vi được kết nối với một chiếc xe buýt trong một hệ thống máy tính (ổ đĩa chính và phụ).
4. Pipe-filter pattern
Pattern này được sử dụng để cấu trúc các hệ thống sản xuất và xử lý luồng dữ liệu. Mỗi bước xử lý được đính kèm trong một thành phần bộ lọc (filter). Dữ liệu đã xử lý sẽ được truyền qua đường ống (pipe). Những ống này có thể được sử dụng để đồng bộ hoặc buffering.
Sử dụng
- Trình biên dịch. Các bộ lọc liên tiếp thực hiện phân tích từ vựng, phân tích cú pháp, phân tích ngữ nghĩa và tạo mã.
- Quy trình làm việc trong tin sinh học.
5. Broker pattern
Mẫu này được sử dụng để cấu trúc các hệ thống phân tán với các thành phần tách rời. Các thành phần này có thể tương tác với nhau bằng các yêu cầu dịch vụ từ xa. Broker chịu trách nhiệm điều phối tương tác giữa các thành phần.
Máy chủ sẽ publish khả năng của chúng (dịch vụ và đặc điểm) cho một broker. Khách hàng yêu cầu một dịch vụ từ broker và broker sẽ chuyển hướng khách hàng đến một dịch vụ phù hợp đã đăng ký trước đó.
Sử dụng
Phần mềm môi giới tin nhắn như Apache ActiveMQ, Apache Kafka, RabbitMQ và JBoss Messaging.
6. Peer-to-peer pattern
Pattern này, các thành phần riêng lẻ được gọi là peer. Các peers này có thể hoạt động như một khách hàng, yêu cầu dịch vụ từ các peers khác và như một máy chủ, cung cấp dịch vụ cho các peers. Một peer có thể hoạt động như một khách hàng hoặc máy chủ hoặc cả hai, và có thể thay đổi vai trò của nó linh hoạt theo thời gian.
Sử dụng:
- Các mạng lưới chia sẻ file như Gnutella và G2)
- Các giao thức đa phương tiện như P2PTV và PDTP.
7. Event-bus pattern
Pattern này thường dùng để xử lý các sự kiện, gồm 4 thành phần chính: event source, event listener, channel và event bus. Message được gửi tới các channels cụ thể bằng event bus. Các listener nhận thông tin từ các channel nhất định và nhận thông báo mỗi khi có message được gửi tới chanel đó
Sử dụng:
- Phát triển Android
- Dịch vụ thông báo
8. Model-view-controller pattern
Kiến trúc này, còn được gọi là mô hình MVC, phân chia một ứng dụng tương tác thành 3 phần:
- Model – chứa chức năng và dữ liệu cốt lõi
- View – hiển thị thông tin cho người dùng (có thể xác định nhiều hơn một chế độ xem)
- Controller – xử lý yêu cầu đầu vào từ người dùng
Kiến trúc này được sử dụng để phân tách cách biểu diễn thông tin nội bộ khỏi cách thức trình bày thông tin và chấp nhận từ người dùng. Nó tách các thành phần và cho phép tái sử dụng code hiệu quả.
Sử dụng cho:
- Kiến trúc cho các ứng dụng web bằng các ngôn ngữ lập trình chính.
- Các web framework như Django và Rails.
9. Blackboard pattern
Kiến trúc này hữu ích đối với các vấn đề chưa tìm được hướng giải quyết. “Blackboard” gồm 3 thành phần chính:
- Blackboard – Một vùng không gian chung dùng để lưu trữ thông tin
- Knowledge source: Gồm các module chuyên biệt xử lý dữ liệu lấy từ blackboard, sau đó trả lại kết quả vào blackboard.
- Thành phần điều khiển – chọn, cấu hình và thực thi các modules
Tất cả các thành phần có quyền truy cập vào blackboard. Các thành phần có thể tạo ra các đối tượng dữ liệu mới được thêm vào blackboard. Các thành phần tìm kiếm các loại dữ liệu cụ thể trên blackboard và có thể tìm thấy các dữ liệu này bằng cách khớp mẫu với knowledge source.
Sử dụng:
- Nhận dạng giọng nói
- Nhận dạng và theo dõi xe
- Nhận dạng cấu trúc protein
- Giải thích tín hiệu sonar
10. Interpreter pattern
Kiến trúc này được sử dụng để thiết kế một thành phần diễn giải các chương trình được viết bằng ngôn ngữ chuyên dụng. Nó chủ yếu chỉ định cách đánh giá các dòng chương trình, được gọi là câu hoặc biểu thức được viết bằng một ngôn ngữ cụ thể. Ý tưởng cơ bản là có một class cho mỗi biểu tượng của ngôn ngữ.
Sử dụng:
- Các ngôn ngữ truy vấn cơ sở dữ liệu như SQL.
- Ngôn ngữ được sử dụng để mô tả các giao thức truyền thông
So sánh các mẫu kiến trúc:
Loại kiến trúc |
Ưu điểm |
Nhược điểm |
Layered | Một layer thấp hơn có thể được sử dụng bởi các layer cao hơn khác nhau
Các layer giúp việc tiêu chuẩn hóa dễ dàng hơn vì chúng ta có thể xác định rõ ràng các levels Có thể thực hiện thay đổi trong một layer mà không ảnh hưởng đến các layer khác |
Không được áp dụng phổ biến.
Một vài layer có khả năng bị skip trong một vài trường hợp cụ thể. |
Client-server | Tốt để mô hình hóa một tập hợp các dịch vụ mà clients yêu cầu | Yêu cầu thường được xử lý trong các luồng riêng biệt trên máy chủ
Giao tiếp giữa các quá trình gây ra overhead vì các clients khác nhau có các đại diện khác nhau. |
Master-slave | Độ chính xác – Việc thực hiện một dịch vụ được ủy quyền cho các slaves khác nhau, với các hướng triển khai khác nhau | Các slaves bị cô lập: không dùng chung các dữ liệu trạng thái
Độ trễ trong giao tiếp chủ-nô có thể là một vấn đề, ví dụ trong các hệ thống thời gian thực Mẫu này chỉ áp dụng cho một vấn đề có thể được phân tách |
Pipe-filter | Biểu diễn các xử lý đồng thời. Khi đầu vào và đầu ra bao gồm các luồng và các bộ lọc bắt đầu tính toán khi chúng nhận được dữ liệu.
Dễ dàng để thêm các bộ lọc. Hệ thống có thể được mở rộng dễ dàng. Bộ lọc có thể tái sử dụng. Có thể xây dựng các pipelines khác nhau bằng cách kết hợp lại một bộ lọc nhất định |
Hiệu quả bị hạn chế bởi quá trình lọc chậm nhất
Phí chuyển đổi dữ liệu khi chuyển từ bộ lọc này sang bộ lọc khác |
Broker | Cho phép thay đổi linh hoạt, thêm, xóa và di chuyển các đối tượng, giúp việc điều phối rõ ràng hơn cho developer | Yêu cầu tiêu chuẩn hóa các mô tả dịch vụ. |
Peer-to-peer | Hỗ trợ tính toán phi tập trung
Không lệ thuộc và sự tồn tại của 1 node nào Khả năng mở rộng cao về resource và tính toán |
Không có gì đảm bảo về chất lượng dịch vụ vì các nodes hợp tác tự nguyện.
An ninh rất khó được đảm bảo. Hiệu suất phụ thuộc vào số lượng nodes. |
Event-bus | Publisher, người đăng ký mới và kết nối có thể được thêm vào dễ dàng
Hiệu quả cho các ứng dụng phân tán cao |
Khả năng mở rộng gây ra vấn đề vì tất cả các tin nhắn đi qua cùng một event bus. |
Model-view-controller | Dễ dàng để có nhiều chế độ xem cho cùng một mô hình, có thể được kết nối và ngắt kết nối trong thời gian chạy | Tăng độ phức tạp. Có thể dẫn đến nhiều cập nhật không cần thiết cho hành động của người dùng. |
Blackboard | Dễ dàng thêm các ứng dụng mới
Mở rộng cấu trúc của không gian dữ liệu dễ dàng |
Sửa đổi cấu trúc của không gian dữ liệu sẽ gặp khó khăn vì tất cả các ứng dụng đều bị ảnh hưởng.
Có thể cần đồng bộ hóa và kiểm soát truy cập. |
Interpreter | Cho phép các hàng vi linh hoạt
Tốt cho các lập trình của người dùng cuối Tăng cường tính linh hoạt do rất dễ dàng để thay thế một chương trình diễn giải |
Bởi vì một ngôn ngữ được thông dịch thường chậm hơn một ngôn ngữ được biên dịch, hiệu suất bị giảm |
Follow page: https://www.facebook.com/pixtaVN/ để cùng đọc thêm nhiều tin tức mới nhé!
Tác giả: Vijini Mallawaarachchi
Bài viết gốc: http://bit.ly/2n9B6Ud
Người dịch: Vân Phạm, Ly Nguyễn, Nhật Anh Phạm