Đề tài Xây dựng và triển khai giải pháp Chợ điện tử

những khác biệt, sau đây là mô tả quá trình tương tác: Một event client-side gây ra một sự kiện - Ajax event. Bất kỳ một tác động nào cũng có thể gây ra Ajax event, từ một sự kiện onchange đơn giản cho đến một số tác động của người dùng. Ví dụ với đoạn mã sau: Một thể hiện của XMLHttpRequest được tạo ra. Dùng phương thức open(), tạo lời gọi hàm - địa chỉ URL được thiết lập cùng với phương thức HTTP yêu cầu, thông thường là GET hay POST. Request được tạo ra qua việc gọi phương thức send(). Đoạn mã nguồn sau thể hiện điều đó: var xmlHttp; function validateEmail() { var email = document.getElementById("email"); var url = "validate?email=" + escape(email.value); if (window.ActiveXObject) { xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");} else if (window.XMLHttpRequest) { xmlHttp = new XMLHttpRequest();} xmlHttp.open("GET", url); xmlHttp.onreadystatechange = callback; xmlHttp.send(null); } Một request được tạo và gửi đến server. Có thể là một lời gọi tới một servlet, một CGI script, hay một công nghệ phía server nào đó tương tự như ASP.NET, JSP, hay PHP…Server xử lí các yêu cầu, chẳng hạn như truy cập cơ sở dữ liệu hay một tác vụ hệ thống nào đấy. Response được trả về cho trình duyệt. Trường Content-Type được thiết lập ở dạng text/xml; XMLHttpRequest chỉ có thể xử lí kết quả dạng text/html. Trong các thể hiện phức tạp hơn, response khá rắc rối và bao gồm JavaScript, các thao tác trên đối tượng DOM, hoặc các công nghệ liên quan khác. Chú ý là cũng cần thiết lập header vì thế trình duyệt sẽ không lưu kết quả một cách cục bộ. Ta sẽ làm như sau: response.setHeader("Cache-Control", "no-cache"); response.setHeader("Pragma", "no-cache"); Trong ví dụ sau, cấu hình XMLHttpRequest để gọi hàm callback() khi kết quả xử lí được trả về. Hàm này kiểm tra thuộc tính readyState trên đối tượng XMLHttpRequest và sau đó xem xét mã trạng thái trả về từ server. Mọi thứ hoàn toàn bình thường, hàm callback() có thể làm nhiều việc trên phía client. Một phương thức callback thường có dạng sau: function callback() {    if (xmlHttp.readyState == 4) {       if (xmlHttp.status == 200) {       //do something interesting here       }  } } Có một số khác biệt với mô hình request/response thông thường. Phải xem xét thêm về việc tạo và thiết lập một đối tượng XMLHttpRequest và sau đó (hàm) callback sẽ kiểm tra các trạng thái. Thường thì các lời gọi chuẩn này được đóng gói vào một thư viện để dùng trong ứng dụng, hay nói cách khác là dùng một thư viện có sẵn để thực thi Ajax cho ứng dụng Web. Hầu hết các framework và toolkit Ajax trên các trang Web đều dùng các kĩ thuật cơ bản và trừu tượng hóa các trình duyệt, và thêm vào một số component giao diện người dùng (UI). Một số là các framework thuần client; còn lại làm việc trên server. Nhiều framework trong số này mới được bắt đầu xây dựng, nhưng chúng liên tục có các phiên bản và có thên các thư viện mới. Một số giải pháp để thực thi Ajax là các thư viện Ajax.NET, Atlas, libXmlRequest, RSLite, sarissa, JavaScript Object Notation (JSON), JSRS, Direct Web Remoting (DWR), và Ruby on Rails… GET và POST GET: Trên lý thuyết, sử dụng GET khi request không thay đổi giá trị, tức là nhiều request sẽ trả về cùng kết quả. Trong thực tế, nếu phương thức tương ứng ở server thay đổi trạng thái theo một vài cách, thì điều này không còn đúng nữa. Điều này có nghĩa, nó là một chuẩn. Tóm lại, dùng GET để truy lục dữ liệu từ server; hay nói cách khác tránh được việc thay đổi trạng thái trên với lời gọi GET. POST: Phương thức POST được dùng khi muốn thay đổi trạng thái trên server. Không giống như GET, phải thiết lập phần Content-Type header trên đối tượng XMLHttpRequest như sau: xmlHttp.setRequestHeader("Content-Type","application/x-www-form-urlencoded");  POST không hạn chế kích thước của payload được gửi tới server, và POST request không cần bảo đảm tính không đổi. Hầu hết các request được thiết lập ở GET request; tuy nhiên trạng thái POST cũng luôn sẵn sàng khi cần thiết. Xây dựng Request theo từng bước Bước 1: Tạo một ví dụ. Đây chỉ là một ví dụ cổ điển của một lớp, nhưng phải có hai sự lựa chọn ứng với mỗi khả năng tương thích của trình duyệt. if(window.XMLHttpRequest)//Đối tượng của window hiện hành{ request = new XMLHttpRequest();// Firefox, Safari, ...} else if (window.ActiveXObject)// phiên bản ActiveX { request = new ActiveXObject(“Microsoft.XMLHttp”);// Internet Explorer } Bước 2: Chờ hồi đáp Sự hồi đáp hay quá trình xử lý xa hơn bao gồm chức năng và sự trả về của chức năng được gán cho thuộc tính onreadystatechange của đối tượng được tạo trước đây. request.onreadystatechange = function() { // chỉ dẫn để xử lý Response }; if (request.readyState == 4){    // Đã nhận, OK } else { // chờ ...} Bước 3: Tạo Request Có hai phương thức XMLHttpRequest được sử dụng: open: lệnh GET hoặc POST, URL của tài liệu, true nếu bất đồng bộ send: chỉ với POST, dữ liệu được gởi đến Server Request sau đọc tài liệu trên Server http_request.open('GET', ' http_request.send(null); Ví dụ với TextResponse Xây dựng một ví dụ đơn giản. Các mã JavaScript gửi request đến một trang HTML, test.html. Trang này chứa dòng "Im a test", sau đó dùng alert() để gửi ra nội dung của file đó. var httpRequest = false; //Ban đầu chưa có request function makeRequest(url) { httpRequest = false; if (window.XMLHttpRequest) { // Kiểm tra hỗ trợ đối tượng XMLHttpRequest trên Mozilla, Safari,... httpRequest = new XMLHttpRequest(); if (httpRequest.overrideMimeType) { httpRequest.overrideMimeType(text/xml); } } else if (window.ActiveXObject) { // Trên IE, kiểm tra xem ActiveX có bị disable try { httpRequest = new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) { try { httpRequest = new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) { //Xử lý khác của bạn } } } if (!httpRequest) { alert(Giving up :( Cannot create an XMLHTTP instance); return false; } httpRequest.onreadystatechange = alertContents; httpRequest.open(GET, url, true); httpRequest.send(null); } function alertContents() { if (httpRequest.readyState == 4) { if (httpRequest.status == 200) { alert(httpRequest.responseText); } else { alert(There was a problem with the request.); }}} <span style="cursor: pointer; text-decoration: underline" onclick="makeRequest(test.html)"> Trong ví dụ này, người dùng kích chuột vào liên kết "Make a request" trên trình duyệt, việc này sẽ gọi hàm makeRequest() cùng với một tham số – cái tên test.html của file HTML trong cùng thư mục. Sau đó request được thực hiện. Tiếp theo, bạn xác định hàm alertContents() sẽ xử lý trường hợp onreadystatechange. alertContents() kiểm tra xem response đã nhận được hay chưa và nếu OK thì nó sẽ thực thi alert() để gửi ra nội dung của file test.html. Ví dụ với XML Response Ví dụ vừa minh họa đưa ra cách dùng thuộc tính reponseText của đối tượng request. Ví dụ dưới đây sẽ minh họa cho thuộc tính responseXML. Việc đầu tiên là chuẩn bị trang XML sẽ được dùng cho request về sau. Trang dưới có tên là test.xml: Im a test. - Trong dòng mã của ví dụ trên chúng ta chỉ cần thay dòng request bằng: ... onclick="makeRequest(test.xml)"> ... - Sau đó trong alertContents() chúng ta cần thay dòng alert(httpRequest.responseText); với: var xmldoc = httpRequest.responseXML; var root_node=xmldoc.getElementByTagName(root).item(0); alert(root_node.firstChild.data); ResponseXML lấy giúp chúng ta đối tượng XMLDocument và chúng ta sẽ dùng các phương thức DOM để truy cập một số dữ liệu có trong trang XML. Nhược điểm của Ajax AJAX có thể góp phần tạo nên một thế hệ mới cho ứng dụng Web nhưng cũng là một công nghệ "nguy hiểm" khi gây ra không ít rắc rối về giao diện người dùng. Chẳng hạn, phím "Back" (trở lại trang trước) được đánh giá cao trong giao diện Website chuẩn. Đáng tiếc, chức năng này không hoạt động ăn khớp với Javascript và người dùng không thể tìm lại nội dung trước đó khi bấm phím Back. Bởi vậy, chỉ một sơ xuất nhỏ là dữ liệu trên trang đã bị thay đổi và khó có thể khôi phục lại được. Đây là một trong những nguyên nhân chính khiến nhiều người không ủng hộ ứng dụng Javascript. Bên cạnh đó, mọi người không thể lưu lại địa chỉ Web vào thư mục Favorite (Bookmark) để xem lại về sau. Do áp dụng lớp trung gian để giao dịch, các ứng dụng AJAX không có một địa chỉ cố định cho từng nội dung. Khiếm khuyết này làm cho AJAX dễ "mất điểm" trong mắt người dùng. Những trình duyệt hỗ trợ AJAX là Microsoft Internet Explorer 5.0 trở lên; trình duyệt dựa trên Gecko như Mozilla, Firefox, SeaMonkey, Epiphany, Galeon và Netscape 7.1; trình duyệt chứa KHTML API 3.2 trở lên như Konqueror, Apple Safari...   Chương 3 ỨNG DỤNG CÁC CÔNG NGHỆ VÀO XÂY DỰNG và TRIỂN KHAI GIẢI PHÁP CHỢ ĐIỆN TỬ Giới thiệu ứng dụng Mô tả Xây dựng các Control: Datagrid, Tab, Poup, Danh mục cấp,… cho ứng dụng. Ứng dụng “Xây dựng và triển khai giải pháp Chợ điện tử” được xây dựng dựa trên các Control đã được xây dựng. Các chức năng chính cho ứng dụng: Thêm, xóa, sửa các tin tức Thêm mới các Danh mục Mua hàng So sánh Sản phẩm Thêm Sản phẩm vào danh sách “Ước gì” của cá nhân (phải Login) Chọn hình thức thanh toán: Credit Card và Cash Đấu giá và mua hàng Bán hàng Đấu giá Sản phẩm (phải Login) Đăng tin rao vặt Đăng tin khuyến mãi (phải Login) Quản lý danh mục mặt hàng (do Admin quản lý) Thêm mặt hàng vào danh mục Chỉnh sửa, xóa mặt hàng Tìm kiếm, hiển thị các Sản phẩm Đăng ký tài khoản Quản lý thông tin cá nhân Chỉnh sửa thông tin cá nhân, thay đổi mật khẩu Quản lý tin nhắn cá nhân: Gởi, đọc và xóa tin nhắn Hiển thị các mặt hàng đã mua / bán Lọc Sản phẩm mua theo: Đã mua, đang đấu giá, không mua được. Lọc Sản phẩm bán theo: Đang bán, đã bán xong, Chưa bán được. Nạp tiền vào tài khoản Yêu cầu hệ thống Hệ thống chạy ứng dụng phải cài đặt các phần mềm sau: IIS (Information Internet Service) .NET Framework 2.0 Microsoft Visual Studio 2005 Microsoft SQL Server 2000 Trình duyệt Internet Explorer hoặc NetScape. Phân tích ứng dụng Phân tích UML Các tác nhân chính (Actors) và Use Case Các tác nhân chính Hình 3.1 – Các tác nhân chính trong ứng dụng Các Use Case: Được mô tả bằng hình elipse Actor Use Case User Buy Goods (based on: Small Goods, promotional Goods) Sell Goods Search Goods (Basic, Advanced Search) Choose Goods (according: Auction Goods, Direct Bought Goods, advertised Goods, Promotional Goods) View Goods (based on: Choose Goods, Search Goods) Publish Classified Items Register Account To Auction Login - User Buy directly Publish Promotional Items Administrator Add Items Publish news daily Login - User Change Password Edit Personal Information View Personal Information Send, Read, Delete Messages View “Wish” List View Sold / Bought Goods Filter Sold / Bought Goods Deliver money into Account (for sell and buy) Transfer of money Login / Logout System Bảng 3.1 – Mô tả các Actor và Use Case Các biểu đồ (Diagrams) Biểu đồ Use Case Use Case cho Administrator Hình 3.2 – Use case mô tả chức năng của Administrator Use Case cho Users Hình 3.3 – Use case mô tả chức năng của Users Mô tả chi tiết các Use Case cho Users Use Case “Mua hàng” Hình 3.3.1 (a) – Use Case mô tả chức năng “Mua hàng” Mô tả chi tiết Use Case “Mua hàng” Hình 3.3.1 (b) – Mô tả chi tiết chức năng “Mua hàng” Use Case “Bán hàng” Hình 3.3.2 (a) – Use Case mô tả chức năng “Bán hàng” Mô tả chi tiết Use Case “Bán hàng” Hình 3.3.2 (b) – Mô tả chi tiết chức năng “Bán hàng” Use Case “Tìm kiếm” Hình 3.3.3 (a) – Use Case mô tả chức năng “Tìm kiếm” Mô tả chi tiết Use Case “Tìm kiếm” Hình 3.3.3 (b) – Mô tả chi tiết chức năng “Tìm kiếm” Use Case “Đấu giá” Hình 3.3.4 (a) – Use Case mô tả chức năng “Đấu giá” Mô tả chi tiết Use Case “Đấu giá” Hình 3.3.4 (b) – Mô tả chi tiết chức năng “Đấu giá” Use Case “Đăng Sản phẩm rao vặt – khuyến mãi” Hình 3.3.5 (a) – Use Case mô tả chức năng “Đăng Sản phẩm rao vặt – khuyến mãi” Mô tả chi tiết Use Case “Đăng Sản phẩm Rao vặt – Khuyến mãi” Hình 3.3.5 (b) - Mô tả chi tiết chức năng “Đăng Sản phẩm rao vặt – khuyến mãi” Use Case “Đăng tin tức hằng ngày” Hình 3.3.6 (a) – Use Case mô tả chức năng “Đăng tin tức hằng ngày” MÔ tả chi tiết Use Case “Đăng tin tức hằng ngày” Hình 3.3.6 (b) – Mô tả chi tiết chức năng “Đăng tin tức hằng ngày” Use Case “Đăng ký tài khoản” Hình 3.3.7 (a) – Use Case mô tả chức năng “Đăng ký tài khoản” Mô tả chi tiết Use Case “Đăng ký tài khoản” Hình 3.3.7 (b) – Mô tả chi tiết chức năng “Đăng tin tức hằng ngày” Use Case “Quản lý thông tin cá nhân” Hình 3.3.8 (a) – Use Case mô tả chức năng “Quản lý thông tin cá nhân” Mô tả chi tiết Use Case “Quản lý thông tin cá nhân” Hình 3.3.8 (b) – Mô tả chi tiết chức năng “Quản lý thông tin cá nhân” Use Case “Đăng nhập” Hình 3.3.9 (a) – Use Case mô tả chức năng “Đăng nhập” Mô tả chi tiết chức năng “Đăng nhập” Hình 3.3.9 (b) – Mô tả chi tiết chức năng “Đăng nhập” Biểu đồ Activiry (Biểu đồ hoạt động) Biểu đồ hoạt động “Mua hàng” Hình 3.4 – Biểu đồ mô tả hoạt dộng cho Use Case “Mua hàng” Biểu đồ Collaboration (Biểu đồ hợp tác) Biểu đồ hợp tác “Mua hàng” Hình 3.5 – Biểu đồ hợp tác mô tả chức năng “Mua hàng” Kiến trúc Chợ Điện Tử Ứng dụng chợ điện tử bao gồm 4 dự án (project) như hình: Hình 3.6 Các dự án được sử dụng trong “Chợ điện tử” Các dự án được xây dựng bên trong “Chợ điện tử” gồm: dự án Application (Application Project), dự án DataProvider (DataProvider Project), dự án Controls (Controls Project) và cơ sở dữ liệu. Các dự án và cơ sở dữ liệu trong mô hình “Chợ” điện tử” có sự tương tác, kết hợp lẫn nhau, sau đây là mô hình: Hình 3.7 Mô hình sự tương tác chính giữa các dự án và cơ sở dữ liệu Dự án Application được xây dựng từ các Control của dự án Control. Các phương thức của dự án Controls được kết hợp với các phương thức Components để thực hiện các thao tác xử lý Control. Khi các sự kiện Control trong dự án được phát sinh, các sự kiện này sẽ kết hợp với các phương thức của dự án DataProvider để lấy tạo nên một sự tương tác với cơ sở dự liệu. Dự án DataProvider là cầu nối quan trọng giữa cơ sở dự liệu và các dự án khác. Ưu điểm của việc phân chia ứng dụng chợ điện tử thành các project nhỏ so với cách viết website thông thường: Việc phân chia các dự án đảm bảo được mô hình ba tầng khi xây dựng và triển khai một ứng dụng web. Việc phân chia các project như vậy làm cho việc xây dựng ứng dụng “Chợ điện tử” được dễ dàng, có một sự rõ ràng trong định hướng, làm khâu viết code không bị chồng chéo. Các dự án sau khi xây dựng có khả năng tái sử dụng vào các ứng dụng xây dựng website khác, các nhà lập trình web có thể kế thừa để phát triển thêm các ứng dụng riêng. Dự án Application (Application Project) Dự án Application là dự án để chạy ứng dụng website trang chợ điện tử. Trong dự án này chứa các tập tin như *.aspx, *.ascx, .... và đặc biệt là chứa các file *.dll đã được biên dịch từ các file code dạng *.cs của các dự án Controls, dự án Components, dự án DataProvider. Các file *.dll này bao gồm: Controls.dll, Components.dll, DataProvider.dll. Các file *.dll được biên dịch sẽ được lưu trữ tại thư mục Bin của dự án Application nhằm mục đích để Framework của .NET đọc các lớp code từ các file này phục vụ cho việc xử lý, hiển thị các trang website. Hình 3.8 Các file *.dll được lưu trữ tại thư mục Application/Bin của dự án Application Để sử dụng được các file *.dll trong ứng dụng, phải thêm các thể hiển của file này trong tập tin web.config. Cách thêm như thế này giúp đọc các lớp, các phương thức chứa trong file *.dll được xuyên suốt trong ứng dụng mà không cần phải gọi lại các lớp, các phương thức này nhiều lần trong ứng dụng. Điều này giúp tiết kiệm thời gian cho người lập trình viên khi viết web. Hình 3.9 Các file *.dll được nhúng trong tập tin web.config TagPrefix là tên thẻ tiền tố biểu thị cho không gian tên (Namespace) của một file *.dll được sử dụng khi nhúng một lớp code kiểu control vào trang *.aspx hoặc trang *.ascx. Assembly biểu thị cho các tập tin dạng dll, một assembly được xem như là một đơn vị. Namespace là không gian tên chứa trong tập tin dạng dll cần sử dụng, trong một tập tin dạng dll có thể chứa nhiều namespace. Dùng kỹ thuật XML trong việc sử dụng đa ngôn ngữ Trong dự án ứng dụng có sử dụng kỹ thuật XML để định dạng đa ngôn ngữ dùng trong website thông qua các tập tin được lưu trữ tại thư mục Application/Languages/ Hình 3.10 Một phần nội dung tập tin Vietnamese.xml để hiển thị giao diện tiếng Việt Thuộc tính name định nghĩa trong thẻ resource được dùng để phân biệt trong việc lấy các dữ liệu hiển thị lên website. Ứng với thuộc tính name có giá trị “em_Search_Keyword” ta có dữ liệu “Từ khoá” với tập tin ngôn ngữ là tiếng Việt (nằm trong tập tin Vietnamese.xml). Với mỗi tập tin ngôn ngữ khác nhau (English.xml, Vietnamese.xml, ....), các thuộc tính name giống nhau nhưng với dữ liệu khác nhau để phục vụ cho các ngôn ngữ khác nhau. Như vậy với trường hợp ngôn ngữ là tiếng Anh (tập tin English.xml), giá trị name “em_Search_Keyword” sẽ có dữ liệu là “Keyword”. Việc lấy các dữ liệu bằng thuộc tính name trong file XML được thực hiện thông qua các Control ResourceButton, ResourceLabel, ReosourceLinkButton trong dự án Controls và các lớp xử lý, phân tích file XML trong dự án Components. Lớp ResourceManager.cs trong dự án Components là lớp chính của việc thao tác với XML dùng để quản lý nguồn tài nguyên trong ứng dụng. Hình 3.11 - Mô hình luồng xử lý cho việc lấy dữ liệu từ tập tin XML ứng với ngôn ngữ Vietnames.xml Luồng yêu cầu dữ liệu (luồng các mũi tên tô mảnh, hình 3.5 ) Khi một người truy cập trang web abc.aspx với thuộc tính ngôn ngữ là tiếng Việt. Khi đó .NET Framework phân tích code trang này và thấy có một Controls tên là ResourceLabel. Dựa vào Control này, .NET Framework chuyến đọc tới lớp ResourceLabel kèm theo thuộc tính ngôn ngữ trong dự án Controls. Lớp ResourceLabel triệu gọi một phương thức lấy dữ liệu từ file XML, thông qua phương thức này, tiếp tục các lớp ResourceManager.cs của dự án Components được gọi để xử lý tập tin Vietnamese.xml, tìm dữ liệu ứng với thuộc tính name. Lớp Cache.cs trong dự án Components góp phần lưu trữ dữ liệu giữa các lần gọi giúp ứng dụng chạy nhanh hơn. Luồng phản hồi dữ liệu (luồng các mũi tên in đậm, hình3.5 ) Sau khi hoàn tất việc tìm kiếm thuộc tính name trong tập tin Vietnamese.xml. Nếu không có dữ liệu ứng với thuộc tính name này, phương thức tìm kiếm sẽ tự động quăng ra lỗi và trả về mô tả lỗi theo dòng in đậm trở về trình duyệt thông báo cho người sử dụng. Ngượcc lại, sẽ trả về kết quả theo dòng in đậm và hiển thị dữ liệu ứng với thuộc tính name đó trên website (trong trường hợp này dữ liệu là “Từ khoá”). URL Rewriting dùng trong ứng dụng Kỹ thuật URL Writing được dùng trong dự án Application nhằm giúp cho ứng dụng được hai thuộc tính lợi ích sau đây: Tính tiện lợi Người sử dụng internet luôn muốn truy cập vào các trang web có đường dẫn ngắn gọn, có quy tắc và dễ nhớ. Từ đó, kỹ thuật URL Rewriting được phát triển để loại bỏ những trang có đường dẫn dài, có nhiều tham số truy vấn, chuyển những trang web có đường dẫn phức tạp này về kiểu đơn giản. Kỹ thuật này giúp người sử dụng khi truy cập website tốn ít thời gian gõ tên đường dẫn mang lại tính tiện lợi khi truy cập website. So sánh hai đường dẫn sau đây: Đường dẫn 1 Đường dẫn 2 Bảng 3.2 Bảng so sánh hai đường dẫn. Đường dẫn 1 không dùng kỹ thuật URL Rewriting, đường dẫn 2 dùng kỹ thuật URL Rewriting Đường dẫn 2 dùng kỹ thuật URL Writing giúp người sử dụng dễ nhớ tên đường dẫn ngắn gọn hơn, thông qua các quy tắc dễ nhớ ngày, tháng, năm. Trong khi đó, đường dẫn 1 mang lại nhiều bất tiện. Tính duy trì Trong các website lớn, việc chuyển đổi các trang từ thư mục này sang thư mục khác sẽ gây một tác động nhất định đối với ứng dụng. Kết quả làm một số phần hoặc cả website không hoạt động. Để dễ hiểu sự cố này, hình dung ví dụ có hai đường dẫn và đường dẫn Người quản trị website đã di chuyển 2 trang Copyright.aspx và trang Contact.aspx đến thư mục mới tên là Help vào ngày hôm sau. Như vậy, người sử dụng internet đã lưu đường dẫn hai trang này trong ngày hôm trước tại lịch sử trình duyệt phải truy cập và lưu đường dẫn mới trong ngày hôm nay. Vấn đề này có thể được giải quyết bằng cách thêm một trang đệm chứa phương thức Response.Redirect(“tên đường dẫn”). Tuy nhiên, cách làm này không hiệu quả đối với việc di chuyển số lượng lớn (hàng trăm, hàng nghìn) các trang từ thư mục này sang thư mục khác trong ứng dụng. Do đó, kỹ thuật URL Rewriting giúp giải quyết vấn đề trên bằng cách chỉnh sửa đoạn code trong file *.config giúp người lập trình web di chuyển các trang giữa các thư mục ảo một cách nhanh chóng. Theo cách này, các nhà phát triển ứng dụng web có thể tách rời kiến trúc vật lý của website ra khỏi kiến trúc logic tới người dùng thông qua các URL. Nói tóm lại, kỹ thuật URL Rewriting góp phần làm duy trì website hoạt động ổn định. Ánh xạ URL tự nhiên(native) trong ASP.NET 2.0 ASP.NET 2.0 cung cấp một giải pháp sáng tạo cho việc ánh xạ URL tĩnh đối với một ứng dụng Web. Việc ánh xạ URL cũ đến một URL mới bên trong tập tin web.config có thể được thực hiện mà không cần phải viết bất kỳ dòng lệnh nào cả. Để sử dụng việc ánh xạ URL, chỉ cần tạo một phần urlMapping bên trong phần system.web của tập tin web.config và thêm vào các yêu cầu cần ánh xạ. (đường dẫn dạng ~/ biểu thị cho thư mục gốc của ứng dụng web). Hình 3.12 - Phần urlMapping bên trong file web.config Vì vậy, nếu người sử dụng internet truy cập vào một đường dẫn có tên là: thì người đó sẽ thấy ngay mộttrang mới có đường dẫn là: mà không cần phải hiểu cơ chế trang cũ đã được ánh xạ tới trang mới. Một điểm bất lợi khác của kỹ thuật ánh xạ URL tự nhiên là trường hợp nếu một trang có tên là Contacts.aspx chứa một số các yếu tố và bắt đầu postback về server (điều này hầu hết xảy ra), thì sau đó người sử dụng sẽ rất ngạc nhiên vì đường dẫn bị thay đổi đến đường dẫn (Hình .). Trong trường hợp này đáng lý đường dẫn cũ phải dẫn tới đường dẫn mới là Điều này bị xảy ra vì cơ chế của ASP.NET sẽ điền thuộc tính action trong thẻ HTML form với một đường dẫn thực đến một trang. Dạng form này được trả về mã HTML như sau: Hình 3.13 - Đoạn code form khi trả về mã HTML Vì vậy, việc ánh xạ URL có sẵn trong ASP.NET 2.0 hầu hết là vô dụng. Việc chỉ rõ một tập hợp URL tương tự nhau trong một quy luật (rule) ánh xạ có thể được thực hiện tốt hơn. Giải pháp tốt nhất cho vấn đề này là sử dụng Regular Expression (được viết tắt là "RegEx" hoặc "regex" là một chuỗi được dùng để mô tả hoặc so sánh một tập chuỗi, theo các quy luật cú pháp nào đó) nhưng ASP.NET 2.0 không hỗ trợ Regular Expression. Vì vậy cần phải phát triển một giải pháp khác để tích hợp việc ánh xạ URL. Module URL Rewriting Cách tốt nhất để thực hiện một giải pháp URL Rewriting là tạo ra một module dễ cấu hình và có thể tái sử dụng, vì vậy quyết định sáng suốt nhất là tạo ra một HTTPModule và thực hiện nó như là một đơn vị (assembly) riêng lẻ. Để tạo đơn vị (assembly) này dễ sử dụng đến mức có thể, cần phải hiểu rõ việc cấu hình cơ chế viết lại (rewrite) và đặc tả được các quy luật trong tập tin web.config. Trong quá trình phát triển, cần phải có khả năng tắt, mở module URL Rewriting (ví dụ trong trường hợp gặp lỗi khó sửa, đó có thể là nguyên nhân do các quy luật viết lại được mô tả không đúng).   true Hình 3.14 - Module URL Rewriting có chức năng tắt/mở module thông qua thuộc tính rewriteOn Điều này có nghĩa là các yều cầu đến server dạng: được kết nối lại đến trang Post.aspx với các tham số truy vấn dạng chuỗi. (trong trường hợp này là trang Tập tin web.config dạng tâp tin dạng cú pháp XML vì vậy ký tự & trong giá trị chuỗi thuộc tính bị cấm. Trong trường này, phải sử dụng mã & thay cho ký tự trên. Để sử dụng phần rewriteModule trong tập tin web.config, cần phải đăng ký (register) tên và điều khiển cho phần này. Cách làm đơn giản là thêm một phần configSections trong tập tin web.config. Hình 3.15 - Phần configSections Điều này có nghĩa là sẽ sử dụng phần sau đây dưới phần configSection:       true Hình 3.16 - Phần modulesSection Một điểm khác khi hướng về quá trình phát triển module rewriting là nên sử dụng những URL ảo với các tham số chuỗi truy vấn nếu có thể, ví dụ như đường dẫn sau đây: Trong đường dẫn này, hai tham số truy vấn là Sort và SortBy với các giá trị lần lượt là Desc và Date. Vì vậy, cần phát triển một giải pháp mới có thể dò tìm các tham số hợp quy cách thông qua các chuỗi truy vấn và thông qua URL ảo trong ứng dụng web. Hình 3.17 - Quá trình ánh xạ một URL ảo thành một URL thực Cấu hình Handling the configuration section Để có thể đọc các tuỳ chọn cấu hình đặc tả trong tập tin web.config thì phải tạo một lớp thi hành giao diện IConfigurationSectionHandler. Điều này được mô tả như hình sau: using System; using System.Collections.Generic; using System.Text; using System.Configuration; using System.Web; using System.Xml; namespace RewriteModule {     public class RewriteModuleSectionHandler : IConfigurationSectionHandler     {         private XmlNode _XmlSection;         private string _RewriteBase;         private bool _RewriteOn;         public XmlNode XmlSection         {             get { return _XmlSection; }         }         public string RewriteBase         {             get { return _RewriteBase; }         }         public bool RewriteOn         {             get { return _RewriteOn; }         }         public object Create(object parent, object configContext,                            System.Xml.XmlNode section)         {             // set base path for rewriting module to             // application root             _RewriteBase = HttpContext.Current.Request.ApplicationPath + "/";             // process configuration section             // from web.config             try             {                 _XmlSection = section;                 _RewriteOn = Convert.ToBoolean(                            section.SelectSingleNode("rewriteOn").InnerText);             }             catch (Exception ex)             {                 throw (new Exception("Error while processing RewriteModule configuration section.", ex));             }             return this;         }     } } Hình 3.18 - Lớp code RewriteModuleSectionHandler Lớp RewriteModuleSectionHandler được khởi tạo bằng cách gọi phương thức Create() với phần rewriteModule của tập tin web.config có quy cách là XmlNode. Phương thức SelectSingleNode của lớp XmlNode được sử dụng để trả về các giá trị cho các thiếp lập module. Sử dụng các tham số từ URL được viết lại (rewritten) Khi điều khiển các đường URL dạng như somebloghost.com/Blogs/gaidar/?Sort=Asc (đường dẫn URL với các tham số chuỗi truy vấn), việc phân biệt rõ ràng các tham số là một điều quan trọng khi xem xét tham số nào hợp quy cách thông qua một chuỗi truy vấn từ các tham số, tham số nào hợp quy cách như là các thư mục ảo. Sử dụng quy luật viết lại (rewriting) được mô tả như sau: Hình 3.19 - Một quy luật viết lại (rewrite) kiểu thư mục Với đoạn code trong hình trên, một đường dẫn có dạng: so.com/gaidar/?Folder=Blogs tương ứng với đường dẫn có dạng: so.com/Blogs/gaidar/ Để giải quyết được vấn đề này thì phải nên tạo một dạng bao bọc (wrapper) cho các tham số đường dẫn ảo. Điều này có thể là một tập hợp các phương thức tĩnh để truy cập các tập tham số hiện tại. using System; using System.Collections.Generic; using System.Text; using System.Collections.Specialized; using System.Web; namespace RewriteModule {     public class RewriteContext     {         // returns actual RewriteContext instance for current request         public static RewriteContext Current         {             get             {                 // Look for RewriteContext instance in                 // current HttpContext. If there is no RewriteContextInfo                 // item then this means that rewrite module is turned off                 if(HttpContext.Current.Items.Contains("RewriteContextInfo"))                     return (RewriteContext) HttpContext.Current.Items["RewriteContextInfo"];                 else                     return new RewriteContext();             }         }         public RewriteContext()         {             _Params = new NameValueCollection(); _InitialUrl = String.Empty;         }        public RewriteContext(NameValueCollection param, string url)         {             _InitialUrl = url; _Params = new NameValueCollection(param);         }         private NameValueCollection _Params;         public NameValueCollection Params         {             get { return _Params; } set { _Params = value; }         }         private string _InitialUrl;         public string InitialUrl         {             get { return _InitialUrl; }set { _InitialUrl = value; }         }     } } Hình 3.20 Lớp RewriteContext Có thể truy cập các tham số đường dẫn ảo (virtual path parameters) thông qua tập hợp RewriteContext.Current và chắc chắn các tham số này đã được đặc tả trong đường URL giống như là các thư mục ảo hoặc các tên trang, mà không phải là các tham số chuỗi truy vấn. Các URL Rewriting Cách tạo dạng viết lại (rewriting) được làm theo hai bước. Đầu tiên, cần phải có các quy luật viết lại (rewrite rules) từ tập tin web.config. Sau đó, kiểm tra các URL thực đối lập với các quy luật, nếu cần thiết, làm một vài dạng viết lại (rewriting) để trang hoạt động đúng. Tạo một HttpModule: class RewriteModule : IHttpModule{ public void Dispose() { }public void Init(HttpApplication context) { } } Hình 3.21 - IHttpModule Khi phương thức RewriteModule_BeginRequest được thêm vào, phương thức này sẽ xử lý các quy luật tương phản với đường dẫn URL được đưa ra, vì vậy cần phải kiểm tra nếu các URL đưa ra có các tham số chuỗi truy vấn và gọi HttpContext.Current.RewritePath để mang lại điều khiển tới trang ASP.NET thích hợp. namespace RewriteModule {     class RewriteModule : IHttpModule     {         public void Dispose() { }         public void Init(HttpApplication context)         {             // it is necessary to             context.BeginRequest += new EventHandler(RewriteModule_BeginRequest);         }         void RewriteModule_BeginRequest(object sender, EventArgs e)         {             RewriteModuleSectionHandler cfg =(RewriteModuleSectionHandler) ConfigurationManager.GetSection("modulesSection/rewriteModule");             // module is turned off in web.config             if (!cfg.RewriteOn) return;             string path = HttpContext.Current.Request.Path;             // there us nothing to process             if (path.Length == 0) return;             // load rewriting rules from web.config             // and loop through rules collection until first match             XmlNode rules = cfg.XmlSection.SelectSingleNode("rewriteRules");             foreach (XmlNode xml in rules.SelectNodes("rule"))             {                 try                 {                     Regex re = new Regex(                     cfg.RewriteBase + xml.Attributes["source"].InnerText,                     RegexOptions.IgnoreCase);                     Match match = re.Match(path);                     if (match.Success)                     {                         path = re.Replace(                             path,                              xml.Attributes["destination"].InnerText);                         if (path.Length != 0)                         {                             // check for QueryString parameters                        if(HttpContext.Current.Request.QueryString.Count != 0)                        {                        // if there are Query String papameters                        // then append them to current path                        string sign = (path.IndexOf('?') == -1) ? "?" : "&";                        path = path + sign +                          HttpContext.Current.Request.QueryString.ToString();                        }                        // new path to rewrite to                        string rew = cfg.RewriteBase + path;                        // save original path to HttpContext for further use                        HttpContext.Current.Items.Add(                          "OriginalUrl",                          HttpContext.Current.Request.RawUrl);                        // rewrite                        HttpContext.Current.RewritePath(rew);                        }                        return;                     }                 }                 catch (Exception ex)                 {                     throw (new Exception("Incorrect rule.", ex));                 }             }             return;         }     } } Sau đó cần phải đăng ký (register) phương thức này: public void Init(HttpApplication context) { context.BeginRequest += new EventHandler(RewriteModule_BeginRequest); } Khi biên dịch đoạn code trên và xem mã nguồn HTML của trang ASP.NET đối với một thuộc tính hành động (action) của thẻ form, người sử dụng sẽ thấy thuộc tính hành động (action) có URL ảo chứa đường dẫn tới một trang ASP.NET có thực. Ví dụ, nếu sử dụng trang ~/Page.aspx để điều khiển các yêu cầu dạng như somebloghost.com/Blogs/2006/12/10/Default.aspx , khi đó thuộc tính hành động (action) như sau: action=”/Post.aspx”. Điều này có nghĩa là người sử dụng sẽ không dùng đường dẫn ảo khi postback, mà dùng đường dẫn thực: somebloghost.com/Blog.aspx. Như vậy, đây là điều không nên dùng. Như vậy, cần phải thêm một số dòng code sau. Sau đó cần đăng ký và thực thi các phương thức trong HttpModule         public void Init(HttpApplication context)         {             // it is necessary to             context.BeginRequest += new EventHandler(                 RewriteModule_BeginRequest);             context.PreRequestHandlerExecute += new EventHandler(                 RewriteModule_PreRequestHandlerExecute);         }       void RewriteModule_PreRequestHandlerExecute(object sender, EventArgs e)         {             HttpApplication app = (HttpApplication)sender;             if ((app.Context.CurrentHandler is Page) &&                  app.Context.CurrentHandler != null)             {                 Page pg = (Page)app.Context.CurrentHandler;                 pg.PreInit += new EventHandler(Page_PreInit);             }         } Phương thức này sẽ kiểm tra nếu người sử dụng đã yêu cầu một trang ASP.NET và thêm một điều khiển cho sự kiện PreInit của chu kỳ sống trang. Đó là nơi RewriteContext được viết với các tham số thực và URL viết lại (rewrite) thứ hai sẽ được thực hiện. Dạng viết lại (rewriting) thứ hai được cần thiết để làm cho ASP.NET biết được nó muốn dùng một đường dẫn ảo trong thuộc tính hoạt động (action) của một form HTML. void Page_PreInit(object sender, EventArgs e) {             // restore internal path to original             // this is required to handle postbacks             if (HttpContext.Current.Items.Contains("OriginalUrl"))             {               string path = (string)HttpContext.Current.Items["OriginalUrl"];               // save query string parameters to context               RewriteContext con = new RewriteContext(                HttpContext.Current.Request.QueryString, path);               HttpContext.Current.Items["RewriteContextInfo"] =  con;               if (path.IndexOf("?") == -1)                   path += "?";               HttpContext.Current.RewritePath(path);             }         } Hình 3.22 - Phương thức xử lý sự kiện Page_PreInit Mô hình các lớp của RewriteModule như sau: Hình 3.23 - Mô hình lớp RewriteModule Đăng ký (register) ReWriteModule trong web.config Để sử dụng RewriteModule trong ứng dụng web, cần phải thêm thể hiện tới phần rewrite và đăng ký HttpModule trong tập tin web.config của ứng dụng web. Để đăng ký HttpModule, cần thêm đoạn code sau vào trong tập tin web.config ở phần system.web của ứn dụng website: Hình 3.24 –Đăng ký ReWriteModule trong Web.Config Sử dụng RewriteModule Có một vài điều về cách sử dụng RewriteModule như sau: Có thể dùng các ký tự đặc biệt trong tài liệu dạng cú pháp XML như là tập tin web.config. Vì vậy phải dùng ký hiệu dạng HTML được mã hoá. Ví dụ, dùng mã & thay cho dấu &. Sử dụng các đường dẫn quan hệ trong các trang ASP.NET, phương thức ResolveUrl nên được gọi bên trong các thẻ HTML, ví dụ như: . Chú ý, ký hiệu ~/ biều thị cho thư mục gốc của ứng dụng. Nếu muốn sử dụng RewriteModule cho các trang khác định dạng *.aspx thì phải cấu hình trong IIS đế ánh xạ yêu cầu đến các trang với các phần mở rộng mong muốn tới ASP.NET khi thi hành. Dự án Components (Components Project) Dự án Components là dự án chứa các lớp code xử lý các thao tác thành phần cho ứng dụng website như xây dựng bộ nhớ Cache, thao tác xử lý liên quan đến đa ngôn ngữ (XML), dùng kỹ thuật URL Rewriting, xây dựng các lớp gửi mail, xây dựng các lớp. Các lớp code trong dự án Components được biên dịch thành tập tin thư viện có tên là Components.dll. Tập tin này được sử dụng vào dự án Controls, dự án DataProvider nhằm đáp ứng các yêu cầu riêng của các lớp trong các dự án liên quan. Một số lớp code xử lý riêng (thành phần), một số lớp code đơn, lẻ chỉ phục vụ cho một vài chức năng nào đó trong website được gạn lọc, chuyển về trong dự án Components. Điều này giúp các nhà lập trình loại bỏ sự rườm ra, phân chia không rõ ràng về chức năng của một số phương thức, lớp code khi viết ứng dụng web. Mô hình tương tác giữa dự án Components với các dự án khác Giải thích mô hình này Một số thao tác chức năng cơ bản, bảo mật, bẫy lỗi được sử dụng trong dự án Components Dự án Controls (Controls Project) Dự án Controls là dự án xây dựng tất cả control dùng để phục vụ cho dự án Application. Các control này được chia thành các lớp code khác nhau sau đó được biên dịch thành một file duy nhất tên là Controls.dll. Sau đó, tập tin này được nhúng vào dự án Application để sử dụng các Control trên website. Hình 3.25 - Dự án Controls liệt kê theo kiểu thư mục Thư mục Base Chứa các lớp code cơ bản để định nghĩa một Control. Lớp chính trong thư mục này là lớp WrappedFormBase.cs. Đây là lớp định nghĩa về Template, DataSource, chỉ số Id,.. và các phương thức như DataBind(), AttachChildControls(), CreateControlHierarchy() ... được các Control khác kế thừa. Hình 3.26 - Các lớp code chứa trong thư mục Base Lớp Chức năng ActionBase WrappedContentBase WrappedControlTag CSThemePageBase WrappedControlItem WrappedControlTagHelper PreTemplatedWrappedContentBase WrappedControlItemTemplate WrappedFormBase Bảng 3.3 - Liệt kê các lớp code trong thư mục Base Phân tích lớp WrappedFormBase Thư mục BaseControl: chứa các Control cơ bản nhất đường dùng trong lập trình Web như: Button, Text, Label, DataGrid, Tab, .... Các Control này đa số được viết theo kiểu Custom Control và một số Control còn lại được viết theo kiểu Composite Control. Giới thiệu về một số BaseControl nổi bật Thư mục Forms Mô tả một số Control Form được sử dụng trong website AdColumnForm Hiển thị một danh sách hình theo chiều dọc, cho phép người dùng nhập hình vào, đường dẫn hình hoặc mặc định là lấy danh sách hình trong cơ sở dữ liệu. cần thể hiện như thế này: Khi nhúng vào trang ứng dụng thì cứ tạo trang riêng để test, chỉ cần nhúng vào là được theo kiến trúc hoặc LinkForm CatalogueFrontForm SearchControl NewsFrontControl StoreFamousForm StoreIntroduceForm DiscountProductForm Dự án DataProvider (DataProvider) Dự án DataProvider là dự án xây dựng các lớp tương tác với cơ sở dữ liệu để thực hiện các thao tác như lấy dữ liệu, cập nhật, thêm, xoá các trường (record) của các bảng. Dự án DataProvider là một cầu nối trung gian giữa cơ sở dữ liệu (Database) và các dự án khác để hiện thị nội dung, thông tin được lấy từ cơ sở dữ liệu. Cách viết tách ra hẳn một dự án dạng DataProvider giúp các nhà lập trình Web có thể tái sử dụng lại dự án này cho các website khác, mang lại một sự minh bạch, rõ ràng khi viết code, đồng thời góp phần làm cho việc truy xuất cơ sở dữ liệu nhanh hơn cách viết thông thường. Các lớp code trong dự án DataProvider được biên dịch thành file thư viện tên là: DataProvider.dll được nhúng vào dự án Controls để thực hiện những thao tác trên các Control liên quan đến cơ sở dữ liệu. Từ đó, các Control này lại được sử dụng trong dự án Application để xây dựng các trang website. Hình 3.27 - Sự tương tác chính giữa dự án DataProvider với các dự án khác Các ký hiệu số được sử dụng trong hình được mô tả như sau: số 1: .NET framework tiến hành phân tích login Control ra các lớp, các sự kiện, các event, ... số 2: Sự kiện LoginButton_Click(...) khi phát sinh sẽ gọi một phương thức của dự án DataProvider để tương tác với cơ sở dữ liệu số 3: Dự án DataProvider cung cấp một lớp code để đọc file web.config trong dự án Application để lấy chuỗi kết nối đến cơ sở dữ liệu (Connection String) số 4: Kết nối, truy xuất cơ sở dữ liêu để so sánh username, password và trả về thông tin cần thiết Giải thích hình Khi một người sử dụng internet truy cập vào trang Login.aspx của website. Server sẽ phân tích file Login.aspx và nhận thấy rằng có một Control tên là Login. Khi đó lớp Login trong dự án Controls Project được phân tích và trả về giao diện Login cho người dùng. Hình 3.28 - Giao diện Login Control mô phỏng khi trả về cho người dùng Người sử dụng tiếp tục nhập Username, Password rồi nhấn nút Login. Với kiểu nhập vào username, password đúng dịnh dạng, server nhận được hồi đáp và nhận thấy sự kiện LoginButton_Click(...){...} được phát sinh. Khi đó, một phương thức trong dự án DataProvider được gọi để kiểm tra username, password này có đúng với thông tin lưu trong cơ sở dữ liệu hay không và trả về thông tin thích hợp. Trước khi kiểm tra điều này, phương thức đó tiếp tục gọi một phương thức khác (trong lớp đọc và phân tích file web.config) để lấy chuỗi kết nối (Connection String). Tiếp tục phương thức trong dự án DataProvider thực hiện kết nối dữ liệu, đọc, so sánh thông tin và trả về thông báo về người sử dụng internet có nhập đúng username, password hay không. Hình 3.29 - Lớp CheckUser trong dự án DataProvider thực hiên các thao tác tương tác với cơ sở dữ liệu Các lớp chứa trong dự án DataProvider và chức năng Giải thích các lớp này Các biểu đồ trình tự một số chức năng nổi bật của ứng dụng Biểu đồ trình tự “Mua hàng” Hình 3.30 –Biểu đồ trình tự cho chức năng “Mua hàng” Biểu đồ trình tự chung cho các chức năng: Đấu giá, mua ngay, đăng tin rao vặt, khuyến mãi Hình 3.31 – Biểu đồ trình tự chung cho các chức năng Biểu đồ trình tự “Đấu giá Sản phẩm” Hình 3.32 –Biểu đồ trình tự cho chức năng “Đấu giá Sản phẩm” Biểu đồ trình tự “Mua hàng” Hình 3.33 –Biểu đồ trình tự cho chức năng “Mua hàng” Thiết kế ứng dụng Mô tả cơ sở dữ liệu của ứng dụng Bảng Mô tả bảng Các thuộc tính Mô tả chi tiết tblCategory Bảng chứa đựng thông tin các Sản phẩm trong Danh mục Id Thuộc tính tăng tự động khi thêm một Danh mục mới CategoryName Tên của Sản phẩm Danh mục Image Hình ảnh SP Description Mô tả chi tiết cho SP Note Ghi chú tblNews Bảng chứa đựng thông tin các tin tức: Website, Doanh nghiệp, tin tức hằng ngày,… Id Thuộc tính tăng tự động khi thêm một Tin tức mới Title Tựa đề của tin tức Content Nội dung chi tiết của Tin tức Image Hình ảnh đính kèm Website Địa chỉ Website (nếu có) Telephone Điện thọai của Doanh nghiệp đăng tin Email Địa chỉ Email của DN Address Địa chỉ của DN tblProducts Bảng danh sách các Sản phẩm con của các Sản phẩm trong Danh mục ProductCode Mã Sản phẩm (tồn tại duy nhất) ProductName Tên Sản phẩm Image Hình ảnh SP ParentId ID của SP cha (SP con thuộc SP nào trong Danh mục) HaveChild SP này có SP con hay không. - Nếu có thì HaveChild = true và SP này sẽ được thêm vào bảng DM để nâng SP này lên thành SP cha. (SP cha trong bảng DM lúc này sẽ là DM cấp2,3,…) - Nếu không thì HaveChild = false và SP Cha trong bbng DM sẽ chỉ là DM cấp 2. Description Mô tả chi tiết cho SP con này ManufatureFirm Hãng sản xuất của SP ProductStream Dòng SP tblSmallProducts Bảng thông tin các Sản phẩm Rao vặt Id Thuộc tính tăng tự động khi thêm một SP mới ProductCode Mã SP Image Hình ảnh đính kèm Title Tiêu đề của SP Content Nội dung chi tiết của SP Seller Người rao vặt để bán SP Price Giá cho SP ContactInfo Thông tin liên hệ của người bán Email Email người bán [Date] Ngày rao vặt (Ngày giờ hệ thống) tblPromotionProducts Bảng danh sách các Sản phẩm Khuyến mãi (Người dùng phải đăng nhập) Id Thuộc tính tăng tự động khi thêm một SP mới ProductCode Mã SP DetailContent Nội dung chi tiết của SP ProductStatus Trạng thái SP PaymentForm Hình thức thanh toán TransferCost Phí vận chuyển StartPrice Giá khởi điểm cho SP FloorPrice Giá sán SellPrice Giá bán PaymentLimit Giới hạn thanh toán StartTime Thời gian bắt đầu EndTime Thời gian kết thúc CurrTime Thời gian hiện hành IsPriority Chế độ ưu tiên cho SP lên đầu trong Danh sách các SP khuyến mãi MoneyForPriority Số tiền cho SP khuyến mãi [User] Thành viên đã đăng tin IsSold SP đã được bán hay chưa - Nếu IsSold = 1: Đã bán xong (khi thuộc tính ‘Check’ trong bảng ShoppingCart = true) - Nếu IsSold = 0: Chưa bán được - Nếu IsSold = 2: Đang bán (khi thuộc tính ‘Check’ trong bảng ShoppingCart = false) tblShoppingCart Bảng thông tin các Sản phẩm người dùng đã mua và số tiền thanh toán tương ứng Id Thuộc tính tăng tự động khi người dùng thêm 1 SP vào giỏ hàng ProductCode Mã SP [User] Thành viên mua SP Content Nội dung BoughtDate Ngày mua Quantity Số lượng mua 1 SP MoneySum Tiền mua tổng cộng IsAuction SP này ‘đấu giá’ hay ‘mua ngay’ - IsAuction = true: SP đang đấu giá - IsAuction = false: SP mua ngay AuctionPrice Giá SP (khi IsAuction = true) YourAuctionIdea Ý kiến cho SP khi đấu giá CheckBought Kiểm tra SP đã được mua chưa (liên quan đến IsSold) tblUser Bảng danh sách những thành viên đã đăng ký trong ứng dụng “Chợ điện tử” LoginName Tên đăng nhập của thành viên UserName Tên thành viên Password Mật khẩu cho thành viên Telephone Số điện thoại của thành viên Email Email của thành viên Address Địa chỉ của thành viên IdentityCard Số CMND (nếu có) CreditCardNo Số thẻ Credit tblMessage Bảng chứa đựng các tin nhắn của thành viên Id Thuộc tính tăng tự động khi thành viên có 1 tin nhắn mới MessageTitle Tiêu đề tin nhắn MessageContent Nội dung tin nhắn MessageType Loại tin nhắn: - MessageType = 1: Tin nhắn đi - MessageType = 0; Tin nhắn đến Receiver Người nhận ti nhắn Sender Người gởi FileAttachment File đính kèm tblWishList Danh sách các Sản phẩm “Ước gì” của thành viên Id Thuộc tính tăng tự động khi thành viên thêm 1 SP vào ‘Danh sách Ước gì’ Product Tên SP [User] Tên thành viên [Date] Ngày thêm SP Bảng 3.4 – Danh sách các bảng trong CSDL Cơ sở dữ liệu của ứng dụng Hình 3.10 – Mô tả biểu đồ CSDL (các bảng và mối quan hệ giữa chúng) Xây dựng và triển khai ứng dụng “Chợ điện tử” Cài đặt ứng dụng Cài đặt cơ sở dữ liệu Cài đặt cơ sở dữ liệu dạng Backup Cài đặt cơ sở dữ liệu dạng Attachment Cài đặt cơ sở dữ liệu dạng Script Cài đặt website Cài đặt website trên IIS Cài đặt website trên Apache Thử nghiệm chạy website KẾT LUẬN Kết quả đạt được: Sau khi hoàn thành khóa luận tốt nghiệp, nhóm chúng em đã thu được các kết quả sau: Về mặt lý thuyết Nhóm đã tìm hiểu được các vấn đề: Một số khái niệm, bản chất và đặc điểm của Thương mại điện tử Một số vấn đề cần quan tâm khi tham gia Thương mại điện tử: Mua / bán hàng, thanh toán trong điện tử,… Khái niệm, bản chất và đặc trưng của .NET Framework, ASP.NET, Custom Control và AJAX. Về mặt ứng dụng Nhóm đã hoàn thành được các mục tiêu đã đề ra: Xây dựng các Control cần thiết cho ứng dụng Ví dụ, Tab Control, DataGrid Control, Popup Control, Control Danh mục cấp, Search Control,… Ứng dụng được xây dựng dựa trên kiến trúc code mở cho phép nâng cấp, triển khai các giải pháp. Xây dựng Website bao gồm các chức năng: Mua hàng, bán hàng, đấu giá, rao vặt, khuyến mãi, đăng ký tài khoản cá nhân trên trang Web, quản lý thông tin cá nhân. Quản lý đăng xuất hệ thống của người dùng. Hướng phát triển: Cho phép người dùng xây dựng gian hàng trực tuyến cá nhân, tùy biến giao diện riêng cho người dùng. Xây dựng hệ thống thanh toán điện tử Xây dựng các hóa đơn mua / bán hàng khi người dùng thực hiện mua / bán hàng Phát triển ứng dụng “Chợ điện tử” trên máy Global. TÀI LIỆU THAM KHẢO hoặc THƯ MỤC [1] APress - Real World ASP.NET - Building a Content Management System [2] Apress - Uml Applied A Net Perspective [3] AJAX Creating Web Pages with Asynchronous JavaScript and XML - Prentice Hall PTR [4] MsPress - Designing Microsoft ASP.Net Applications [5] Wrox - Professional Dotnetnuke Asp Dot Net Portals 2005 [6] Wrox Professional Asp Net 2.0 Nov 2005 Ebook-Ling [7] Wrox Professional ASP.NET 2.0 Security Membership and Role Management  2006 [8] Wrox Professional UML with Visual Studio NET[7] [9] Wrox Professional ASP NET 2.0 Server Control and Component Development Aug 2006 [10] TS Nguyễn Đăng Hậu (2004), “Kiến thức Thương Mại Điện Tử ”, Viện Đào Tạo Công Nghệ và Quản Lý Quốc Tế Khoa Công Nghệ Thông Tin [11] Các Website: PHỤ LỤC Công việc của các thành viên trong nhóm Nhóm gồm 2 thành viên và công việc cụ thể của thành viên trong nhóm như sau: Tạ Hoàng Thắng Nghiên cứu kiến trúc Code Community Server Thiết kế giao diện, tạo kiến trúc code cho ứng dụng“Xây dựng và triển khai giải pháp Chợ điện tử” Code các thư viện Control: Tin tức, danh mục Thực hiện code chức năng “Bán hàng” cho ứng dụng Ráp các Control vào giao diện Viết báo cáo Bùi Nguyễn Thanh Yên Nghiên cứu kiến trúc Code Community Server Thiết kế mô hình UML: các biểu đồ Use Case, Collaboration, Sequence, Activity,…cho ứng dụng Phân tích và thiết kế cơ sở dữ liệu Code các thư viện Control: Tab Control, Datagrid Control, Popup Control Thực hiện code chức năng Đăng ký tài khoản cá nhân và “Mua hàng” cho ứng dụng Viết báo cáo