Kiến trúc phân lớp (Đọc thêm)

4689

Bài viết được sự cho phép của tác giả Edward Thien Hoang

Khách nhau giữa kiến trúc phân lớp (Layered) và kiến trúc N-tier

HM thấy trên mạng có một số người hỏi về kiến trúc phân lớp (layered) và kiến trúc n-tier. Cũng như nhiều khái niệm khác, nếu tỉ mỉ đi vào chi tiết thì chắc không có định nghĩa thống nhất, tuy nhiên nếu để nắm ý tưởng chung, thì có lẽ tốt nhất là xem “Microsoft application architecture guide” (Microsoft viết mà sai thì chịu thôi :D). Tải miễn phí tại Microsoft, hoặc đọc trong mục patterns & practices của MSDN. Dưới đây tóm lược các ý chính:

  10 điều mọi nhà phát triển ứng dụng Android nên biết về kiến trúc Architecture
  Các khái niệm căn bản trong kiến trúc phần mềm

Kiến trúc phân lớp nhóm các chức năng liên quan đến nhau trong từng lớp (layer). Các chức năng ở một lớp khi làm nhiệm vụ của mình có thể sử dụng các chức năng mà lớp dưới nó cung cấp. Có hai dạng

  • Strict layering: Lớp trên chỉ liên hệ với lớp ở ngay dưới nó.
  • Relaxed layering: Lớp trên có thể liên hệ với nhiều lớp dưới nó.

Khi nói về kiến trúc phân lớp, chúng ta nói về cách tổ chức luận lí của code, ví dụ thông qua các package, namespace, module, v.v. Không hề có gì gợi ý rằng các lớp phải chạy trên các máy khác nhau, hay thậm chí trong các process khác nhau.

Tier là nơi các lớp chạy. Các tier phải tách biệt với nhau về memory space. Nhưng cũng không có nghĩa là các tier phải chạy trên các máy khác nhau. Trong hệ điều hành, các process tách biệt với nhau về memory space, cho nên nếu bạn có một chương trình với hai lớp Presentation và Business Services chạy trên hai process giao tiếp với nhau dùng Web services thì bạn cũng đã có một hệ thống 2-tier rồi.

Các lớp có thể ở cùng một một tier, hoặc được phân tán trên nhiều tier (n-tier). Vậy một tier có thể có nhiều lớp. Tuy nhiên, thông thường với các hệ thống lớn, các tier sẽ không ở trên cùng một máy vật lí, vì các lí do về performance, scalability, fault tolerance, security v.v.

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.

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-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.

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ộ.

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.

Lớ 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.

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.

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ầnkế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.

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.

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.

3-layes

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.mvc

Đây là bài viết trong loạt bài viết về “Tổng quan về sự phát triển của kiến trúc phần mềm“. Đây là loạt bài viết chủ yếu giới thiệu về một số mô hình kiến trúc phần mềm hay nói đúng hơn là sự phát triển của chúng qua từng giai đoạn, qua đó giúp chúng ta có cái nhìn tổng quát, up-to-date và là roadmap để bắt đầu hành trình chinh phục (đào sâu) thế giới của những bản thiết kế với vai trò là những kỹ sư và kiến trúc sư phần mềm đam mê với nghề.

Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com

Có thể bạn quan tâm:

Xem thêm Việc làm ngành it hấp dẫn trên TopDev