Cập nhật thông tin chi tiết về Kiến Trúc Phân Lớp (Layered Architecture) mới nhất trên website Tvzoneplus.com. Hy vọng nội dung bài viết sẽ đáp ứng được nhu cầu của bạn, chúng tôi sẽ thường xuyên cập nhật mới nội dung để bạn nhận được thông tin nhanh chóng và chính xác nhất.
Là dạng kiến trúc rất phổ biến ngày nay, chắc chắn ai cũng đã từng nghe qua về kiến trúc 3 lớp, MVC, MVVM,… Tất cả đều có chung một mục đích là tổ chức, phân rã mã nguồn theo nhiều chức năng và nhiệm vụ khác nhau trong hệ thống.
In an object-oriented program, UI, database, and other support code often gets written directly into the business objects. Additional business logic is embedded in the behaviour of UI widgets and database scripts. This happens because it is the easiest way to make things work, in the short run.When the domain-related code is diffused through such a large amount of other code, it becomes extremely difficult to see and to reason about. Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. Implementing coherent, model-driven objects becomes impractical. Automated testing is awkward. With all the technologies and logic involved in each activity, a program must be kept very simple or it becomes impossible to understand.
Eric Evans 2014, Domain-Driven Design Reference
Sự phân lớp là gì
Trong một hệ thống phân lớp, thì một lớp:
Phụ thuộc vào các lớp bên dưới nó;
Không biết và không phụ thuộc vào các lớp bên trên sử dụng nó;
Trong kiến trúc phân lớp, các layer có thể được design theo hướng nghiêm ngặt, một layer chỉ có hiểu biết và sử dụng layer ngay bên dưới nó, hoặc theo hướng linh hoạt hơn, nghĩa là một layer có thể sử dụng tất cả các layer ở dưới nó. Cả Martin Fowler và tôi đều tán đồng cách thứ 2 để tạo nên sự linh hoạt, tránh phải tạo ra các proxy method (hoặc thậm chí là proxy class) trong các layer trung gian chỉ để truyền tải thông điệp từ lớp bên trên nó xuống lớp phía dưới nó. Việc sử dụng các layer trung gian như vậy được coi là 1 anti-pattern với tên gọi Lasagna Architecture.
Đôi khi các layer được thiết kế sao cho domain layer hoàn toàn không muốn presentation layer biết đến data source layer. Tuy nhiên, và thường xuyên, presentation layer nên truy cập trực tiếp đến data source layer. Mặc dù điều này không tinh khiết, nhưng nó có xu hướng hoạt động tốt hơn trong thực tế.
Sometimes the layers are arranged so that the domain layer completely hides the data source from the presentation. More often, however, the presentation accesses the data store directly. While this is less pure, it tends to work better in practice.
Fowler 2002, Patterns of Enterprise Application Architecture
Ưu điểm:
Chúng ta chỉ cần hiểu những lớp bên dưới lớp chúng ta đang làm;
Mỗi lớp có thể được thay thế bởi một thể hiện tương đương (equivalent implementation), không ảnh hưởng đến các lớp khác;
Một lớp có thể được sử dụng bởi một số lớp cấp cao khác nhau.
Những bất lợi là:
Lớp không thể đóng gói (encapsulate) tất cả mọi thứ (một field được thêm vào UI, rất có thể cũng cần phải được thêm vào DB);
Các lớp bổ sung (extra) có thể gây ảnh hưởng đến hiệu suất, đặc biệt nếu ở các tier khác nhau.
Cùng điểm qua sự tiến hóa của kiến trúc phân lớp qua các thời kỳ
Những năm 60 và 70
Những application lúc đó (hầu như) hoàn toàn khác với ngày nay. Chẳng có GUI (cái chỉ mới xuất hiện vào những năm đầu thập nên 90), tất cả application được sử dụng thông qua CLI (Command-line interface) dưới dạng cửa sổ console với nhiệ vụ đơn giản là nhận input (bàn phím) từ người dùng và xuất ngược trở ra màn hình. Cũng chẳng có khái niệm Client-Server, tất cả được đóng gói thành một bản cài đặt trên từng máy trạm.
Vì ứng dụng lúc đó quá đơn giản nên chẳng ai buồn nghĩ tới chuyện phân tách layer/tier này nọ làm gì. Ta có thể gọi các ứng dụng lúc đó với kiến trúc 1 layer, 1 tier, chúng không thể mở rộng (scalable), ví dụ, nếu chúng ta muốn cập nhật phiên bản mới, thì chỉ có cách là cài đặt chúng trên từng máy trạm (client)
Giai đoạn những năm 80 và 90
Giai đoạn này đã bắt đầu xuất hiện các ứng dụng dành cho doanh nghiệp (enterprise) với lượng người sử dụng dùng máy tính cá nhân (desktop computer) để truy cập vào ứng dụng thông qua network.
Có 3 layers được chia ra:
User Interface (Presentation): là những chương trình chạy trên desktop / CLI hoặc các web page. Các chương trình client lúc này thường là các rich client (nơi luồng công việc và kiểm tra input đầu vào đặt ở client)
Business Logic (Domain): là nơi đặt các logic về nghiệp vụ chính của hệ thống, layer này sẽ tiếp nhận các request từ phía Client, xử lý và lưu trữ data thông qua Data source layer.
Data source: nhiệm vụ chính của layer này là thực thi các tác vụ lưu trữ dữ liệu và liên lạc với các applications khác (được request từ business logic layer).
Đây chính là mô hình 3 lớp (3-layers) kinh điển chúng ta đã từng biết khi còn là sinh viên. Tuy nhiên xét về mặt các lớp vật lý (tier) thì ứng dụng thường được tổ chức ở mức 2 tier hay còn gọi là Client-Server. Client side sẽ chứa Presentation layer, Server side sẽ chứa Business logic layer and Data source layer.
Kiến trúc này có thể giải quyết các vấn đề về mở rộng, tuy nhiên vẫn còn hạn chế. Các ứng dụng dạng rich-client khi được cài đặt ở một số lượng lớn máy trạm thì việc update, mở rộng sẽ gặp nhiều khó khăn.
Vào giữa những năm 90
Đây là giai đoạn thế giới công nghệ có những chuyển biến mạnh mẽ. từ những năm 95 đến 2005, thế giới bắt đầu dịch chuyển lên “mây”. Số lượng người dùng tăng lên, độ phức tạp về ứng dụng tăng lên, vấn đề về cơ sở hạ tầng cũng ngày càng phức tạp. Từ đó dẫn đến việc cải tiến các mô hình kiến trúc sao cho phù hợp với nhu cầu, kiến trúc phân lớp vào thời điểm này được biến đổi như sau:
Web browser: làm nhiệm vụ render và gửi / nhận request tới server.
Application server: chứa presentation layer, the application layer, the domain layer, và the persistence layer.
Database server: được tối ưu cho mục đích lưu trữ dữ liệu
Đây là một architecture pattern 3 lớp vật lý (3-tier) hay n-tier. Tất cả logic điều được move lên phía server, do đó giải quyết triệt để vấn đề về mở rộng, client bây giờ chỉ làm nhiệm vụ render mà không cần biết các thay đổi từ server ra sao.
Những năm 2000 tới nay
Domain Driven Design là từ khóa rất hot trong giới kỹ nghệ lập trình. Eric Evan là người khởi xướng thuật ngữ này vào năm 2003 với cuốn sách nhan đề: Domain-Driven Design: Tackling Complexity in the Heart of Softwar e. Cuốn sách chứa đựng rất nhiều khái niệm ảnh hưởng sâu rộng đến cách chúng ta định hình nên các bản thiết kế hiện nay.
User Interface
Chịu trách nhiệm trong việc render và truyền tải thông điệp từ client tới server. Client ở đây có thể là người dùng hoặc những application khác, gần giống với khái niệm Boundary object trong bài viết về EBI Architecture của Ivar Jacobson, chúng ta sẽ làm rõ thêm khái niệm này.
Có 1 từ rất hay đó là Orchestration, nó được dùng trong SOA/ESB như là một điều phối viên. Ví dụ, Application Layer nhận 1 request từ Presentation, nó phải gọi xuống Domain Layer để thực hiện công việc đó, nhưng không đơn giản là 1 lời gọi đơn giản xuống Domain Layer, mà nó cần phải biết gọi Domain object nào, bao nhiêu Domain object để có thể thực hiện xong công việc, và trả về dữ liệu cho Presentation. Cho nên mình gọi nó là Application Services và Domain Services Layer.
Infrastructure
Các common technical facilities dùng chung cho cả hệ thống, ví dụ như logging, persistance, messaging…
Anti-pattern: Lasagna Architecture
Là tên gọi cho anti-pattern trong kiến trúc phân lớp, khi:
Chúng ta quyết định đề ra các chính sách nghiêm ngặt về việc liên lạc giữa các layer (một layer chỉ có thể liên lạc với layer ở dưới ngay nó). Trong trường hợp như vậy, rất có thể ta phải tạo ra rất nhiều proxy method, proxy class trong các layer trung gian cốt chỉ để by-pass việc communication này, gây tốn công và khó chịu khi làm việc. Vì vậy, hãy giảm bớt sự nghiêm ngặt để có thể trực tiếp đi thẳng tới các layer phía dưới nó mà không cần qua trung gian.
Một thay đổi nhỏ cũng có thể gây ảnh hưởng đến cả hệ thống. Ví dụ việc refactor lại 1 layer nào đó có thể gây ra hậu quả to lớn so với lợi ích nhận lại.
Tạo quá nhiều layer dẫn đến việc phức tạp cho cả hệ thống.
Có quá nhiều tier sẽ dẫn đến sự phức tạp và giảm performance trong hệ thống.
Chúng ta tổ chức, đóng gói layer theo chức năng kỹ thuật (functional) của nó, ví dụ như UI, Domain, DB,.. mà không chia theo chức năng nghiệp vụ (component) như Product, Payment, Checkout, làm mất đi khả năng module hóa và đóng gói (encapsulation) theo domain concept.
Kết luận
Layered Architecture là một cách chia để trị mối quan tâm, đóng gói và tách riêng, bằng cách nhóm các đơn vị mã bằng vai trò chức năng của chúng trong ứng dụng.
Tuy nhiên, như hầu hết mọi thứ trong cuộc sống, quá nhiều sẽ phản tác dụng! Vì vậy, quy tắc của ngón tay cái (rule-of-thumb) là: Chỉ sử dụng các lớp chúng ta cần, các lớp chúng ta cần, và không có gì nhiều hơn nữa! Chúng ta không được đuổi theo đuổi một chén thánh kiến trúc, cái không hề tồn tại. Những gì tồn tại là một nhu cầu, và sự phù hợp tốt nhất có thể cho nhu cầu đó. Đó là một phần của Lean, tiện thể.
Hơn nữa, điều quan trọng cần lưu ý là phương pháp tiếp cận top/down này đã lỗi thời. Không còn là những gì chúng ta nên làm trong phát triển phần mềm hiện đại, có những cách nghĩ mới và tốt hơn về một lớp ứng dụng. Tôi sẽ nói về sau đó trong bài viết sau.
Đâ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 được tham khảo từ: Layered Architecture Tổng hợp bởi edwardthienhoang
Định Nghĩa Organizational Architecture / Kiến Trúc Tổ Chức Là Gì?
Khái niệm thuật ngữ
Organizational Architecture bao gồm sự phân bố quyền sở hữu, các chương trình khuyến khích và các hệ thống giám sát
Tìm Hiểu Về Mô Hình 3 Lớp (3 Layer)
Do dạo gần đây mình đang làm về một số app desktop sử dụng mô hình 3 lớp, nên mình sẽ note lại những điều cần chú ý trong mô hình 3 lớp.
1. Mô hình 3 lớp là gì??
Khái niệm:
Mô hình 3 lớp hay còn được gọi là mô hình Three Layer(3-Layer), mô hình này ra đời nhằm phân chia các thành phần trong hệ thống, các thành phần cùng chức năng sẽ được nhóm lại với nhau và phân chia công việc cho từng nhóm để dữ liệu không bị chồng chéo và chạy lộn xộn.
Mô hình này phát huy hiệu quả nhất khi bạn xây dựng một hệ thống lớn, việc quản lý code và xử lý dữ liệu lỗi dễ dàng hơn.
Ưu điểm:
Phân loại rõ ràng các lớp có các nhiệm vụ khác nhau. Từ đó ta có thể quản lý và maintain project tốt hơn.
Dễ dàng phân loại các hành động tại Business.
Dễ dàng phân loại các hàm truy xuất tại Database, phân loại hàm theo table,…
Ứng dụng được cho các project lớn ở bên ngoài.
…
Lưu ý khi xây dựng mô hình 3 lớp:
Cần một solution riêng cho project.
Cần 3 project khác nhau để làm nên 3 lớp, tên Project đặt như sau:
Lớp GUI: (VD: QuanLy_GUI)
Lớp Business: (VD: QuanLy_BUS)
Lớp Data Access: (VD: QuanLy_DAL)
Lớp DTO: (VD: QuanLy_DTO)
2. Giới thiệu về mô hình 3 lớp
Mô hình 3-layer gồm có 3 phần chính:
Presentation Layer (GUI)
Lớp này có nhiệm vụ chính là giao tiếp với người dùng. Nó gồm các thành phần giao diện ( winform, webform, …) và thực hiện các công việc như nhập liệu, hiển thị dữ liệu, kiểm tra tính đúng đắn dữ liệu trước khi gọi lớp Business Logic Layer (BLL).
Business Logic Layer (BLL) Layer này phân ra 2 thành nhiệm vụ:
Đây là nơi đáp ứng các yêu cầu thao tác dữ liệu của GUI layer, xử lý chính nguồn dữ liệu từ Presentation Layer trước khi truyền xuống Data Access Layer và lưu xuống hệ quản trị CSDL.
Đây còn là nơi kiểm tra các ràng buộc, tính toàn vẹn và hợp lệ dữ liệu, thực hiện tính toán và xử lý các yêu cầu nghiệp vụ, trước khi trả kết quả về Presentation Layer.
Data Access Layer (DAL)
3. Các thành phần của từng lớp
Presentation Layer (GUI)
Có hai thành phần chính sau đây với những tác vụ cụ thể :
UI Components : gồm các thành phần tạo nên giao diện của ứng dụng (GUI). Chúng chịu trách nhiệm thu nhận và hiển thị dữ liệu cho người dùng… Ví dụ : textbox, button, combobox, …
UI Process Components : là thành phần chịu trách nhiệm quản lý các quá trình chuyển đổi giữa các UI… Ví dụ : Sắp xếp quá trình kiểm tra thông tin khách hàng:
Hiển thị màn hình tra cứu ID.
Hiển thị màn hình thông tin chi tiết khách hàng tương ứng.
Hiển thị màn hình liên lạc với khách hàng.
Bussiness Layer (BLL)
Lớp này gồm 4 thành phần:
Service Interface : là thành phần giao diện lập trình mà lớp này cung cấp cho lớp Presentation sử dụng.
Bussiness Workflows : chịu trách nhiệm xác định và điều phối các quy trình nghiệp vụ gồm nhiều bước và kéo dài. Những quy trình này phải được sắp xếp và thực hiện theo một thứ tự chính xác.
Bussiness Components : chịu trách nhiệm kiểm tra các quy tắc nghiệp vụ, ràng buộc logic và thực hiện các công việc . Các thành phần này cũng thực hiện các dịch vụ mà Service Interface cung cấp và Business Workflows sẽ sử dụng nó.
Bussiness Entities : thường được sử dụng như Data Transfer Objects ( DTO ) . Bạn có thể sử dụng để truyền dữ liệu giữa các lớp (Presentation và Data Layer). Chúng thường là cấu trúc dữ liệu ( DataSets, XML,… ) hay các lớp đối tượng đã được tùy chỉnh. Ví dụ : tạo 1 class Student lưu trữ các dữ liệu về tên, ngày sinh, ID, lớp.
Data Layer (DAL)
Data Access Logic Components : chịu trách nhiệm chính lưu trữ và truy xuất dữ liệu từ các nguồn dữ liệu (Data Sources) như XML, file system,… Hơn nữa còn tạo thuận lợi cho việc dễ cấu hình và bảo trì. Service Agents : giúp bạn gọi và tương tác với các dịch vụ từ bên ngoài một cách dễ dàng và đơn giản.
Để hiểu rõ hơn về cấu trúc và cách xây dựng của mô hình 3 lớp, chúng ta cùng tham khảo một ví dụ về mô hình quản lí Uber gồm các lớp BUS, DAO, DTO, GUI ( Lớp GUI sẽ là phần chương trình chính). Do ở đây mình lười nên mình gom lại thành các folder để dễ gọi nhau :v (Nếu làm đúng chuẩn thì phải là tạo ra các project trong Solution mới đúng)
Đầu tiên là GUI gồm các button, texbox, … mà người dùng sẽ tương tác với màn hình giao diện này.
Lớp DTO, chứa những dữ liệu được xây dựng dưới dạng lớp đối tượng. Mỗi một User sẽ mang những thuộc tính sau:
Các nghiệp vụ xử lý chính sẽ được đặt ở lớp BUS (hay là BLL) gồm các nghiệp vụ insert, update, delete,…
namespace UberManagerment_WPF.BUS { public class List_Driver_BUS { private static List_Driver_BUS instance; public static List_Driver_BUS Instance { get { if (instance == null) instance = new List_Driver_BUS(); return instance; } } public void ShowListDriver(DataGrid data) { data.ItemsSource = List_Driver_DAO.Instance.ShowListDriver(); } public void ShowListDriverMotobike(DataGrid data) { data.ItemsSource = List_Driver_DAO.Instance.ShowListDriver_Motobike(); } public void ShowListDriverCar(DataGrid data) { data.ItemsSource = List_Driver_DAO.Instance.ShowListDriver_Car(); } public void ShowListDriverTaxiCar(DataGrid data) { data.ItemsSource = List_Driver_DAO.Instance.ShowListDriver_taxiCar(); } } }Và cuối cùng là lớp DAO ( hay là DAL ). Truy vấn đến cơ sở dữ liệu
All Rights Reserved
Hệ Môđun Trong Kiến Trúc
3.4.2. Hệ môđun trong kiến trúc – xây dựng
Yêu cầu thống nhất hóa trong kiến trúc xây dựng đòi hỏi công tác thiết kế và sản xuất các sản phẩm xây dựng phải được căn cứ trên một đơn vị đo lường thống nhất. Ngay từ cổ xưa, từ khi con người biết tự sản xuất các của cải vật chất đã đòi hỏi họ phải cân nhắc rút kinh nghiệm tìm ra những chỉ số chung để hoạt động sản xuất, trao đổi có nhiều khả năng đạt hiệu quả. Thí dụ nhiều nơi đã dùng đơn vị đo gang tay, tầm sải tay, chiều dài cánh khuỷu tay để quyết định bán kính chân cột của thức La Mã, để định mức “rui 1 mực” của thức cổ truyền Việt Nam… Trong xây dựng hiện đại, yêu cầu thống nhất hóa, điển hình hóa đòi hỏi phải sử dụng một hệ thống cơ sở chọn lựa kích thước gọi là hệ môđun thống nhất.
“Môđun” là đơn vi đo quy ước dùng để điều họp kích thước ở bộ phận kết cấu (cấu kiện) và kiến trúc (chi tiết kiến trúc) với nhau nhằm để các bộ phận này có thể trao đổi phối hợp lẫn cho nhau, được sử dụng lặp lại càng nhiều càng tốt trên thực tế sử dụng. Điều hợp kích thước tức nghiên cứu chọn lựa cho được những loạt kích thước điển hình và có hạn chế trong xây đựng theo mục đích thống nhất hóa, nhằm hạn chế số kiểu kích thước
có mặt trên thị trường sản phẩm xây dựng. Áp dụng hệ môđun thống nhất có ưu điểm:
1 Giảm số kiểu kích thước tạo điều kiện tốt cho nâng cao chất lượng và hạ giá thành sản phẩm sản xuất hàng loạt ở nhà máy, tạo điều kiện thuận lợi cho chuyên môn hóa và công nghiệp hóa ngành xây dựng.
– Tạo điều kiện để đẩy nhanh công tác thiết kế điển hình, tiêu chuẩn hóa thiết kế và phát triển ngành xây dựng theo kiểu lắp ghép, công nghiệp hóa.
– Tạo điều kiện để hòa nhập kinh tế khu vực và thế giới cho sự hợp tác kinh tế – khoa học – kỹ thuât giữa các quốc gia, các tổ chức xây dựng Theo tiêu chuẩn Việt Nam (TCVN 5568: 1991) môđun gốc có ký hiệu M = 100mm (quốc tế quy định). Đó là kích thước quy định khỏi đầu của hệ môđun thống nhất, từ đó để đinh ra các kích thước lớn hơn hoặc nhỏ hơn cho từng loại cấu kiện hay chi tiết kiến trúc (gọi là các môđun mở rộng).
Môđun mở rộng chia ra môđun bội số và môđun ước số.
Trên thực tế xây dựng, các môđun mở rộng ở các nước có thể còn quy định khác nhau. Việt Nam và một số nước dùng các môđun bội số sau:
30 M cho các kích thước mặt bằng đến 18 000 mm.
15 M cho các kích thước mặt bằng đến 12 000 mm.
6 M cho các kích thước mặt bằng đến 7 200 mm.
3 M và 2 M cho các kích thước mặt bằng đến 3 600 mm.
Môđun ước số hay gặp là 1/2 M, 1/5 M, 1/10 M cùng với môđun gốc M được áp dụng cho các bộ phận kết cấu và kiến trúc, có trị số không quá 1200 mm.
Việc áp dụng môđun quy định chỉ dùng trong các kích thước cơ bản và kích thước danh nghĩa. Kích thước cơ bản là những kích thước tương ứng với ba thông số chính của ngôi nhà là bước, nhịp hay khẩu độ và chiều cao tầng nhà. Còn kích thước tương ứng với từng cấu kiện, bộ phận kiến trúc gọi 1 ằ kích thước riêng trong đó bao hàm ba loại kích thước: danh nghĩa, cấu tạo và thực tế.
Bước nhà (có ký hiệu là B) là khoảng cách trục kết cấu (tường hay cột) đo theo chiều vuông góc với phương làm việc chính của kết cấu đỡ sàn. Theo dọc nhà gọi là bước dọc, theo ngang nhà gọi là bước ngang.
Nhịp hay khẩu độ (ký hiệu L) là khoảng cách trục tường, tim cột đo theo phương làm việc chính của kết cấu đỡ sàn, hay mái (thường cũng là chiều dài các dầm, xà chính, các dàn hay vì kèo) (hình 1.3.9).
Chiều cao tầng nhà (ký hiệu H) được quy định tính như sau:
– Với nhà nhiều tầng, trừ tầng áp mái, H là khoảng cách đứng giữa hai sàn đo từ mật sàn này đến mặt sàn kia.
– Với tầng áp mái khi có trần treo sẽ tính từ mặt sàn hoàn chỉnh đến độ cao cách mặt trần về phía trên một khoảng cách bằng chiều dày trung bình của sàn trung gian (cả mặt hoàn thiện), nếu không có trần thì H chỉ tính đến mặt dưới của kết cấu chịu lực chính của mái (dầm, dàn quá giang vì kèo,…).
– Với nhà một tầng quy định như tầng áp mái không trần hay cao hơn trần 20 cm.
– Với kết cấu mái vòm, mái khẩu độ lớn thì H được tính đến chân vòm hay mặt thấp nhất của kết cấu chịu lực chính.
Bạn đang xem bài viết Kiến Trúc Phân Lớp (Layered Architecture) trên website Tvzoneplus.com. Hy vọng những thông tin mà chúng tôi đã chia sẻ là hữu ích với bạn. Nếu nội dung hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất. Chúc bạn một ngày tốt lành!