1. Mô hình 3 tầng (3-tiers) là gì?
Theo wikipedia thì:
“3-tiers là một kiến trúc kiểu client/server mà trong đó giao diện người dùng (UI-user interface), các quy tắc xử lý(BR-business rule hay BL-business logic), và việc lưu trữ dữ liệu được phát triển như những module độc lập, và hầu hết là được duy trì trên các nền tảng độc lập, và mô hình 3 tầng (3-tiers) được coi là một kiến trúc phần mềm và là một mẫu thiết kế.” (dịch lại từ wikipedia tiếng Anh).
Như vậy, ta có thể mô hình này phân tách ứng dụng ra làm 3 module riêng biệt, bao gồm:
- Tầng Presentation: được dùng để giao tiếp với người dùng, nhiệm vụ chính là hiển thị dữ liệu và nhận dữ liệu từ người dùng.
- Tầng Business Logic: nhiệm vụ chính là cung cấp các chức năng của phần mềm.
- Tầng Data: lưu trữ dữ liệu, cho phép lớp Business Logic có thể tìm kiếm, trích xuất, cập nhật… dữ liệu.
2. Tại sao là 3-tiers mà không phải là 3-layers?
Khi dùng từ layer, chúng ta nói tới việc phân chia ứng dụng thành các thành phần một cách logic theo chức năng hoặc theo vai trò, điều này giúp phần mềm của bạn có cấu trúc sáng sủa, dễ dùng lại, từ đó giúp việc phát triển và bảo trì dễ dàng hơn. Các layer khác nhau khi được thực thi vẫn có thể nằm trong cùng một vùng bộ nhớ của một process, và hiển nhiên việc giao tiếp giữa 2 layer có thể không phải là giao tiếp giữa 2 process, đồng nghĩa với việc chúng không liên quan tới mô hình client/server.
Trái lại, tier liên quan đến cách phân chia một cách vật lý các thành phần trên các máy tính khác nhau.
Điều làm nhiều người nhầm lẫn giữa layer và tier là chúng có cùng cách phân chia (presentation, business, data), tuy nhiên trên thực tế chúng khác nhau. Vì cách phân chia như trên nên 1 tier có thể chứa nhiều hơn 1 layer.
3. 3-tiers có những ưu và nhược điểm gì?
3-tiers là một kiến trúc phần mềm, có nghĩa là bạn có thể dùng nó để xây dựng nên bộ khung tổng thể của ứng dụng. Tuy nhiên bạn cần chú ý những ưu và nhược điểm sau đây để áp dụng nó một cách đúng đắn.
Ưu điểm:
- Dễ dàng mở rộng, thay đổi quy mô của hệ thống: Khi cần tải lớn, người quản trị có thể dễ dàng thêm các máy chủ vào nhóm, hoặc lấy bớt ra trong trường hợp ngược lại.
Nhược điểm:
- Việc truyền dữ liệu giữa các tầng sẽ chậm hơn vì phải truyền giữa các tiến trình khác nhau (IPC), dữ liệu cần phải được đóng gói -> truyền đi -> mở gói trước khi có thể dùng được.
- Việc phát triển ứng dụng phức tạp hơn.
4. Những công nghệ nào hỗ trợ xây dựng các ứng dụng 3-tiers?
Tùy thuộc vào nền tảng, bạn có thể chọn một trong các công nghệ như EJB (J2EE), COM+ (Windows), hay cũng có thể dùng các máy chủ web như nền tảng xây dựng lớp giữa (dùng webservice). Tuy nhiên, EJB và COM+ là hai tùy chọn tốt nhất vì nó có nhiều công nghệ hỗ trợ như Object Pooling, Authentication và Authority, Resource management, Remote Object Access, Transaction…
Các công nghệ truyền thông điệp như JMS hay MSMQ cũng hỗ trợ nhiều trong việc tạo các lời gọi không đồng bộ.
5. Các ứng dụng máy chủ cơ sở dữ liệu có liên quan gì đến mô hình này không?
Có, nó đóng vai trò tầng Data.
Bản thân khi hoạt động, máy chủ CSDL trở thành 1 phần không thể thiếu trong hệ thống, nó chính là nơi chứa dữ liệu của bạn. Việc dùng một hệ CSDL sẵn có là việc nên làm vì nó giúp chúng ta rất nhiều công sức, nhưng điều đó không có nghĩa là nó không thuộc vào hệ thống của chúng ta, chỉ khác ở chỗ đây là một tầng Data được xây dựng sẵn.
6. Lớp Data Access Layer (DAL) thuộc tầng nào?
Lớp Business Logic.
Trái với nhiều người nghĩ, cứ cái gì có chữ Data thì nó phải thuộc lớp 3, tuy nhiên vì DAL chỉ đóng vai trò truy vấn, chứ bản thân nó không cung cấp dữ liệu, và nó vẫn phải được thực thi bởi các Business Object, vậy nên trong đa số trường hợp nó sẽ nằm trong lớp 2 (một số thiết kế tách nó riêng thành 1 tier).
Nên nhớ rằng việc tách riêng ra một DAL giúp bạn có một thiết kế tốt hơn, nhưng không phải là bắt buộc. Và việc tự tạo một DAL với việc dùng chung một tập các lớp truy xuất dữ liệu được cung cấp bởi một công nghệ/công cụ có sẵn như LINQ to SQL, NHibernate hay Entity Framework không có gì khác nhau về kiến trúc hệ thống.
Có lẽ vì sự tồn tại của DAL mà rất nhiều người hiểu nhầm giữa 3-tiers và 3-layers.
7. Tôi nên kiểm tra dữ liệu nhập bởi người dùng ở lớp nào?
Kiểm tra dữ liệu ở lớp giao diện giúp giảm tải cho lớp giữa, phản hồi cũng nhanh hơn. Tuy nhiên sẽ khó có thể đảm bảo sẽ không có kẽ hở để những dữ liệu không hợp lệ được chuyển đến lớp Business Logic và thậm chí lớp Data, vậy nên thông thường việc kiểm tra nên được đặt trong tất cả các lớp tùy thuộc vào từng loại dữ liệu và phép kiểm tra.
8. Tôi có một ứng dụng, nó không có giao diện người dùng vì nó chỉ nhận dữ liệu từ các ứng dụng khác, tôi có thể viết theo mô hình 3-tiers được không?
Có, từ Presentation ở đây không mang ý nghĩa giao diện tương tác với người dùng, mà nó có nghĩa rộng hơn là phần tương tác với các hệ thống bên ngoài, ví dụ Presentation có thể là phần kết nối để truy xuất dữ liệu đến một hệ thống khác, hay một cổng để tiếp nhận các lệnh do một hệ thống khác chuyển đến.
9. Tôi nên đọc thêm tài liệu nào để hiểu kỹ hơn về mô hình 3 lớp và cách dùng hiệu quả các công nghệ như EJB và COM+?
Bạn có thể đọc thêm 2 quyển:
- Designing Enterprise Applications with the J2EE Platform, Second Edition, dành cho người làm J2EE (http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/).
- Application Architecture Guide 2.0, quyển này của các bác MS (http://www.codeplex.com/AppArchGuide/)
Ngay cả khi chưa viết ứng dụng mới mô hình 3-tiers thì bạn cũng RẤT RẤT RẤT nên đọc 2 quyển trên.
10. 3-tiers có giống MVC không?
Không, trong 3-tiers, quá trình đi theo chiều dọc, bắt đầu từ Presentation, sang BL, rồi tới Data, và từ Data, chạy ngược lại BL rồi quay ra lại Presentation.
Còn trong MVC, dữ liệu được nhận bởi View, View sẽ chuyển cho Controller cập nhật vào Model, rồi sau đó dữ liệu trong Model sẽ được đưa lại cho View mà không thông qua Controller, do vậy luồng xử lý này có hình tam giác.
Theo wikipedia thì:
“3-tiers là một kiến trúc kiểu client/server mà trong đó giao diện người dùng (UI-user interface), các quy tắc xử lý(BR-business rule hay BL-business logic), và việc lưu trữ dữ liệu được phát triển như những module độc lập, và hầu hết là được duy trì trên các nền tảng độc lập, và mô hình 3 tầng (3-tiers) được coi là một kiến trúc phần mềm và là một mẫu thiết kế.” (dịch lại từ wikipedia tiếng Anh).
Như vậy, ta có thể mô hình này phân tách ứng dụng ra làm 3 module riêng biệt, bao gồm:
- Tầng Presentation: được dùng để giao tiếp với người dùng, nhiệm vụ chính là hiển thị dữ liệu và nhận dữ liệu từ người dùng.
- Tầng Business Logic: nhiệm vụ chính là cung cấp các chức năng của phần mềm.
- Tầng Data: lưu trữ dữ liệu, cho phép lớp Business Logic có thể tìm kiếm, trích xuất, cập nhật… dữ liệu.
2. Tại sao là 3-tiers mà không phải là 3-layers?
Khi dùng từ layer, chúng ta nói tới việc phân chia ứng dụng thành các thành phần một cách logic theo chức năng hoặc theo vai trò, điều này giúp phần mềm của bạn có cấu trúc sáng sủa, dễ dùng lại, từ đó giúp việc phát triển và bảo trì dễ dàng hơn. Các layer khác nhau khi được thực thi vẫn có thể nằm trong cùng một vùng bộ nhớ của một process, và hiển nhiên việc giao tiếp giữa 2 layer có thể không phải là giao tiếp giữa 2 process, đồng nghĩa với việc chúng không liên quan tới mô hình client/server.
Trái lại, tier liên quan đến cách phân chia một cách vật lý các thành phần trên các máy tính khác nhau.
Điều làm nhiều người nhầm lẫn giữa layer và tier là chúng có cùng cách phân chia (presentation, business, data), tuy nhiên trên thực tế chúng khác nhau. Vì cách phân chia như trên nên 1 tier có thể chứa nhiều hơn 1 layer.
3. 3-tiers có những ưu và nhược điểm gì?
3-tiers là một kiến trúc phần mềm, có nghĩa là bạn có thể dùng nó để xây dựng nên bộ khung tổng thể của ứng dụng. Tuy nhiên bạn cần chú ý những ưu và nhược điểm sau đây để áp dụng nó một cách đúng đắn.
Ưu điểm:
- Dễ dàng mở rộng, thay đổi quy mô của hệ thống: Khi cần tải lớn, người quản trị có thể dễ dàng thêm các máy chủ vào nhóm, hoặc lấy bớt ra trong trường hợp ngược lại.
Nhược điểm:
- Việc truyền dữ liệu giữa các tầng sẽ chậm hơn vì phải truyền giữa các tiến trình khác nhau (IPC), dữ liệu cần phải được đóng gói -> truyền đi -> mở gói trước khi có thể dùng được.
- Việc phát triển ứng dụng phức tạp hơn.
4. Những công nghệ nào hỗ trợ xây dựng các ứng dụng 3-tiers?
Tùy thuộc vào nền tảng, bạn có thể chọn một trong các công nghệ như EJB (J2EE), COM+ (Windows), hay cũng có thể dùng các máy chủ web như nền tảng xây dựng lớp giữa (dùng webservice). Tuy nhiên, EJB và COM+ là hai tùy chọn tốt nhất vì nó có nhiều công nghệ hỗ trợ như Object Pooling, Authentication và Authority, Resource management, Remote Object Access, Transaction…
Các công nghệ truyền thông điệp như JMS hay MSMQ cũng hỗ trợ nhiều trong việc tạo các lời gọi không đồng bộ.
5. Các ứng dụng máy chủ cơ sở dữ liệu có liên quan gì đến mô hình này không?
Có, nó đóng vai trò tầng Data.
Bản thân khi hoạt động, máy chủ CSDL trở thành 1 phần không thể thiếu trong hệ thống, nó chính là nơi chứa dữ liệu của bạn. Việc dùng một hệ CSDL sẵn có là việc nên làm vì nó giúp chúng ta rất nhiều công sức, nhưng điều đó không có nghĩa là nó không thuộc vào hệ thống của chúng ta, chỉ khác ở chỗ đây là một tầng Data được xây dựng sẵn.
6. Lớp Data Access Layer (DAL) thuộc tầng nào?
Lớp Business Logic.
Trái với nhiều người nghĩ, cứ cái gì có chữ Data thì nó phải thuộc lớp 3, tuy nhiên vì DAL chỉ đóng vai trò truy vấn, chứ bản thân nó không cung cấp dữ liệu, và nó vẫn phải được thực thi bởi các Business Object, vậy nên trong đa số trường hợp nó sẽ nằm trong lớp 2 (một số thiết kế tách nó riêng thành 1 tier).
Nên nhớ rằng việc tách riêng ra một DAL giúp bạn có một thiết kế tốt hơn, nhưng không phải là bắt buộc. Và việc tự tạo một DAL với việc dùng chung một tập các lớp truy xuất dữ liệu được cung cấp bởi một công nghệ/công cụ có sẵn như LINQ to SQL, NHibernate hay Entity Framework không có gì khác nhau về kiến trúc hệ thống.
Có lẽ vì sự tồn tại của DAL mà rất nhiều người hiểu nhầm giữa 3-tiers và 3-layers.
7. Tôi nên kiểm tra dữ liệu nhập bởi người dùng ở lớp nào?
Kiểm tra dữ liệu ở lớp giao diện giúp giảm tải cho lớp giữa, phản hồi cũng nhanh hơn. Tuy nhiên sẽ khó có thể đảm bảo sẽ không có kẽ hở để những dữ liệu không hợp lệ được chuyển đến lớp Business Logic và thậm chí lớp Data, vậy nên thông thường việc kiểm tra nên được đặt trong tất cả các lớp tùy thuộc vào từng loại dữ liệu và phép kiểm tra.
8. Tôi có một ứng dụng, nó không có giao diện người dùng vì nó chỉ nhận dữ liệu từ các ứng dụng khác, tôi có thể viết theo mô hình 3-tiers được không?
Có, từ Presentation ở đây không mang ý nghĩa giao diện tương tác với người dùng, mà nó có nghĩa rộng hơn là phần tương tác với các hệ thống bên ngoài, ví dụ Presentation có thể là phần kết nối để truy xuất dữ liệu đến một hệ thống khác, hay một cổng để tiếp nhận các lệnh do một hệ thống khác chuyển đến.
9. Tôi nên đọc thêm tài liệu nào để hiểu kỹ hơn về mô hình 3 lớp và cách dùng hiệu quả các công nghệ như EJB và COM+?
Bạn có thể đọc thêm 2 quyển:
- Designing Enterprise Applications with the J2EE Platform, Second Edition, dành cho người làm J2EE (http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/).
- Application Architecture Guide 2.0, quyển này của các bác MS (http://www.codeplex.com/AppArchGuide/)
Ngay cả khi chưa viết ứng dụng mới mô hình 3-tiers thì bạn cũng RẤT RẤT RẤT nên đọc 2 quyển trên.
10. 3-tiers có giống MVC không?
Không, trong 3-tiers, quá trình đi theo chiều dọc, bắt đầu từ Presentation, sang BL, rồi tới Data, và từ Data, chạy ngược lại BL rồi quay ra lại Presentation.
Còn trong MVC, dữ liệu được nhận bởi View, View sẽ chuyển cho Controller cập nhật vào Model, rồi sau đó dữ liệu trong Model sẽ được đưa lại cho View mà không thông qua Controller, do vậy luồng xử lý này có hình tam giác.
Không có nhận xét nào:
Đăng nhận xét