TÌM HIỂU MỘT SỐ MÔ HÌNH KIẾN TRÚC PHẦN MỀM VÀ ỨNG DỤNG XÂY DỰNG HỆ THỐNG QUẢN LÝ KÝ TÚC XÁ TRƯỜNG ĐẠI HỌC QUẢNG NAM - Full 10 điểm

TRƯỜNG ĐẠI HỌC QUẢNG NAM KHOA CÔNG NGHỆ THÔNG TIN ---------- KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC TÌM HIỂU MỘT SỐ MÔ HÌNH KIẾN TRÚC PHẦN MỀM VÀ ỨNG DỤNG XÂY DỰNG HỆ THỐNG QUẢN LÝ KÝ TÚC XÁ TRƯỜNG ĐẠI HỌC QUẢNG NAM Sinh viên thực hiện: Bùi Lê Quốc Nam MSSV: 2112011015 CHUYÊN NGÀNH: CÔNG NGHỆ THÔNG TIN KHÓA 2012 – 2016 Giảng viên hướng dẫn: ThS. ĐỖ QUANG KHÔI Quảng Nam, tháng 04 năm 2016 LỜI CẢM ƠN Trước hết tôi xin gửi lời cảm ơn sâu sắc đến ThS. Đỗ Quang Khôi, người đã trực tiếp hướng dẫn, giúp đỡ, định hướng và đóng góp ý kiến cho tôi trong suốt thời gian làm bài để tôi có thể hoàn thành Khóa luận tốt nghiệp này. Tôi xin chân thành cảm ơn tất cả thầy, cô giáo trường Đại học Quảng Nam. Đặc biệt là các thầy, cô trong Khoa Công nghệ thông tin của trường đã tận tình dạy dỗ và truyền đạt kiến thức cho tôi trong suốt quá trình học tập và nghiên cứu tại trường, tạo điều kiện thuận lợi cho tôi trong thời gian cuối khóa để hoàn thành chương trình tốt nghiệp. Tôi cũng gởi lời cảm ơn đến Trung tâm học liệu và Công nghệ thông tin – Trường Đại học Quảng Nam đã tạo môi trường, điều kiện giúp đỡ cho tôi trong suốt quá trình thực tập tốt nghiệp và những kinh nghiệm trong thực tế. Đồng thời, tôi cũng gởi lời cảm ơn đến gia đình, bạn bè đã động viên, giúp đỡ tôi lúc khó khăn trong học tập và trong cuộc sống. -i- MỤC LỤC DANH MỤC TỪ VIẾT TẮT.............................................................................. iv DANH MỤC HÌNH VẼ ....................................................................................... v Phần 1. MỞ ĐẦU ................................................................................................. 1 1.1. Lý do chọn đề tài ..................................................................................... 1 1.2. Mục đích nghiên cứu ............................................................................... 2 1.3. Đối tượng và phạm vi nghiên cứu ........................................................... 2 1.4. Phương pháp nghiên cứu ......................................................................... 2 1.5. Lịch sử nghiên cứu .................................................................................. 2 1.6. Đóng góp của đề tài ................................................................................. 2 1.7. Cấu trúc của khóa luận ............................................................................ 3 Phần 2. NỘI DUNG NGHIÊN CỨU .................................................................. 4 Chương 1: TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM .......................... 4 1.1. Khái niệm kiến trúc phần mềm ................................................................ 4 1.1.1. Khái niệm .......................................................................................... 4 1.1.2. Lịch sử kiến trúc phần mềm .............................................................. 5 1.1.3. Tầm quan trọng của kiến trúc phần mềm ......................................... 6 1.2. Phân loại mô hình kiến trúc ..................................................................... 7 1.2.1. Mô hình đơn lập ................................................................................ 7 1.2.2. Mô hình phân tán .............................................................................. 7 1.2.2.1. Đặc điểm..................................................................................... 7 1.2.2.2. Đặc tính ...................................................................................... 8 1.2.2.3. Một số mô hình phân tán ............................................................ 8 1.3. Xử lý dữ liệu với ADO.NET ................................................................. 11 1.3.1. Tính năng của ADO.NET ................................................................ 11 1.3.2. Kiến trúc tổng quan của ADO.NET ................................................ 12 1.3.3. Tổng quan về các mô hình xử lý dữ liệu trong ADO.NET .............. 13 1.3.3.1. Mô hình kết nối ........................................................................ 13 1.3.3.2. Mô hình ngắt kết nối ................................................................ 14 1.3.4. Lựa chọn giữa mô hình Kết nối và mô hình Ngắt kết nối ............... 15 -ii- 1.4. Kết luận chương 1.................................................................................. 16 Chương 2: MỘT SỐ MÔ HÌNH KIẾN TRÚC PHẦN MỀM .................... 17 2.1. Mô hình MVC........................................................................................ 17 2.1.1. Kiến trúc mô hình MVC .................................................................. 17 2.1.2. Đặc điểm mô hình MVC .................................................................. 17 2.1.3. Các thành phần của ASP.NET MVC............................................... 18 2.1.4. Lợi ích của mô hình MVC ............................................................... 19 2.2. Mô hình MVVM .................................................................................... 19 2.3. Mô hình đa tầng (n-Tier) ....................................................................... 20 2.3.1. Khái niệm ........................................................................................ 21 2.3.2. Các thành phần của mô hình 3 tầng ............................................... 21 2.3.3. Tính chất của 3-Tier........................................................................ 22 2.3.4. Ưu, nhược điểm của 3-tier .............................................................. 24 2.4. Mô hình 3-Layer .................................................................................... 24 2.4.1. Khái niệm ........................................................................................ 24 2.4.2. Các thành phần của 3-Layer........................................................... 25 2.4.3. Ưu điểm khi sử dụng mô hình 3-Layer ........................................... 27 2.5. So sánh các mô hình kiến trúc phần mềm ............................................. 28 2.5.1. So sánh mô hình 3-Tier và mô hình MVC ....................................... 28 2.5.2. So sánh 3-tier và 3-layer ................................................................. 29 2.6. Kết luận chương 2.................................................................................. 31 Chương 3: XÂY DỰNG HỆ THỐNG QUẢN LÝ KÝ TÚC XÁ TRƯỜNG ĐẠI HỌC QUẢNG NAM .............................................................................. 32 3.1. Khảo sát hệ thống .................................................................................. 32 3.1.1. Tổng quan về tổ chức ...................................................................... 32 3.1.1.1. Mô tả khái quát về tổ chức ....................................................... 32 3.1.1.2. Mục tiêu tổ chức ....................................................................... 33 3.1.1.3. Cơ cấu tổ chức .......................................................................... 33 3.1.2. Các quy trình hoạt động nghiệp vụ ................................................. 34 3.2. Phân tích và thiết kế hệ thống ................................................................ 41 3.2.1. Các yêu cầu của hệ thống mới ........................................................ 41 3.2.1.1. Mục tiêu của hệ thống .............................................................. 41 -iii- 3.2.1.2. Yêu cầu phi chức năng ............................................................. 41 3.2.1.3. Yêu cầu chức năng ................................................................... 41 3.2.2. Phân tích hệ thống .......................................................................... 42 3.2.2.1. Các tác nhân của hệ thống ........................................................ 42 3.2.2.2. Ca sử dụng của hệ thống .......................................................... 42 3.2.2.3. Biểu đồ ca sử dụng (Use Case) của hệ thống ........................... 43 3.2.2.4. Đặc tả ca sử dụng ..................................................................... 44 3.2.3. Mô hình cấu trúc của Hệ thống ...................................................... 50 3.2.3.1. Xác định các lớp thực thể ......................................................... 50 3.2.3.2. Xác định các lớp biên ............................................................... 51 3.2.3.3. Xác đinh các lớp điều khiển ..................................................... 53 3.2.4. Mô hình hành vi của Hệ thống ........................................................ 53 3.2.4.1. Mô hình tuần tự ........................................................................ 53 3.2.4.2. Biểu đồ hoạt động .................................................................... 58 3.2.5. Thiết kế ............................................................................................ 59 3.2.5.1. Cơ sở dữ liệu của hệ thống ....................................................... 59 3.2.5.2. Biều đồ định hướng giao diện người dùng ............................... 67 3.2.6. Cài đặt hệ thống .............................................................................. 69 3.3. Cài đặt kiến trúc chương trình theo mô hình 1- tier, 3 layer ................. 69 3.4. Một số giao diện chính của chương trình .............................................. 72 3.5. Kết luận chương 3.................................................................................. 74 Phần 3. KẾT LUẬN ........................................................................................... 75 Phần 4. TÀI LIỆU THAM KHẢO ................................................................... 76 -iv- DANH MỤC TỪ VIẾT TẮT Tên viết tắt Tên đầy đủ KTX Kí túc xá KTPM Kiến trúc phần mềm GUI Graphic User Interface BLL Business Logic Layer DAL Data Access Layer DTO Data Tranfer Object MVC Model-View-Controler MVVM Model-View-ViewModel TTHTSV Trung tâm hỗ trợ sinh viên UC Use case -v- DANH MỤC HÌNH VẼ Hình 1.1. Mô hình Client – Server ......................................................................... 8 Hình 1.2. Mô hình 3-Tier ....................................................................................... 9 Hình 1.3. Mô hình Peer-To-Peer với kiến trúc không tập trung .......................... 10 Hình 1.4. Mô hình Peer-To-Peer với kiến trúc bán tập trung .............................. 11 Hình 1.5. Kiến trúc tổng quan của ADO.NET ..................................................... 12 Hình 1.6. Mô hình kết nối .................................................................................... 13 Hình 1.7. Mô hình ngắt kết nối ............................................................................ 14 Hình 2.1. Mô hình MVC trong ASP.NET ........................................................... 17 Hình 2.2. Các thành phần của MVC .................................................................... 18 Hình 2.3. Các thành phần của mô hình MVVM .................................................. 19 Hình 2.4. Các tầng trong mô hình 3-tier và nhiệm vụ của nó .............................. 22 Hình 2.5. Mô hình 3-Tier giảm sự gắn kết giữa các thực thể .............................. 23 Hình 2.6. Mô hình 3-Tier giúp dễ dàng tái sử dụng phần mềm ........................... 23 Hình 2.7. Mô hình 3-Tier giúp dễ dàng chia sẻ trách nhiệm ............................... 23 Hình 2.8. Các thành phần của mô hình 3-Layer .................................................. 25 Hình 2.9. Quá trình xử lý của kiến trúc 3 tầng..................................................... 28 Hình 2.10. Quá trình xử lý của mô hình MVC .................................................... 29 Hình 2.11. Mô hình 3-Tier mang tính vật lý ........................................................ 30 Hình 2.12. Mô hình 3-Layer mang tính logic ...................................................... 30 Hình 3.1. Cơ cấu tổ chức của Trung tâm hỗ trợ sinh viên ................................... 32 Hình 3.3. Kiến trúc của chương trình demo theo mô hình 1-Tier, 3-Layer ......... 71 Hình 3.4. Giao diện Đăng nhập của chương trình ............................................... 72 Hình 3.5. Giao diện chính của chương trình ........................................................ 72 Hình 3.6. Cửa sổ nhập thông tin SV mới ............................................................. 73 Hình 3.7. Cửa sổ chuyển sinh viên qua phòng khác ............................................ 73 Hình 3.8. Cửa sổ tính phí điện nước từng phòng ................................................. 74 -1- Phần 1. MỞ ĐẦU 1.1. Lý do chọn đề tài Kiến trúc phần mềm là một chuyên ngành bắt đầu từ những năm 70 của thế kỷ trước. Với việc gia tăng độ phức tạp và áp lực về việc phát triển các hệ thống thời gian thực phức tạp, kiến trúc phần mềm (KTPM) nổi lên như là một kiến trúc cơ sở của việc phát triển phần mềm và công nghệ hệ thống chủ lực. Như bất kỳ lĩnh vực nghiên cứu nào khác, KTPM cũng có những thách thức ban đầu của nó. Một KTPM thể hiện các phương diện cấu trúc và hành vi của một hệ thống. Các nhà phát triển phần mềm rất coi trọng KTPM vì nó quyết định mối quan hệ giữa các thành phần trong phần mềm, phát triển module, tái sử dụng sau này. Ban đầu với những chương trình đơn giản, KTPM được thiết kế đơn giản với việc thiết kế thuật toán, cấu trúc dữ liệu... dần dần khi những phần mềm lớn ra đời, việc điều phối, quản lý con người, quản lý thành phần phần mềm, quản lý tiến trình phát triển dự án... đã hình thành những KTPM và những mẫu phần mềm. Trong phát triển ứng dụng hiện nay, để dễ quản lý các thành phần của hệ thống, cũng như không bị ảnh hưởng bởi các thay đổi, người ta hay nhóm các thành phần có cùng chức năng lại với nhau và phân chia trách nhiệm cho từng nhóm để công việc không bị chồng chéo và ảnh hưởng lẫn nhau. Điều này có nghĩa là ứng dụng được phát triển theo kiểu phân tán, các thành phần của hệ thống đảm nhận những vai trò, nhiệm vụ khác nhau. KTX của nhà trường hiện đang quản lý theo cách truyền thống. Việc đăng ký và quản lý thủ công gây nên nhiều khó khăn, tốn thời gian và gây lãng phí cả về công sức và tiền bạc. Chính vì những lí do trên nên tôi đã chọn đề tài “ Tìm hiểu một số mô hình kiến trúc phần mềm và ứng dụng xây dựng hệ thống Quản lý ký túc xá Trường Đại học Quảng Nam” làm Khóa luận tốt nghiệp. -2- 1.2. Mục đích nghiên cứu - Nắm vững những kiến thức cơ bản về KTPM, mô hình MVC và đặc biệt là kiến trúc 3 lớp. - Áp dụng kiến trúc 3 lớp vào việc Xây dựng hệ thống Quản lý ký túc xá trường Đại học Quảng Nam 1.3. Đối tượng và phạm vi nghiên cứu - Kiến thức cơ bản và kiến trúc phần mềm - Kiến thức về MVC và kiến trúc đa tầng. - Ứng dụng mô hình kiến trúc 1-tier, 3-layers vào xây dựng 1 hệ thống. 1.4. Phương pháp nghiên cứu - Nghiên cứu tài liệu, giáo trình, luận văn, bài báo, thông tin trên mạng. - Phân tích, tổng hợp tài liệu. - Thống kê, phân tích dữ liệu. 1.5. Lịch sử nghiên cứu Kiến trúc phần mềm đã được một số tác giả tìm hiểu và nghiên cứu trước đó. Phần lớn các tác giả đều cho thấy một cách tổng quan về nội dung lý thuyết của KTPM và kiến trúc 3 lớp đồng thời cũng xây dựng một hệ thống phù hợp với môi trường và bản thân tác giả. Với những ưu điểm của mình thì lập trình 3 lớp đã được sử dụng trong nhiều hệ thống lớn tuy nhiên nó còn khá mới mẻ đối với sinh viên trường Đại học Quảng Nam. 1.6. Đóng góp của đề tài Đề tài được nghiên cứu nhằm trình bày tổng quan về các KTPM. Trình bày những kiến thức cơ bản và tổng quan về KTPM và một số mô hình KTPM tiêu biểu nhất. Xây dựng chương trình ứng dụng trong việc quản lý kí túc xá trường Đại học Quảng Nam -3- 1.7. Cấu trúc của khóa luận Lời cảm ơn Mục lục Danh mục các ký hiệu, các chữ viết tắt Danh mục các bảng Danh mục các hình vẽ, đồ thị MỞ ĐẦU 1. Lý do chọn đề tài 2. Mục đích nghiên cứu 3. Đối tượng và phạm vi nghiên cứu 4. Phương pháp nghiên cứu 5. Lịch sử nghiên cứu 6. Đóng góp của đề tài NỘI DUNG Chương 1: Tổng quan về kiến trúc phần mề m Chương 2: Một số mô hình kiến trúc phần mề m Chương 3: Xây dựng hệ thống quản lý ký túc xá trường Đại họ c Quảng Nam KẾT LUẬN TÀI LIỆU THAM KHẢO PHỤ LỤC -4- Phần 2. NỘI DUNG NGHIÊN CỨU Chương 1: TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM 1.1. Khái niệm kiến trúc phần mềm 1.1.1. Khái niệm Nhiều nhà nghiên cứu đã giải thích về kiến trúc phần mềm, và họ có các quan điểm khác nhau về cách trình bày tốt nhất về kiến trúc của hệ thống phần mềm. Không có cách giải thích nào là sai; mỗi kiến trúc có giá trị riêng. Định nghĩa của Bass L, và cộng sự nắm giữ được điểm cốt yếu của cái mà kiến trúc phần mềm đòi hỏi: “Kiến trúc phần mềm của một chương trình hoặc hệ thố ng tính toán là cấu trúc hoặc các cấu trúc của hệ thống đó, gồm các thành phần củ a phần mềm, các thuộc tính có thể trông thấy được từ bên ngoài củ a các thành phần này, và các mối quan hệ giữa chúng” . Định nghĩa này tập trung vào kiến trúc đã tạo nên các bản dựng thô (coarse- grained constructs) (tức các thành phần của phần mềm) mà có thể được coi là các bộ phận cơ bản của kiến trúc/các khối xây dựng nên kiến trúc (building blocks of the architecture). Mỗi thành phần của phần mềm, hay bộ phận kiến trúc cơ bản, có một số nhất định các thuộc tính có thể nhìn thấy từ bên ngoài mà nó thông báo đến các bộ phận kiến trúc cơ bản còn lại. Các chi tiết bên trong của sự thiết kế và cài đặt thành phần phần mềm không liên quan đến phần còn lại của hệ thống, xem xét một phần mềm đặc biệt chỉ như một hộp đen. Hộp đen này có các thuộc tính nhất định mà nó biểu lộ, cái mà các thành phần phần mềm còn lại có thể sử dụng để thực hiện chung các đích nghiệp vụ hoặc công nghệ thông tin. Kiến trúc phần mềm xác định các khối kiến trúc cơ bản, với một mức độ chi tiết thích hợp. Nó cũng xác định và viết tư liệu việc các bộ phận cơ bản liên quan lẫn nhau như thế nào. Kiến trúc khi nó liên quan đến công nghệ phần mềm là việc phân tích hoặc phân vùng một hệ thống đơn lẻ sang một tập các bộ phận mà có thể được xây -5- dựng theo kiểu lặp lại, gia tăng, và độc lập. Các bộ phận riêng lẻ có các mối quan hệ hiện với nhau. Khi đan xen vào nhau, các bộ phận riêng lẻ đó tạo nên kiến trúc của hệ thống, tổ chức, hoặc ứng dụng. Ngoài ra, thuật ngữ “kiến trúc phần mềm” cũng đề cập đến các tài liệu kiến trúc phần mềm của một hệ thống, thuận tiện cho việc trao đổi thông tin giữa các thành viên trong một dự án. KTPM giúp việc quyết định ở mức cao trong thiết kế phần mềm dễ dàng hơn và cho phép tái sử dụng các thành phần và mẫu thiết kế của các dự án. Lĩnh vực khoa học máy tính trải qua sự kết hợp các vấn đề cùng với sự phức tạp của cấu trúc. Lúc đầu, sự phức tạp được giải quyết bởi người phát triển bằng cách lựa chọn các cấu trúc dữ liệu đúng đắn, phát triển các thuật toán và áp dụng các thuật toán để chia nhỏ các vấn đề. Khái niệm “Kiến trúc phần mềm” tập trung vào việc giảm tải các phức tạp bằng cách trừu tượng hóa vấn đề và phân chia rõ trách nhiệm công việc. Tuy vậy, đến ngày nay vẫn chưa có một khái niệm thật chính xác và rõ ràng cho thuật ngữ “Kiến trúc phần mềm”. Như vậy mặc dù khái niệm “Kiến trúc phần mềm” đã xuất hiện trong các giảng đường đại học và được đưa vào sử dụng trong ngành công nghệ phần mềm, nhưng việc nó vẫn chưa có các quy tắc, luật lệ chung và chưa rõ ràng nên thiết kế KTPM vẫn là một sự pha tạp giữa “khoa học” và “nghệ thuật”. Vẻ “nghệ thuật” của kiến trúc phần mềm được lý giải là do có sự xuất hiện của các yêu cầu phi chức năng của hệ thống mà phần mềm phải đáp ứng được các yêu cầu này, chẳng hạn như các yêu cầu về các thuộc tính chất lượng. Ngoài ra, phần mềm còn phải thỏa mãn các yêu cầu khác như: khả năng chịu lỗi, tính tương thích với các phiên bản cũ của các phần mềm khác (backward compatibility), khả năng mở rộng, tính tin cậy, khả năng bảo trì, tính hiện hữu, tính bảo mật, tính dễ dùng, và một số các yêu cầu khác nữa. 1.1.2. Lịch sử kiến trúc phần mềm Nguồn gốc của kiến trúc phần mềm như một ý tưởng được giới thiệu đầu tiên trong nghiên cứu của Edsger Dijkstra năm 1968 và David Parnas đầu những -6- năm 1970. Các nhà khoa học nhấn mạnh rằng cấu trúc của một hệ thống phần mềm rất quan trọng và đạt được cấu trúc đúng đắn là một yếu tố quyết định. Các nghiên cứu về lĩnh vực này ngày càng nhiều và trở nên phổ biến từ đầu những năm 1990 cùng với các nghiên cứu tập trung vào các mẫu thiết kế (pattern), ngôn ngữ đặc tả kiến trúc (Architecture Description Languages), tài liệu kiến trúc và các phương pháp chính thức. Các viện nghiên cứu đóng vai trò quan trọng trong nghiên cứu môn học KTPM. Mary Shaw và David Garlan của viện nghiên cứu Carnegie Mellon đã viết cuốn sách “Software Architecture: Perspectives on an Emerging Discipline” vào năm 1996, mang đến các khái niệm tiến bộ trong KTPM như thành phần, kết nối (connector), kiểu (style) và nhiều thứ nữa. Trường đại học tổng hợp California, viện nghiên cứu phần mềm Irvine cũng có nhiều nỗ lực trong nghiên cứu KTPM, chủ yếu hướng vào các kiểu kiến trúc, ngôn ngữ đặc tả kiến trúc và các kiến trúc động. Một trong những chuẩn đầu tiên trong KTPM là chuẩn ANSI/IEEE 1471-2000 được ISO chấp nhận như ISO/IEC DIS 25961. 1.1.3. Tầm quan trọng của kiến trúc phần mềm Có 3 lý do chính để giải thích tầm quan trọng của KTPM:  Hỗ trợ giao tiếp Hỗ trợ việc giao tiếp với các thành viên trong dự án. KTPM tái hiện một vẻ bề ngoài trừu tượng của hệ thống. Với sự trừu tượng hóa hệ thống với các khái niệm dễ hiểu, những thành viên trong dự án sẽ chỉ cần vận dụng các kiến thức cơ bản của mình về hệ thống trong việc tìm hiểu, dàn xếp, phối hợp làm việc, và bàn bạc trao đổi với nhau.  Giúp ra quyết định sớm hơn Việc ra quyết định được thực hiện sớm hơn. KTPM biểu thị các quyết định thiết kế dành cho hệ thống. Như vậy các đội tham gia phát triển, triển khai, kiểm thử và bảo trì phần mềm cũng như các nhóm người dùng và các cấp quản lý sẽ có cái nhìn tổng quan hơn cũng như sớm hơn về hệ thống ngay từ khi nó còn sơ khai. Mỗi đội đó sẽ có các đóng góp ý kiến của mình, các đề xuất cũng như các -7- phản bác của mình khi mọi chuyện chưa quá muộn. Nếu không có quyết định sớm, thì khi phần mềm đã được xây dựng hoàn chỉnh hoặc khá hoàn chỉnh mà đột ngột xuất hiện các yêu cầu thay đổi từ phía nhóm này hoặc nhóm khác, ngoài việc gây trì trệ cho tiến độ công việc mà còn có thể gây ra tâm lý căng thẳng, mâu thuẫn giữa các đội tham gia trong dự án.  Tính khả chuyển cho hệ thống KTPM không phụ thuộc vào một ngôn ngữ cụ thể nào cả mà chỉ tuân theo một số chuẩn của các ngôn ngữ đặc tả nó. Ngoài ra, KTPM khi được xây dựng cho một hệ thống, nó tạo thành một mô hình có sự gắn kết tương đối với hệ thống. KTPM còn chỉ ra cách thức mà phần mềm làm việc với hệ thống. Do vậy, khi ta muốn chuyển phần mềm sang làm việc ở các hệ thống khác có những điểm tương đồng nhất định với hệ thống cũ thì phần mềm này cũng sẽ có các thuộc tính chất lượng và các yêu cầu chức năng được đảm bảo là không quá khác so với khi tồn tại ở hệ thống cũ. 1.2. Phân loại mô hình kiến trúc 1.2.1. Mô hình đơn lập Là một thể thống nhất, không có sự phân nhóm và các thành phần trong mô hình đơn lập thì tự do tương tác.  Ưu điểm: + Dễ lập trình và triển khai. + Tốc độ xử lý cao.  Nhược điểm: + Khó bảo trì, nâng cấp. + Không chia sẻ dữ liệu. 1.2.2. Mô hình phân tán 1.2.2.1. Đặc điểm - Chia sẻ tài nguyên: chia sẻ tài nguyên phần cứng và phần mềm. - Tính mở: Cho phép sử dụng phần mềm và thiết bị của các nhà cung cấp khác nhau. -8- - Xử lý đồng thời: Nâng cao hiệu năng của hệ thống. - Tính mềm dẻo: Cho phép thêm mới tài nguyên một cách dễ dàng. - Khả năng chịu lỗi: Cho phép hệ thống tiếp tục vận hành khi lỗi phát sinh. 1.2.2.2. Đặc tính - Tính phức tạp: hệ thống phân tán phức tạp hơn hệ thống tập trung. - Tính an toàn: Dễ bị tấn công từ bên ngoài. - Tính quản lý được: Cần nhiều công sức hơn để quản lý hệ thống. - Không thể dự đoán trước: Khả năng đáp ứng không được dự đoán trước do phụ thuộc vào phương thức tổ chức hệ thống và khả năng chịu tải của hệ thống mạng. 1.2.2.3. Một số mô hình phân tán  Mô hình Client – Server: - Là mô hình tổ chức trong đó các dịch vụ được cung cấp bởi server (chương trình chủ) và client (chương trình khách) sử dụng các dịch vụ đó (máy tính trên đó cài đặt chương trình chủ gọi là máy chủ). - Client gửi yêu cầu (request) tới server, server tiếp nhận, xử lý vả trả về kết quả cho client. - Client biết server nhưng server không cần biết client. - Để client-server giao tiếp được với nhau cần tuân theo chuẩn, gọi là giao thức. - Một server có thể nối tới nhiều server khác để tăng hiệu quả xử lý. - Client và server là các tiến trình logic. Hình 1.1. Mô hình Client – Server -9-  Ưu điểm: + Dữ liệu chia sẻ và đồng bộ. + Hạn chế tương tác. + Dễ bảo trì, nâng cấp, cô lập lỗi.  Nhược điểm: + Chi phí triển khai. + Tốc độ xử lí.  Mô hình 3 – Tiers: Được phân thành 3 tầng: * Tầng giao diện (Presentation tier): Các thực thể phần mềm làm nhiệm vụ nhập liệu, trình bày, hiển thị, có thể bao gồm bước kiểm tra dữ liệu trước khi gọi Business Logic Tier và tương tác với người sử dụng. * Tầng xử lý (Business tier): Các thực thể phần mềm thực hiện các chức năng nghiệp vụ, chứa các xử lý chính và quản lý các transaction. * Tầng dữ liệu (Data tier): các thực thể phần mềm làm nhiệm vụ lưu trữ dữ liệu, tương tác với cơ sở dữ liệu (thêm, xóa, sửa, chọn). Hình 1.2. Mô hình 3-Tier -10-  Ưu điểm: + Tương tự mô hình Client–Server. + Xử lý chia sẻ và được chia nhỏ.  Khuyết điểm: + Tương tự mô hình Client-Server. Trong Chương 2 của Khóa luận sẽ trình bày cụ thể hơn về mô hình này.  Mô hình Peer - To - Peer (mô hình ngang hàng): - Là mô hình không tập trung, trong đó việc tính toán có thể được thực hiện ở bất cứ nút nào trên mạng. - Triển khai trên nhiều máy (node). - Các node tương tác được với nhau. - Mỗi node đóng vai trò Client – Server. - Chia sẻ dữ liệu và xử lý trên toàn bộ node. - Ngoài mô hình Peer-To-Peer có kiến trúc không tập trung truyền thống còn có mô hình kiến trúc bán tập trung. Hình 1.3. Mô hình Peer-To-Peer với kiến trúc không tập trung -11- Hình 1.4. Mô hình Peer-To-Peer với kiến trúc bán tập trung  Ưu điểm: + Không cần Server trung tâm. + Không gian lưu trữ và khả năng xử lý dàn trải + Dễ triển khai.  Nhược điểm: + Khó lập trình và quản lý dữ liệu. 1.3. Xử lý dữ liệu với ADO.NET Xử lý dữ liệu là nhiệm vụ phổ biến và quan trọng của nhiều chương trình ứng dụng. Dữ liệu được truy xuất, xử lý của một chương trình ứng dụng có thể là một tập tin văn bản, tập tin các bản ghi, hay là một nguồn dữ liệu từ CSDL nào đó. ADO.NET là một tập các lớp nằm trong bộ thư viện lớp cơ sở của .NET Framework, cho phép các ứng dụng windows (như C#, VB.NET) hay ứng dụng Web (như ASP.NET) thao tác dễ dàng với các nguồn dữ liệu. 1.3.1. Tính năng của ADO.NET * Hỗ trợ lập trình: Cung cấp các lớp thao tác với CSDL giúp lập trình viên lập trình nhanh hơn và giảm bớt lỗi. -12- Cung cấp các công cụ để thao tác với CSDL ngay trên phần Designer giúp lập trình viên tương tác với CSDL mà không cần hiểu sâu về CSDL. * Khả năng mở rộng: Sử dụng kiến trúc không kết nối chỉ kết nối với dữ liệu khi cần thiết nên giảm tải cho server CSDL -> Ứng dụng có thể đáp ứng nhiều người dùng hơn. * Khả năng tích hợp: ADO.NET có thể gửi dữ liệu cho bất cứ ứng dụng nào hỗ trợ XML. 1.3.2. Kiến trúc tổng quan của ADO.NET ADO.NET được chia ra làm hai phần chính rõ rệt, được thể hiện qua hình 1.5: Hình 1.5. Kiến trúc tổng quan của ADO.NET DataSet là thành phần chính cho đặc trưng kết nối không liên tục của kiến trúc ADO.NET. DataSet được thiết kế để có thể thích ứng với bất kỳ nguồn dữ liệu nào. DataSet chứa một hay nhiều đối tượng DataTable mà nó được tạo từ tập các dòng và cột dữ liệu, cùng với khoá chính, khóa ngoại, ràng buộc và các thông tin liên quan đến đối tượng DataTable này. Bản thân DataSet được dạng như một tập tin XML. Thành phần chính thứ hai của ADO.NET chính là NET Provider Data, nó chứa các đối tượng phục vụ cho việc thao tác trên cơ sở dữ liệu được hiệu quả và nhanh chóng, nó bao gồm một tập các đối tượng Connection, Command, -13- DataReader và DataAdapter. Đối tượng Connection cung cấp một kết nối đến cơ sở dữ liệu, Command cung cấp một thao tác đến cơ sở dữ liệu, DataReader cho phép chỉ đọc dữ liệu và DataAdapter là cầu nối trung gian giữa DataSet và nguồn dữ liệu. 1.3.3. Tổng quan về các mô hình xử lý dữ liệu trong ADO.NET 1.3.3.1. Mô hình kết nối Trong mô hình kết nối của ADO.NET, có một connection hoạt động được duy trì giữa đối tượng DataReader của ứng dụng và một data source (nguồn dữ liệu). Một dòng dữ liệu (datarow) được trả về từ data source mỗi khi phương thức Read của đối tượng DataReader được thực thi. Điểm quan trọng nhất của mô hình kết nối đó là dữ liệu được lấy từ tập dữ liệu (các record được trả về bởi một lệnh SQL nào đó) theo kiểu từng record một cho một lần đọc, chỉ đọc, và chỉ theo một hướng tiến… Hình dưới đây mô tả cách sử dụng DataReader trong chế dộ kết nối. Hình 1.6. Mô hình kết nối  Các bước điển hình để làm việc với đối tượng DataReader là như sau: 1. Tạo đối tượng Connection bằng cách truyền một chuỗi Connection string cho hàm khởi dựng của nó. 2. Khởi tạo một biến chuỗi và gán câu lệnh SQL dựa theo dữ liệu muốn nạp về. 3. Khởi tạo một đối tượng Command với nội dung câu lệnh SQL đã được xác định ở trên. -14- 4. Tạo đối tượng DataReader bằng cách thực thi phương thức Command.ExecuteReader. Đối tượng này sau đó sẽ được dùng để đọc kết quả của câu truy vấn mỗi dòng 1 lần. Một số đối tượng khi làm việc với mô hình kết nối như: lớp conection command, DataReader. 1.3.3.2. Mô hình ngắt kết nối Triết lý của mô hình ngắt kết nối đó là: Dữ liệu được nạp - sử dụng một lệnh SQL – từ nguồn dữ liệu bên ngoài vào bộ nhớ đệm tại máy client; tập kết quả được xử lý tại máy cục bộ, mọi cập nhật sau đó sẽ được truyền từ dữ liệu trong bộ nhớ ngược trở lại nguồn dữ liệu. Mô hình được gọi là “ngắt kết nối” bởi vì đối tượng kết nối chỉ được mở đủ lâu để đọc dữ liệu từ nguồn dữ liệu và tiến hành các thao tác cập nhật. Bằng cách đưa dữ liệu Connection, bộ nhớ, thời gian xử lý sẽ được giải phóng bớt. Tuy vậy, mô hình này cũng có nhược điểm về thời gian cần để nạp tập dữ liệu và bộ nhớ dùng để chứa dữ liệu tại máy client. Như hình dưới đây minh họa, các thành phần chính của mô hình ngắt kết nối đó là DataAdapter và DataSet. DataAdapter làm nhiệm vụ như là cầu nối giữa nguồn dữ liệu và DataSet, nạp dữ liệu vào các bảng của DataSet và đẩy các thay đổi ngược trở lại nguồn dữ liệu. Một DataSet đóng vai trò như là một cơ sở dữ liệu quan hệ nằm trong bộ nhớ, chứa một hay nhiều DataTable, giữa các DataTable này cũng có thể có các mối quan hệ với nhau như trong một cơ sở dữ liệu quan hệ thực. Một DataTable chứa các dòng và các cột dữ liệu thường được lấy từ cơ sở dữ liệu nguồn. Hình 1.7. Mô hình ngắt kết nối -15- Trong số các phương thức và thuộc tính của DataAdaper thì Fill() và Update() là hai phương thức quan trọng nhất. Fill() chuyển một query đến cơ sở dữ liệu và lưu tập kết quả trả về trong một DataTable nào đó; phương thức Update() thực hiện một thao tác thêm, xóa, cập nhật dựa trên những thay đổi của đối tượng DataSet. Các lệnh cập nhật thực sự được chứa trong các thuộc tính của DataAdapter. Đối tượng khi làm việc với mô hình ngắt kết nối: lớp DataSet. 1.3.4. Lựa chọn giữa mô hình Kết nối và mô hình Ngắt kết nối DataReader và DataSet đưa ra 2 cách tiếp cận khác nhau về xử lý dữ liệu. DataReader cho phép truy xuất kiểu forward-only, read-only. Bằng cách xử lý từng dòng một, cách tiếp cận này giúp tiết kiệm bộ nhớ. DataSet, ngược lại cho phép truy xuất theo kiểu read/write, nhưng lại yêu cầu phải có đủ bộ nhớ để quản lý bản sao dữ liệu nạp về data source. Như vậy, bạn có thể suy ra một số quy tắc chung: Nếu ứng dụng không cần tính năng cập nhật dữ liệu và hầu như chỉ hiển thị và chọn lọc dữ liệu, DataReader là lựa chọn thích hợp, nếu ứng dụng cần cập nhật dữ liệu, giải pháp được sử dụng DataSet nên được xem xét. Tất nhiên cũng có một số tình huống đi ngược lại với quy tắc chung nói trên. Chẳng hạn, nếu data source chứa một số lượng lớn các record, khi đó DataSet phải yêu cầu quá nhiều tài nguyên bộ nhớ, hoặc nếu dữ liệu chỉ yêu cầu một vài thao tác cập nhật, thì sự kết hợp giữa DataReader và Command để thực thi cập nhật sẽ có thể có ý nghĩa hơn. Tóm lại, một DataSet là một lựa chọn tốt khi:  Dữ liệu cần được serialize (tuần tự hóa) và/hoặc gửi đi bằng HTTP.  Các điều khiển read-only trên Form/WinForm được kết buộc (bind) với data source.  Một điều khiển WinForm như GridView hay DataView được kết buộc với một data source có khả năng cập nhật được.  Một ứng dụng Desktop cần thêm, xóa, sửa dòng dữ liệu. -16- Trong khi đó, DataReader là lựa chọn cho những trường hợp:  Cần quản lý một số lượng lớn các record, lớn đến mức mà bộ nhớ và thời gian để nạp dữ liệu cho DataSet là phi thực tế.  Dữ liệu là read-only và được kết buộc với một điều khiển loại danh sách (list control) của WinForm hoặc WebForm.  CSDL là không ổn định và thay đổi thường xuyên. 1.4. Kết luận chương 1 Chương 1 đã trình bày những kiến thức cơ bản và tổng quan nhất về KTPM cũng như việc xử lý dữ liệu với ADO.NET. Qua đó cũng cho thấy được việc xây dựng KTPM và xử lý dữ liệu là một vấn đề quan trọng trong quá trình xây dựng hệ thống phần mềm, đặc biệt là những phần mềm lớn. Trong KTPM có nhiều mô hình kiến trúc khác nhau, mỗi loại đều có những ưu và nhược điểm riêng của nó. Chương 2 sẽ giới thiệu một số mô hình kiến trúc phổ biến đang được sử dụng trong việc xây dựng các ứng dụng thông dụng hiện nay. -17- Chương 2: MỘT SỐ MÔ HÌNH KIẾN TRÚC PHẦN MỀM 2.1. Mô hình MVC 2.1.1. Kiến trúc mô hình MVC Trong kiến trúc MVC, một đối tượng đồ họa người dùng (GUI Component) bao gồm 3 thành phần cơ bản: Model, View, và Controller. Model có trách nhiệm đối với toàn bộ dữ liệu cũng như trạng thái của đối tượng đồ họa. View chính là thể hiện trực quan của Model, hay nói cách khác chính là giao diện của đối tượng đồ họa. Và Controller điều khiển việc tương tác giữa đối tượng đồ họa với người sử dụng cũng như những đối tượng khác. Hình 2.1. Mô hình MVC trong ASP.NET 2.1.2. Đặc điểm mô hình MVC Lợi ích quan trọng nhất của mô hình MVC là nó giúp cho ứng dụng dễ bảo trì, module hóa các chức năng, và được xây dựng nhanh chóng. MVC tách các tác vụ của ứng dụng thành các phần riêng lẽ model, view, controller giúp cho việc xây dựng ứng dụng nhẹ nhàng hơn. Dễ dàng thêm các tính năng mới, và các tính năng cũ có thể dễ dàng thay đổi. MVC cho phép các nhà phát triển và các nhà thiết kế có thể làm việc đồng thời với nhau. MVC cho phép thay đổi trong 1 phần của ứng dụng mà không ảnh hưởng đến các phần khác. -18- 2.1.3. Các thành phần của ASP.NET MVC ASP.NET MVC cũng chia nhỏ một ứng dụng thành ba thành phần để cài đặt, mỗi thành phần đóng một vai trò khác nhau và ảnh hưởng lẫn nhau, đó là model, view, và controller. Hình 2.2. Các thành phần của MVC + Models: có nhiệm vụ lưu trữ thông tin, trạng thái của các đối tượng, thông thường nó là một lớp được ánh xạ từ một bảng trong CSDL. Ví dụ: Chúng ta có lớp Giáo trình được sử dụng để mô tả dữ liệu từ bảng Giáo trình trong SQL, bao gồm Mã giáo trình, Tên giáo trình... + Views: chịu trách nhiệm hiển thị các thông tin lên cho người dùng thông qua giao diện. Thông thường, các thông tin cần hiển thị được lấy từ thành phần Models. + Controllers: chịu trách nhiệm xử lý các tác động về mặt giao diện, các thao tác đối với models, và cuối cùng là chọn một view thích hợp để hiển thị ra màn hình. Trong kiến trúc MVC, View chỉ có tác dụng hiển thị giao diện mà thôi, còn điều khiển dòng nhập xuất của người dùng vẫn do Controllers đảm trách. -19- 2.1.4. Lợi ích của mô hình MVC  Có tính mở rộng do có thể thay thế từng thành phần 1 cách dễ dàng.  Không sử dụng Viewstate, điều này làm các nhà phát triển dễ dàng điều khiển ứng dụng của mình.  Hệ thống định tuyến mới mạnh mẽ.  Hỗ trợ tốt hơn cho test-driven development (TDD – mô hình phát triển kiểm thử) cài đặt các kiểm thử đơn vị (unit tests) tự động, xác định và kiểm tra lại các yêu cầu trước khi bắt tay vào viết code.  Hỗ trợ kết hợp rất tốt giữa người lập trình và người thiết kế giao diện.  Sử dụng các tính năng tốt nhất đã có của ASP.NET. 2.2. Mô hình MVVM Mô hình MVVM (Model - View - View Model) là một mô hình kiến trúc dùng trong công nghệ phần mềm được phát triển từ Microsoft và chủ yếu dựa trên mô hình MVC. Xuất phát từ như cầu thực tế, đó là sự thay đổi trong việc xử lý sự kiện và dữ liệu, giữa các tầng của ứng dụng với nhau, qua đó, hầu hết các công việc của tầng kết hợp với lớp presentation. Điều này làm nảy sinh ra nhu cầu phải có một mô hình phát triển ứng dụng mới phù hợp hơn. Và do đó, mô hình Model – View – ViewModel (MVVM) ra đời và ngày càng trở nên phổ biến hơn. Mô hình MVVM giúp phát triển ứng dụng linh hoạt bằng cách tách biệt ra 3 phần là Model, View và View Model như hình vẽ dưới đây: Hình 2.3. Các thành phần của mô hình MVVM -20- Trong đó:  View: tương tự như trong mô hình MVC, View là phần giao diện của ứng dụng để hiển thị dữ liệu và nhận tương tác của người dùng. Nó có nhiệm vụ hiển thị thông tin từ View Model, người dùng có thể tương tác với View để truyền mệnh lệnh xuống cho View Model và có thể được cập nhật thông tin khi trạng thái thông tin trong View Model thay đổi. Một điểm khác biệt so với các ứng dụng truyền thống là View trong mô hình này tích cực hơn. Nó có khả năng thực hiện các hành vi và phản hồi lại người dùng thông qua tính năng binding, command.  ViewModel: là phần xử lý logic, lấy dữ liệu từ cơ sở dữ liệu trong phần Model hiển thị lên View và cập nhập dữ liệu từ View xuống cơ sở dữ liệu trong Model, hoặc có thể chỉ xử lý nghiệp vụ thông thường mà không cần lấy dữ liệu dưới cơ sở dữ liệu. ViewModel có thể được xem là thành phần thay thế cho Controller trong mô hình MVC. Nó chứa các mã lệnh cần thiết để thực hiện data binding, command. Lưu ý rằng nó không phải là phần dữ liệu trong Model và cũng không phải là UI trong View, mà nó quản lý phần dữ liệu mà người dùng đang tương tác.  Model: là phần chứa dữ liệu của ứng dụng và nó được tách riêng với phần giao diện người dùng (UI). Cũng tương tự như trong mô hình MVC. Model là các đối tượng giúp truy xuất và thao tác trên dữ liệu thực sự. 2.3. Mô hình đa tầng (n-Tier) Trong kỹ thuật phần mềm, kiến trúc đa tầng (thường được gọi là kiến trúc n-tier) là một kiến trúc client-server trong đó trình bày, xử lý ứng dụng, và quản lý dữ liệu chức năng được tách biệt. Việc sử dụng rộng rãi nhất của kiến trúc đa tầng là kiến trúc 3 tầng (3-Tier). Kiến trúc n-tier ứng dụng cung cấp một mô hình mà các nhà phát triển có thể tạo ra các ứng dụng linh hoạt và sử dụng lại. Bằng cách tách một ứng dụng -21- thành các tầng, các nhà phát triển có được các tùy chọn để sửa đổi hoặc bổ sung thêm một tầng cụ thể, thay vì làm lại toàn bộ ứng dụng. 2.3.1. Khái niệm Mô hình 3 tầng (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-tier) được coi là một KTPM và là một mẫu thiết kế. 2.3.2. Các thành phần của mô hình 3 tầng 3-Tiers có tính vật lý (physical): là mô hình client-server (mỗi tier có thể đặt chung 1 nơi hoặc nhiều nơi, kết nối với nhau qua Web services, WCF, Remoting…). 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. Kiến trúc 3-tier gồm 3 tầng chính:  Presentation Tier: bao gồm các thành phần xử lý giao diện Graphic User Interface (GUI). Đượ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.  Business Logic Tier: gồm các thành phần Business Logic Layer (BLL), Data Access Layer (DAL) và Data Tranfer Object (DTO). Được dùng để cung cấp các chức năng của phần mềm.  Data Tier: Tầng giao tiếp với các hệ quản trị CSDL. -22- Hình 2.4. Các tầng trong mô hình 3-tier và nhiệm vụ của nó 2.3.3. Tính chất của 3-Tier - Giảm sự gắn kết giữa các thực thể phần mềm: xây dựng phần mềm theo mô hình 3-Tier làm giảm sự gắn kết giữa các thành phần trong hệ thống do mỗi tầng có trách nhiệm độc lập tương đối. -23- Hình 2.5. Mô hình 3-Tier giảm sự gắn kết giữa các thực thể - Tái sử dụng: chính vì giảm sự gắn kết giữa các tầng nên xây dựng phần mềm theo mô hình 3-Tier giúp cho việc bổ sung, chỉnh sửa, cập nhật hệ thống một cách dễ dàng, đơn giản hơn. Hình 2.6. Mô hình 3-Tier giúp dễ dàng tái sử dụng phần mềm - Chia sẻ trách nhiệm: vì mỗi tầng có thể đặt ở nhiều nơi khác nhau và vai trò của mỗi tầng là khác nhau và tương đối độc lập nên việc phát triển phần mềm theo mô hình này giúp chia sẻ trách nhiệm ở mỗi tầng cũng như trách nhiệm đối với đội ngũ phát triển hệ thống. Hình 2.7. Mô hình 3-Tier giúp dễ dàng chia sẻ trách nhiệm -24- 2.3.4. Ưu, nhược điểm của 3-tier 3-tier là một KTPM, 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ô 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. 2.4. Mô hình 3-Layer 2.4.1. Khái niệm Trong phát triển ứng dụng, để dễ quản lý các thành phần của hệ thống, cũng như không bị ảnh hưởng bởi các thay đổi, người ta hay nhóm các thành phần có cùng chức năng lại với nhau và phân chia trách nhiệm cho từng nhóm để công việc không bị chồng chéo và ảnh hưởng lẫn nhau. Ví dụ trong một công ty có từng phòng ban, mỗi phòng ban sẽ chịu trách nhiệm một công việc cụ thể nào đó, phòng này không được can thiệp vào công việc nội bộ của phòng kia như Phòng tài chính thì chỉ phát lương, còn chuyện lấy tiền đâu phát cho các anh phòng Marketing thì các anh không cần biết. Trong phát triển phần mềm, người ta cũng áp dụng cách phân chia chức năng này, đó là mô hình 3-Layer (3 lớp), mỗi lớp sẽ thực hiện một chức năng nào đó. Không như mô hình 3-Tiers có tính vật lý, mô hình 3-Layers có tính logic (mỗi layer có 1 công việc) và là 1 thành phần của 3-Tiers. -25- 2.4.2. Các thành phần của 3-Layer Mô hình 3-Layer được cấu thành từ 3 Layer: Presentation Layer hay còn gọi là Graphic User Interface (GUI), Business Logic Layer (BLL) và Data Access Layer (DAL). Các lớp này sẽ giao tiếp với nhau thông qua các dịch vụ (services) mà mỗi lớp cung cấp để tạo nên ứng dụng, lớp này cũng không cần biết bên trong lớp kia làm gì mà chỉ cần biết lớp kia cung cấp dịch vụ gì cho mình và sử dụng nó mà thôi. Mô hình 3 lớp mà Microsoft đề nghị dùng cho các hệ thống phát triển trên nền .NET như sau: Hình 2.8. Các thành phần của mô hình 3-Layer Trong đó:  GUI: Thành phần gia

Định dạng
Số trang	84
Dung lượng	1,86 MB