Mô hình 3 lớp (kiến trúc 3 lớp) - 3 layers architecture cần phân
biệt với mô hình 3 tầng - 3 tiers. 3 layers là mô hình logic, còn 3
tiers là mô hình vật lí. Trong nội dung bài này, khi nhắc đến 3 lớp tức
là 3 layers.
Có một bài viết rất hay trên codeproject nói về kiến trúc 3 layers. Các bạn tham khảo tại đây: Three Layer Architecture in C# .NET
Giới thiệu
Có lẽ mình nên bỏ qua phần giới thiệu, ưu điểm và khuyết điểm của mô hình 3 lớp vì nói dài, nói dai đâm ra nói dại thôi :))Kiến trúc
Presentation Layer (GUI)
Đây chính là giao diện xử lý của ứng dụng (Windows form, webform, ...). Nhiệm vụ chính của lớp này là nhập liệu và trình bày dữ liệu, có thể bao gồm kiểm tra dữ liệu đầu vào trước khi gọi Business Logic Layer.
Như ví dụ trên, trước khi nhấn button Add, ta phải nhập
dữ liệu Name, Address và Email. Ở Presentation Layer có thể kiểm tra các
dữ liệu nhập vào có hợp lệ hay không, có cho phép để trống không, email
đúng định dạng không...sau đó mới thực hiện việc thêm vào CSDL.
Business Logic Layer (BLL)
Đôi khi bạn thấy BLL, đôi khi là BUS, cái nào cũng là Business Logic Layer, muốn viết kiểu nào thì viết thôi.
Kiểm tra các yêu cầu nghiệp vụ trước khi cập nhật dữ
liệu, quản lý các transaction, quản lý các concurrent access...bla bla.
Nếu mới tìm hiểu có thể bạn sẽ thắc mắc ở lớp này, và khi code bạn càng
thắc mắc hơn. Công việc của BLL là gọi lại các xử lí của lớp Data Access
Layer, nếu gặp ngoại lệ cũng "quăng" cho GUI. Vậy nó có tầm quan trọng
như thế nào trong khi ta có thể gọi trực tiếp từ DAL?
Thứ nhất, đừng tự hỏi vì sao mặt trời mọc ở hướng đông. Khi người ta đưa ra mô hình 3 lớp thì cũng có lý do của họ :v
Thứ hai, theo đúng trình tự viết theo
mô hình 3 lớp, bạn sẽ viết từ lớp trên xuống lớp dưới. Tức là ở GUI cần
xử lý những gì thì bạn sẽ thêm xử lý đó cho BLL, và BLL yêu cầu lớp dưới
nó là DAL làm, sau đó kết quả cứ trả ngược lại cho lớp trên.
Cuối cùng, hãy tưởng tượng viễn cảnh
như thế này: Có 3 đối tượng đưa ra là khách hàng, giám đốc và đội ngũ kỹ
thuật. Khách hàng sẽ làm việc với giám đốc và yêu cầu làm một chương
trình Quản lý sinh viên. Ngày đầu tiên, khách hàng nói với giám đốc rằng
họ cần chức năng thêm sinh viên trong ứng dụng đó, giám đốc đồng ý cung
cấp chức năng đó cho khách hàng, và giám đốc yêu cầu đội ngũ kỹ thuật
làm điều đó. Ngày tiếp theo, khách hàng cần chức năng xóa 1 sinh viên,
giám đốc cũng đồng ý và tiếp tục yêu cầu đội ngũ kỹ thuật thêm chức năng
xóa 1 sinh viên cho khách hàng.
Có thể so sánh sự tương đồng như sau: Khách hàng = GUI,
Giám đốc = BLL và Đội ngũ kỹ thuật = DAL. GUI cần gì BLL sẽ cung cấp, và
BLL gọi DAL để xử lý yêu cầu đó.
Tiếp tục thế này, sau khi đội ngũ kỹ thuật thực hiện 2
yêu cầu thêm và xóa, họ "tự nghĩ" rằng có thể khách hàng sẽ cần thêm
chức năng cập nhật thông tin cho 1 sinh viên, và họ cũng "tự làm" thêm
chức năng cập nhật để dự phòng. Thế nhưng "đời không như là mơ", khách
hàng không cần chức năng đó, và đội ngũ kỹ thuật đã làm 1 việc vô ích.
Trường hợp này cũng giống như khi bạn code lớp DAL trước, rồi mới đưa
lên BLL vậy.
Data Access Layer (DAL)
Đôi khi bạn thấy là DAL, đôi khi là DAO, cái nào cũng là Data Access Layer cả. Tùy cách thể hiện thôi.
Chức năng của DAL là kết nối CSDL, tìm kiếm, thêm, xóa, sửa,… trên
CSDL/XML. Quá rõ ràng rồi, trong đó bạn có thể sử dụng ADO.NET, Entity
Framework để xử lý, và cũng không giới hạn cách thức lưu trữ (Sql,
Access, Xml...).Data Transfer Object (DTO) - anh là ai?
Như ví dụ ở trên, Khách hàng, giám đốc và đội ngũ kỹ thuật giao tiếp bằng cách nào. Nếu ở gần thì họ có thể gặp mặt, họp...nhưng nếu khách hàng ở Mĩ, và công ty ở VN thì sao? Đơn giản, họ có thể liên lạc bằng phone, sms, email, skype...Cũng như vậy, GUI, BLL và DAL trao đổi dữ liệu bằng DTO - đối tượng trao đổi dữ liệu.
Nên nhớ, DTO không phải là 1 lớp mà chỉ là đối tượng trao đổi dữ liệu giữa các lớp với nhau. Vậy DTO ... là gì?
Đơn giản thôi, DTO chính là các bảng có trong CSDL của bạn: